Re: [Trans] IETF 94 TRANS minutes Draft

[Ben Laurie <[e-mail]>]

On Mon, 16 Nov 2015 at 18:23 Daniel Kahn Gillmor <[e-mail]>
wrote:

> On Mon 2015-11-16 13:08:48 -0500, Ben Laurie wrote:
> > On Mon, 2 Nov 2015 at 05:38 Salz, Rich <[e-mail]> wrote:
> >> Discussion about what inclusion proof is/contains. Dkg and bryan agree
> >> embedding them in cert is probably bad idea.
> >
> > This is not helpful: I think it is probably a good idea. Why is it a bad
> > idea?
>
> From a privacy-perspective: with relatively long-lived certs, embedded
> inclusion proofs are going to contain "stale" STHs.  As a result, it
> makes the verification of these STHs (via consistency proofs)
> potentially privacy-sensitive, since they could be tied to a specific
> origin.
>
> in the current Gossip approach, we manage to make STHs
> non-privacy-sensitive specifically because clients keep them "fresh" and
> are therefore all gossiping about the same current set of STHs.
>
> Does this make sense?  I'd love to hear a counterargument, as i'm
> generally more in favor of inclusion proofs than of SCTs.  Including an
> up-to-date inclusion-proof *alongside* a cert seems fine to me, as would
> including a "fresh" inclusion proof in a short-lived cert.
>
> But my understanding of the lifetime of certs and the narrow window of
> freshness we'd like to keep for STH gossip don't line up.
>
> If a cert includes an older inclusion proof to STH k, and that's always
> bundled with a consistency proof from k to the current "fresh" STH n, i
> don't think that'd be a bad thing.
>

Hmm. I see your point. Obviously if you're capable of bundling an STH
proof, you're also capable of bundling an inclusion proof...


>
>     --dkg
>