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. So, inclusion proofs. > > One way to deal with this would be to for browsers to report to > servers the previous cert seen for that server. The server can then > fetch the inclusion proof. > > If the client ever talks to the correct server having talked to an > evil one, the evil one will be discovered. If the client doesn't, then > the client is effectively in a bubble and beyond help. > I don't believe this is correct, at least for common clients, because the attacker can selectively interfere with just your connections to the site of interest; this would be detectable with at least some designs. Consider a trivial, inefficient, CT-like system in which the browser manufacturer scrapes the entire CT log and sends it to every browser client. As long as the manufacturer doesn't cheat (in which case you truly are beyond help, but for non-CT reasons), then a client can easily assess log-inclusion for any server as long as the connection back to the vendor is live. And if that connection fails, then the browser in fact knows it is under attack, which is different from the silent attack we have here. So, ultimately, I don't think this is that useful. Another would be to require servers to serve inclusion proofs > alongside the cert, once the SCT was past the MMD. This could be done > either with OCSP stapling or with the TLS extension. I agree that having the server serve an inclusion proof is the right design (and in fact it's what Richard and I contemplated) but this seems problematic for two reasons: 1. It's effectively retroactive consistency and so it's a weaker guarantee than prevention of compromise. I realize that that's not your objective, but it seems like it's a good one. Also, it means that if a client just goes to a site once, then compromise may never even be detected. 2. In order to operate efficiently, it requires that the client be able to verify consistency for the specific STH which this is an inclusion proof for. It's possible that this can be made efficient, especially if you minimize the number of STHs to which inclusion proofs are actually issued, but all that needs to actually be specified in some way. 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. 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
