I’ve also been thinking about a threat model, though your writing is much clearer than mine!
tl;dr: (a) There’s a lot of text about the details of revocation that I thought was out of scope for CT. (b) A client specification may answer many of the questions you raise about Monitors. -- Katriel Cohn-Gordon Student, Cyber Security Merton College, Oxford On Thursday, 11 September 2014 at 19:08, Stephen Kent wrote: > Certificate Transparency (CT) is intended to detect and mitigate... Is it intended to mitigate problems? (-04) says so but immediately follows it with “the logs do not themselves prevent misissue, but they ensure that interested parties (particularly those named in certificates) can detect such misissuance” A fairer introduction might be “CT is intended to allow subjects to detect…" > A certificate is characterized as mis-issued if the certificate is issued to > an entity that is not authorized to represent the host (web server) named in > the certificate Subject field or Subject Alternative Name extension. Or doesn’t follow certain regulations, or some other definition (e.g. comes from a root that the CA can but does not use to issue certificates). I think it should be up to individual Monitors to define what they consider to be mis-issued, though it makes sense to give a minimal criterion, and hence that the text should say something like “In the following, a certificate is characterised as mis-issued if… but any Monitor may choose to use an alternative definition, since CT is definition-agnostic." > > > Certificate mis-issuance may arise in one of several ways. The ways that CT > helps detect and remedy mis-issuance depends on the context of the > mis-issuance. I think the key distinction to be made is between contexts that cause the certificate to be submitted to a non-malicious Log Server, and those that do not. As you say, in the former case a Monitor tracking the targeted Subject will detect the mis-issued certificate and set off the out-of-scope revocation process. In the latter, TLS clients which are not backwards compatible will refuse to accept the certificate, while TLS clients which do not yet enforce CT will act as they do today. Once the certificate is detected, is the revocation process (e.g. what data the CA requires) in scope for this document? > > 1. If a CA submits the bogus certificate to logs, but these logs are not > watched by a Monitor that is tracking the targeted Subject, CT will not > mitigate a mis-issuance attack. It is not clear whether every Monitor MUST > offer to track every Subject that requests its certificates be monitored. > Absent such a guarantee, how do TLS clients and CAs know which set of > Monitors will provide “sufficient” coverage. Unless these details are > addressed, use of CT does not mitigation mis-issuance even when certificates > are logged. I understood Monitors to be run by Subjects (or paid by Subjects to do their tracking for them), so I see no reason why they MUST offer to track anybody. It’s log servers for which you need sufficient coverage, though, not Monitors: one of the latter will suffice as long as it watches all the former. I don’t know what the current definition of “the set of all log servers” is (*); for the moment I assume it is defined by Google’s list for Chrome. I agree it’s important to specify how Monitors can find out the set of log servers. (e.g. it’s Very Bad if I run my own monitor but don’t update its list, since then a mis-issued certificate submitted to a new log server will pass me by.) > > 3. If a TLS client is to reject a certificate that lacks an embedded SCT, or > is not accompanied by a post-issuance SCT, this behavior needs to be defined > in a way that is compatible with incremental deployment. Issuing a warning to > a (human) user is probably insufficient, based on experience with warnings > displayed for expired certificates, lack of certificate revocation status > information, and similar errors that violate RFC 5280 path validation rules. What’s the precedent for defining incremental deployment in this type of document? I suppose the wording would be something like “TLS clients wishing to respect incremental deployment MAY choose to accept certificates without embedded SCTs, but…" > > 4. The targeted Subject might request the parent or the offending CA to > revoke the certificate of the non-cooperative CA. However, a request of this > sort may be rejected, e.g., because of the potential for significant > collateral damage. Again, is this in scope for CT? This issue exists in today’s infrastructure just as much (c.f. when people removed DigiNotar from trust lists). > > > > Absent a protocol (a so-called “gossip” protocol) that enables Monitors to > verify that data from logs are consistent, CT does not provide protection > against logs that may conspire with, or be victims of, attackers effecting > certificate mis-issuance. Even when a gossip protocol is deployed, it is > 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. I believe this is the same question as at (*): who controls the list of trusted logs? One assumes that anybody doing so (e.g. Chrome) would also run a Monitor, and thus detect misissuances and remove said logs from their list the same way they would have removed DigiNotar. I think a section specifying the actions of TLS clients should answer a lot of these questions. Such a section would say in part that clients must keep lists of CAs and log servers, maintained either by themselves or by a trusted third party, and that the signatures on the cert and the SCT should be from entities in the respective lists. Whoever maintains the list undertakes to remove both bad CAs and bad log servers if they are detected. > > Monitors also play a critical role in detecting certificate mis-issuance, for > Subjects that have requested monitoring of their certificates. Thus Monitors > represent another target for adversaries who wish to effect certificate > mis-issuance. If a Monitor is compromised by, or is complicit with, an > attacker, it will fail to alert a Subject to a mis-issued certificate > targeting the Subject. This raises the question of whether a Subject needs to > request certificate monitoring from multiple sources to guard against such > failures. Subjects must choose a trusted Monitor because the Monitor is by definition the thing that watches the logs; they can do this themselves or they can delegate to a third party, in which case they rely on that party not to be compromised. This doesn’t seem particular to CT: if I install a burglar alarm either I have to monitor it, or I have to pay someone else to monitor it and trust them to respond if it goes off, or I have to accept that the alarm might be ignored. > _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
