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. >> 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. Really? You think the common case is where an attacker controls connections to a single site? > > >> 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. I agree it is a good objective, but not one I know how to achieve practically. If you have a plan, I'm all ears. > > 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. Eh? It is specified in 6962-bis. > > >> 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! > > >> 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
