I thought it might be useful to elaborate on what I meant about threat model and technology for CT. As I mentioned, I think there are three primary threat models one might be concerned about:
1. CAs misissue but aren't malicious. 2. CAs are malicious or otherwise fail to log but logs are not 3. CAs and logs are both malicious In threat model #1, what is mostly required is merely that CAs submit certificates to logs. As long as every CA submits their certs to a common log than misissuance can be detected without any client side behavior at all. This is effectively CT as it is implemented for DV today and as Ben indicates, it has detected misissuance already. If CAs do not log (either maliciously or through mistake), then it is necessary for RPs to refuse to accept certificates which are not logged. However, as long as we believe that the logs behave correctly (specifically, they never sign an SCT that they don't then log) then all that is required is that a certificate contain SCTs from some set of logs and that RPs check that. This is roughly CT as Chrome proposes to implement as of end-of-2017. Note that the Merkle tree infrastructure is not needed here at all. The final case is the one where logs are also malicious and collude with a malicious CA to issue an SCT for a certificate but not to log it. In order to detect this, you need to ensure that RPs have the same view of the log structure as auditors do, because otherwise the CA can issue a certificate which will be acceptable to the RP but will never be audited [0]. The general notion for current CT is that there is some notion of getting global consensus on the state of the log and then the auditors and the RPs can know that they are checking the same thing. This is where the Merkle tree infrastructure comes in (though as I indicated previously, Richard and I do not believe it adequately addresses this case). Note that these are *all* detection use cases, but just detection under particular threat models. So, I think the question is: which threat model is this document intended to address? It seems to me that the charter pretty clearly comes down on #3, because it talks about "verifiable" logs and defines verifiable in a way that seems to include log misissuance. But perhaps I have misunderstood. -Ekr [0] This is just about avoiding TOCTOU bugs. On Wed, Feb 1, 2017 at 7:51 AM, Eric Rescorla <[email protected]> wrote: > > On Tue, Jan 31, 2017 at 7:50 PM, Salz, Rich <[email protected]> wrote: > >> > We don't have consensus. We're deadlocked and we're not getting >> > sufficient input from the working group to break the deadlock. >> >> Well, yeah, that's why you get paid the big bucks, right? :) >> >> > Paul and I can make a decision on the particular question that's a >> problem but >> > it probably means an appeal and further delay. >> >> That's the process. >> >> > Frankly, this working group was chartered under the assumption that the >> > goal was detection, not prevention. >> >> That's my perception as well. Is there anyone who thinks prevention was >> part of the scope? >> > > I think this is painting with a bit too broad a brush. One needs to talk > about > detection under a specific threat model, as I indicated previously. > Specifically, > there seem to be a number of potential threat models: > > 1. CAs make mistakes but aren't malicious. > 2. CAs are malicious but logs are not > 3. CAs and logs are both malicious > > What technological solution is adequate to detect misissuance depends on > which > of these three threat models you think applies. > > -Ekr > >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
