On Wed, 15 Feb 2017 16:33:40 -0800
Richard Barnes <[email protected]> wrote:
> [...]
>
> >
> > > [...]
> > >
> > > Option M leads to something like a Haber-Stornetta hash chain
> > > of batch Merkle trees.
> >
> > Why? The only justification provided so far is that a client would
> > need to download 4MB of data a month, which is a "pretty big chunk
> > of data."[1] This is a rather extraordinary claim. Can you
> > explain your reasoning why 4MB a month is too much?
> >
>
> To be a bit glib -- the folks who manage syncing state out to Firefox
> balked when I mentioned it to them.
>
> Basically, that amount might not sound scary from the client side,
> but if you're thinking about syncing that data out to 100s of
> millions of clients, that's an extra few 100MBps of capacity you have
> to provision, and it's only kinda cacheable.
Ah, it's a server-side constraint. Thanks for clarifying.
Would an effective caching strategy make this implementable by Mozilla?
What if every STH and its consistency proof to the previous STH was
a separate resource? That's trivially cacheable, and HTTP/2 makes
it cheap for the client to request lots of resources at once.
> > Even if 4MB/month is deemed excessive, there are other options which
> > avoid reliance on SCTs, but can be implemented on top of 6962bis'
> > current design without requiring clients to download 4MB a month.
> > Let's call them Options A1 and A2.
> >
>
> To be clear, I did not mean to imply that these were the only
> options. On the contrary, I would like to have some discussion about
> the options here so we can understand what requirements we should be
> holding 6962bis to.
>
> Can you explain why being implemented on top of the current system is
> a requirement? I can see why it's desireable, e.g., to avoid further
> delay. But in general, I would be inclined to change the spec to the
> web's needs rather than the other way around.
Does the desirability of a new design outweigh the desirability of moving
forward with the current one? Tradeoffs always have to be made, or one
could spend forever in quest of the perfect solution. Consider:
1. The delay would likely be significant. RFC6962bis would need major
changes. The gossip and threat analysis documents would need revision.
This would hold up other work.
2. We'd forgo much of the running code and implementation experience
from RFC6962.
3. There's no guarantee that a Haber-Stornetta chain is the right
solution - what if we uncover unforeseen problems in a year?
> > Option A1: Fetch consistency proofs on demand
> >
> > 1. Client gets an STH and an inclusion proof to the STH from server,
> > verifies the proof, and adds STH to a cache if not already present.
> >
> > 2. In the background, client audits unverified STHs in the cache
> > by requesting a consistency proof between the unverified STH and
> > some other verified STH.
> >
> > - [PRO] No need to audit SCTs.
> > - [PRO] Although client makes queries (consistency proofs) that are
> > triggered by
> > browsing, the queries do not reveal browsing history because many
> > certificates
> > use inclusion proofs to the same STH.
> > - [PRO] No need for a log proxy.
> > - [PRO] Client only needs to fetch consistency proofs for STHs it
> > actually sees.
> > - [PRO] Client only needs to store STHs it actually sees.
> > - [CON] CA needs to wait for inclusion proof if inclusion proof is
> > included in cert.
> > - [CON] Requires CA to upgrade to fetch inclusion proofs instead
> > of / in addition to SCTs.
> >
> > I asked you on-list two weeks ago why this wouldn't work[2], but you
> > have not replied.
> >
>
> Sorry, that's my fault. Trying to be more responsible on this
> thread :)
>
> I think this is better than option G, but there are still a couple of
> concerns. The one that's most critical to me is that you're relying
> on the structure of STHs for a privacy property -- if there are too
> few new certs under an STH, then your consistency query reveals your
> browsing history. That seems like a very fragile assumption to be
> making, especially given that we have no STH discipline / schedule in
> the current system. And making logs explicitly trusted for this
> privacy property seems counter to the idea that logs are not to be
> trusted.
6962bis could require a minimum number of log entries between STHs,
much like it requires a minimum amount of time. Monitors could
detect it if logs violated this requirement.
However, one could stuff the log with certificates that it knows will
never be used on the public Internet, so you're right that this option
has privacy problems which makes it inferior to options M and A2.
> > Option A2: Publicly-logged STH batches
> >
> > 1. Auditor pulls STHs from logs at some frequency, validates
> > consistency.
> >
> > 2. Periodically, auditor logs batches of STHs to CT logs.
> >
> > 3. Periodically, the client obtains from the auditor:
> > a. Batches of STHs since the last one the client received
> > b. Inclusion proofs for each STH batch up to the log's latest STH
> > c. Consistency proof between the last STH received by the client
> > and the latest STH
> >
> > 4. The client verifies all proofs received from auditor, but assumes
> > that the STHs in the batches are legitimate.
> >
> > 5. Client caches entire history of STHs that it has received (really
> > just needs to store tree heads).
> >
> > 6. Client gets inclusion proof to an STH from server (either in the
> > certificate or in a stapled OCSP response), verifies it.
> >
> > 7. Client audits by verifying that the STH provided by the server
> > is in the cache.
> >
> > 8. An ecosystem of auditors monitors logs for STH batches and audits
> > all contained STHs by requesting consistency proofs. This saves the
> > client from having to verify every single STH itself.
> >
> > - [PRO] No need to audit SCTs.
> > - [PRO] Client never makes queries in response to browsing.
> > - [PRO] No need for a log proxy.
> > - [CON] CA needs to wait for inclusion proof if inclusion proof is
> > included in cert.
> > - [CON] Client needs to store entire history of STHs.
> > - [CON] Requires CA to upgrade to fetch inclusion proofs instead
> > of / in addition to SCTs.
> >
> > Option A2 is very similar to Option M, but avoids the need for
> > clients to do their own STH auditing (except for STHs related to
> > the STH batches). If you're happy with Option M you should be happy
> > with Option A2, even when implemented on top of the current Merkle
> > Tree design.
> >
>
> What you lose in this design relative to both G and M is the clients
> direct assurance that the STHs it's relying on are a valid sequence,
> as opposed to something the auditor made up. That is, the assurance
> here is like if you took G or M and removed the part where the
> auditor sends down the consistency proofs.
Not quite, because in option A2, the client has assurance that every
STH it relies upon has been published for the world to see. If a
log misbehaves and signs an inconsistent STH, and the auditor passes
that STH through to the client, someone is certain to notice and detect
the log's misbehavior.
> That's not the biggest tragedy in the world, but if that's the best
> we can do, we'll need to be clear about this constraint in the
> document ("Most clients will need to delegate consistency checking to
> an auditor, which means that they will be at risk of the auditor
> lying to them in the following ways...").
It's true that clients have to assume that someone else does the
auditing faithfully, but since the STHs are logged for anyone to
audit, this is a very safe assumption.
> But given that there are
> options on the table that get us to a stranger guarantee at the cost
> of a spec change and some adaptation by the small number of logs that
> exist, I'm not sure why we should settle here.
>
> > I agree with many of your concerns about SCT auditing, but
> > considering that Options A1 and A2 can be implemented on top of
> > 6962bis (plus Option M if 4MB/month can be tolerated), I don't see
> > why these concerns should hold up publication.
> >
>
> As I've noted above, A1 and A2 aren't really meeting my requirements.
> (Maybe we should go through a requirements exercise here?)
I would like to convince you that A2 meets your requirements. I contend
that its auditing guarantees are as strong as M's. In particular, having
proof that the STHs are publicly-logged is just as good as the client
auditing them itself. If you disagree, I'm curious why.
Regards,
Andrew
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
