Todays call

[Linus Nordberg]

Hi,

As per request by Ben, here's the condensed form of what I said on
todays call.

- going to have tor consensuses (and votes from at least one dir auth)
submitted to open/gaol (http://mvkhztpvqcxpdbn3.onion/open/gaol/v1/)
for beginning of march

- got some buy-in from both .cz and .se for participating in the dnssec
trans experiment discussed at the ietf94 meeting (nov -15); goal is to
finalise a poc at the ietf95 hackathon april 2 and 3

[Ben Laurie]

And I guess I said a bunch of stuff, mostly about ObjectHash (https://github.com/benlaurie/objecthash) and redaction, in particular:

1. Redaction is useful because you may want to log private information that can be verified by those allowed to see it but still allow those who can't see it to verify the remainder of the object.

2. It is not possible to technically prevent redaction (even if the facility doesn't exist, clearly a log can simply decline to respond, or respond with a redacted version), so it is not inherently harmful to enable it, and if redaction is not desired, then that can be implemented as a matter of policy (which is the best you can do anyway).

We also discussed git hashes, IPFS and TUF, which I hope others will expand on!

--
You received this message because you are subscribed to the Google Groups "binary-transparency" group.
To unsubscribe from this group and stop receiving emails from it, send an email to binary-transpar...@googlegroups.com.
To post to this group, send an email to binary-tr...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/binary-transparency/87mvroqsiu.fsf%40nordberg.se.
For more options, visit https://groups.google.com/d/optout.

[Eric Myhre]

The most interesting thing I heard from the group overall was the observation that BT discussions get tricky because there's so many questions that can be brought up under that banner. I've felt that pain before too. Have we got a breakdown list of goals anywhere?

Here's a shot:

- [ANYBUILD] can we communicate a build definition to anyone (builds-from-source at all)
- [REPBUILD] is this build definition done right (consistent binary products)
- [TRUSTSRC] do i trust the build definition (comes down to audit or trust (either via author sig, or append-only log))
- [TRUSTRCR] do i trust the binary artifacts a build definition requires as inputs (e.g. can i recurse to those binaries' build definitions, and so on)
- [UPTODATE] is the binary artifact and/or build definition i'm holding up to date
- [SEETWIST] can i discover targeted misuses of (possibly compromised) signing keys
- [MORESIGS] how can we enhance log validity checks, and allow clear definition of multiple PoV's for trust


This is my top-of-the-head list -- do these line up with other folk's imaginings? Any appends?

We have answers in mind to several of these (append-only logs cover several bases), but tis nice to have a list of objectives sans implementation details.

One interesting thought I had as drafting that list is SEETWIST -- which we often seem to be setting our sights on with merklelogs -- may be subtly different than handling *widely* distributed bad-yet-signed packages. Just kicking that out there.

---

TUF -- http://theupdateframework.com/ -- is noteworthy for taking the UPTODATE objective very seriously. They also have an *excellent* enumeration of threats (rollbacks, replays, stalls, etc) in their docs, recommend reading. I'm not sure how TUF jives with distributed logs.

+1 to all DKG's comments about mergable/federatable/gossip-enabled logs. Having logs emanate from any party running a build seems wise.

Re: hashing objects / ipfs: Yeah, it's interesting to note more than one party has come to the conclusion objecthashes are a fundamental need. IPFS did it, Ben's ObjectHash did it, I did a one-off for tars, likely there's more. More interesting though, git did too. This is fine; it seems like duplication of effort and we can try to minimize it as time passes, but as far as dreaming of One True Spec, putting git in the field kinda blows a fuse on utility/cost ratios -- let's just all plan to play together? We might be well advised to have any general-purpose protocols leave room for a hashtree type flag. (That said, ObjectHash seems to be full of "right answers" usable as a library, which is really excellent.)

(n.b. ipfs folk also proposed a "multihash" spec, and while an interesting idea, imho this has a sharp upper limit on utility because the semantics of what you're hashing are at least as important as sha-n vs blake-m, yeah? So multihash might be great for their internal versioning, but you can't convince me it'll ever bridge the gap all the way to say, git, in a useful manner. Nor that you'd in all cases want to make such disparate things transparent.)

A passing note re: encodings: http://cbor.io/ RFC 7049 is a fine one: semantically almost identical to JSON, binary length delimited for fast, supports binary strings without b64 or similar expensive escaping. Simple unambiguously spec'd varinits, even, if you're into that. Since it's *so* similar to JSON, we can define treehashes that actually see them as the same thing.

I like the redaction strategy in Objecthash, fwiw. Seems like a useful thing to bake in.

Spawning a new thread for git-config fun, as I imagine we might want to be able to look that one up by thread title.

---

What a wonderful forum! Cheers all.
-Eric

[Ben Laurie]

On 29 January 2016 at 16:20, Ben Laurie <be...@google.com> wrote:

And I guess I said a bunch of stuff, mostly about ObjectHash (https://github.com/benlaurie/objecthash) and redaction, in particular:

1. Redaction is useful because you may want to log private information that can be verified by those allowed to see it but still allow those who can't see it to verify the remainder of the object.

2. It is not possible to technically prevent redaction (even if the facility doesn't exist, clearly a log can simply decline to respond, or respond with a redacted version), so it is not inherently harmful to enable it, and if redaction is not desired, then that can be implemented as a matter of policy (which is the best you can do anyway).

BTW, the whole point here is that your defence against incorrect redaction is to have your own copy of the unredacted version - which you can prove is a true copy.

[Eric Myhre]

In case anyone was interested in this minutiae of serialization...

I implemented a golang program for all-directional exchange between A)
json B) cbor C) a custom prettyprinter (okay, this one's write-only) and
D) in-memory golang objects.  This might be useful to you, or not.  Note
that despite the fact it is written in golang and supports golang
in-memory objects, golang struct definitions are *not* the internal
lingua-franca; you can easily transform cbor-to-json and vice versa
without defining any structs as an intermediate.

The library is at https://github.com/polydawn/refmt .  There should be a
CLI tool that does the exchanges easily, though I haven't yet been
bothered (I'll get on it real fast if anyone makes requests though!).

This could probably also be extended to do https://www.tjson.org/ pretty
easily, since the internal exchange format is a typed token stream
that's already roughly analogous to tjson's types.

Cheers!

On 01/29/2016 08:10 PM (from the "Todays Call" thread) Eric Myhre wrote:
> A passing note re: encodings: http://cbor.io/ RFC 7049 is a fine one: semantically almost identical to JSON, binary length delimited for fast, supports binary strings without b64 or similar expensive escaping. Simple unambiguously spec'd varinits, even, if you're into that. Since it's *so* similar to JSON, we can define treehashes that actually see them as the same thing.
>
>
>