On Tue, Jan 31, 2017 at 12:51 PM, Ben Laurie <[email protected]> wrote:
> On 30 January 2017 at 04:39, Eric Rescorla <[email protected]> wrote: > > > > > > On Sun, Jan 29, 2017 at 6:44 PM, Ben Laurie <[email protected]> wrote: > >> > >> On 29 January 2017 at 17:08, Eric Rescorla <[email protected]> wrote: > >> > Hi Melinda, > >> > > >> > Unfortunately, I don't believe that the concerns that we are proposing > >> > can in fact be plausibly addressed by post-hoc mechanisms on top of > >> > the 6962-bis structure. To be precise, one might build either: > >> > > >> > (a) A system which is not publicly verifiable in which case EEs would > >> > only need to handle and provide SCTs and one can and should > >> > dispense with much of the Merkle hash tree infrastructure. > >> > > >> > (b) A system in which is publicly verifiable in which case the > >> > current Merkle hash tree infrastructure seems inadequate and > >> > would need to be revised, not just built on top of. > >> > > >> > Either of these seem like reasonable WG decisions (though the > >> > charter pretty clearly contemplates (b)) but the current draft > >> > doesn't really do either. For that reason, I don't think it makes > >> > sense to just proceed as-is. Typically for last call comments > >> > of this magnitude the process would be to discuss them at the > >> > next IETF. Accordingly, rather than pubreq the draft now, > >> > we'd ask for agenda time to discuss in Chicago. > >> > >> I don't think you're right. In practice, there are mechanisms that > >> address your concerns, I believe. > >> > >> Firstly, its important to understand that the goal of CT is to reveal > >> misissuance, not to prevent it, nor to deal with it when it occurs. > > > > > > That's a reasonable objective, but as far as I can tell it requires that > > the client be able to ensure that it is seeing the same thing that the > > rest of the world sees (i.e., "public" or "end-to-end" verifiability). > > The concerns that we have raised go to the practicality of achieving > > that. > > Given that CT has revealed a good deal of misissuance it is clear that > it does not _require_ that, but it is, of course, a desirable > property. > > In other words: don't let the perfect be the enemy of the good. > Sorry, I should have been clearer. As I said in my earlier mail, I think there are several threat models: - Security if you trust the CAs to accurately log their certs. - Security if you trust the logs to accurately log certs. - Security even if you don't trust the logs. ISTM that the misissuance that CT has revealed is under the first threat model, namely that the CAs are misbehaving but correctly logging. However this doesn't require any of the Merkle tree machinery specified here; indeed it doesn't even require the browser to check SCTs, because these events happened when people don't check them. > > >> Next, STH consistency. > >> > >> My preferred plan for this is to add a new leaf type, STH, and require > >> (by policy) all logs to accept STHs from all other logs. Then you add > >> a call to logs that lists the positions of those STHs, so they can be > >> efficiently retrieved. Or maybe just retrieves the latest seen from > >> each log. If inconsistent STHs are ever logged, monitors can detect > >> this. In order to fork a log, you would then have to fork all logs. Of > >> course, monitors and other interested parties could also gossip STHs > >> for added value. > > > > > > That might work, but I think again it requires some notion that there are > > a limited number of STHs which are actually published in practice and > > which there are inclusion proofs to. And then this gets into the > efficiency > > analysis that Richard posted in his initial comments. > > There are a limited number of STHs, again, required by 6962-bis. > > I will have to look again at the efficiency analysis, but I am > sceptical having done the same thing myself when we started the > project! > It would certainly be very helpful to get your thoughts on why you think Richard's analysis is wrong. -Ekr > > > > > > >> All of these can be done on top of 6962-bis. > > > > > > Perhaps. However, given that these proposals are pretty essential to > > determining whether the public verifiability part of CT works, it would > > probably be good to have a fully fleshed out design to analyze prior > > to standardizing that piece. > > > > -Ekr > > > > > >> > >> > >> > > >> > -Ekr > >> > > >> > > >> > On Wed, Jan 25, 2017 at 8:03 PM, Melinda Shore < > [email protected]> > >> > wrote: > >> >> > >> >> Hi, all: > >> >> > >> >> We've been looking at the discussion and trying to figure > >> >> out next steps. Because we believe that the mechanisms > >> >> Richard's asking for can be built on top of what's specified > >> >> in 6962-bis, we've decided that we're going to > >> >> continue progressing the document towards publication, > >> >> and look to Richard and EKR to produce a draft specifying > >> >> a mechanism that meets their requirements with the intent > >> >> of adopting it as a working group deliverable. > >> >> > >> >> Thanks, > >> >> > >> >> Melinda > >> >> > >> > > >> > > >> > _______________________________________________ > >> > Trans mailing list > >> > [email protected] > >> > https://www.ietf.org/mailman/listinfo/trans > >> > > > > > >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
