2016.03.11 cliff notes

[Eric Myhre]

Hello, all; here comes an attempt to share my rough notes from our tea time today, with the usual apologies in advance for omissions and misquotes which shall of course be entirely my fault:


### binary transparency is trendy

There was a flurry of twittering about binary transparency topics in recent weeks. (I missed much of this, perhaps if there's interesting links to reshare others can jump in)


### binary transparency related to closed source

What BT can do for closed source?

- Something, we're sure; audit for consistency is always valuable
- We can, at least, help prevent and detect targeted interceptions, rollback attacks, delays etc, much as CT
- What's different? Open source is significantly more empowered because we can root our trust in Reproducible builds -- there's no need for reverse engineering to reach something semantic

Also, some potential unique challenges were raised (these may not be specific to closed source, but were raised from that inspiration):

- Downloads may embed serial numbers, or other intended variations (like compile time address space layout randomizations).
- How do we manage this? Custom object hash implementations which intentionally ignore those fields?

Todos include recruiting more input from other folks in a commercial environment who have practical knowledge of how we can make this useful and implementable for them.


### accessibility of blobs

Talking about how we can interface with closed source brought up the consideration of making things associated with the log accessible. (This is kind of a recurring topic?)

- A log of hashes is reduced in value if there's not an obvious way to turn around and *get* the binary content again
- Esp. relevant for e.g. taking a previously known item and subjecting it to intense scrutiny later if there's suspected tampering
- Imagine CT if it didn't have domain names! It'd be quite hard for someone to jump in and start helping verification
- Lots of reasons to tread carefully:
- With closed source, we may not be legally permitted to mirror content itself
- Embedding large blobs in the log naively will not scale

By nature, we're referring to things outside of the logs. Is it useful for us to propose a basic standard schema for referring to external assets that's easy to mechanically traverse?

- BT logs are permanent; network locations aren't. Natural friction there.
- Perhaps soothed by making lists of network locations per hash. And/Or url rewrite rules which can be stacked on by later records, like git's `insteadof` configs.
- It may be useful to have different types of fetchers? e.g. a "$platform app store" plugin vs a plain-ol http url.
- Is this connected to how we may want different hasher definitions, as considered for e.g. blobs with intentional variations? Or orthogonal?
- (after-the-fact thought: these considerations about "What justifies a different hasher?" might be resonant with mention of e.g. IPFS multihash a few weeks back)



End-of-Notes. (What did I miss?)

Unrelated: has everyone read the TUF docs at least in passing? I just realized I'm mentally referencing their enumerated threat model a lot: section 1.5.2 of their spec -- "specific attacks to protect against" -- is mi favorito: https://github.com/theupdateframework/tuf/blob/a417f67129a8cb1a3cfc091596c3ba1e9d8de315/docs/tuf-spec.txt#L124-L158