On Wed, Jun 03, 2015 at 02:00:30PM -0700, [email protected] wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Public Notary Transparency Working Group > of the IETF. > > Title : Threat Analysis for Certificate Transparency
A good enumeration of the threat space. My thoughts: > 2.1.1.2. Malicious or conspiring log > > In this case, the bogus (pre-)certificate has been submitted to one > or more logs that are either simply malicious or are conspiring with > the attacker. It is assumed that the logs issue SCTs (in an attempt > to fool browsers and/or Monitors). In this context, a log probably > will suppress a bogus certificate log entry. (This case encompasses > the scenario in which a log creates an entry for the certificate but > reports it selectively.) Do you have any thoughts on what a "simply malicious" log might look like, behaviourally speaking? Is there a way to differentiate, from the outside, whether a log is "simply malicious" or "conspiring"? Do we even care that there's a difference? I wonder if it would be clearer to stick to observed behaviour, rather than motivation? So, rather than talking about a "simply malicious" or "conspiring" log, say instead something like, "a log which does not faithfully report all submitted entries, and/or presents different views of the log to different observers". > Note that a malicious log also could create and report entries for > bogus certificates that have not been issued by the indicated CA. > These could cause the Monitor to report non-existent semantic > problems to the Subject who would in turn report them to the > (apparently) issuing CA. This might cause the CA to do needless > investigative work or perhaps incorrectly revoke and re-issue the > Subject's certificate. How is a malicious log going to be able to report bogus certificates? The closest a malicious log could come is to whack together a cert chain that has the same issuer names, etc, but that won't validate to the CA's *actual* root certificate. Is the point of this section, then, to indicate that reporters of bogus certificates (or the CAs that receive them) should validate the cert chain before taking action? >From Note 5: > Absent a ''gossip'' mechanism that enables Monitors to verify that > data from logs are reported in a consistent fashion, CT cannot claim > to provide protection against logs that are malicious or may > conspire with, or are victims of, attackers effecting certificate > mis-issuance. Developing such a mechanism is not easy. The mechanism > SHOULD protect the privacy of users (with respect to which web sites > they visit). It needs to scale to accommodate a potentially large > number of self-monitoring Subjects and a vast number of browsers (if > browsers are part of the mechanism). Even when a gossip mechanism is > defined, it will be necessary to describe how the CT system will > deal with a mis-behaving or compromised log. For example, will there > be a mechanism to alert all TLS clients to reject SCTs issued by > such a log? Absent a description of a mitigation strategy to deal > with mis-behaving or compromised logs, CT cannot ensure detection of > mis-issuance in a wide range of scenarios. This doesn't seem so much an issue of threat model, as it is a commentary on the current state of CT, and I don't think it belongs in this document. - Matt _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
