7 June 2017 15:08 Ryan Sleevi <[email protected]> wrote: > On Wed, Jun 7, 2017 at 8:51 AM, Magnus Ahltorp <[email protected]> wrote: >> Well, that depends on the assurance level, doesn't it? For domain-validated >> certificates, sure, but those are next to worthless anyway. It would be hard >> to hold a CA responsible for issuing them, so the need for logging them is >> really small. > > Let's not introduce CAs' marketing distinction into the technical discussion. > > Domain validated certificates - the basis for the Web PKI - are the only > security level that matter. The holder of such a certificate can impersonate > any site named in the certificate - whether from example.com to google.com. > > The other forms of certificates, "Organizationally Validated" or "Extended > Validation", or, in the EU, Qualified Website Authentication Certificates, > while nominally trying to provide higher assurance, do not meaningfully do so > in the security model of the Web (which is the Origin). > > To that end, the past decade of CA misissuance responses have come down, in > part, to the misissuance of certificates that attest to a websites identity, > and CAs have been held responsible. > > I can totally appreciate a perspective that believes that CAs' human > processes are far more secure than their automated processes, even if that > perspective is not supported by the data. However, if we accept that - from a > pragmatic and practical security perspective - that identifying a website > grants the capability of TLS termination (namely, lacking an EKU or having an > id-kp-serverAuth EKU, and naming one or more dNSName or iPAddress identities > in a SAN) - then these certificates are very much in scope of the Web PKI, > and thus need to be logged, as they present risk to the Web PKI consumers.
CAs cannot be held responsible for domain-validated certificates for the simple reason that they don't have documentation, and therefore cannot be required to produce documentation, which means that they can claim anything. > > > Certificate is used immediately, only with SCT: Clients accept > > > certificates only with SCTs for a limited duration; after that an > > > inclusion proof must be accompanied [4]. > > > [4] That requires auditing logs asynchronously, since an attacker with > > > persistent access could keep getting new SCTs issued, or some clients may > > > not have fresh STHs because they missed some updates. > > > > This seems potentially promising but I think it has some flaws. Would this > > auditing be done by the logs themselves, or by monitors? IIUC, logs are > > allowed to produce infinite SCTs for the same cert once they've logged it, > > and they don't have to produce the list of SCTs they've signed. So the only > > party that could meaningfully audit for excessive SCT generation would be > > the log itself, which is the party we're trying to defend against. > > If we are talking about "limited duration" of SCTs, we are talking about the > age of the timestamp in the SCT. Each timestamp that is used to generate an > SCT is required to be logged in the log. That is what the log is logging, > cert+timestamp. > > I think this may have resulted from a misunderstanding. I'll try to explain > one such scenario. > > Consider at T=0, Certificate X is logged, and an SCT(X, 0) is issued. The > proof that such SCT has been incorporated into the STH will not be required > until T=24, so such a certificate can be used (without proof of inclusion) > from T=0 to T=24. > > Now, if I am a malicious CA, a T=23, I approach the log again, and request > SCT(X, 23). The log, colluding with the CA, issues SCT(X, 23) - rather than > the expect SCT(X, 0). Further, the log does not incorporate the SCT(X, 0) > into STH(24) - it silently discards it. > > Clients will not expect to see a proof of this inclusion until STH(47) - that > is, SCT(X, 23) + 24. > > On T=46, I repeat this process, obtaining SCT(X, 46), and clients not > expecting this until STH(70). > > By the CA and Log colluding, I can continue to extend the period upon which > I, the Evil Log, do not log this certificate. > > This situation arises because the SCTs can be delivered through multiple > means, so it does not necessarily need to be fixed in the certificate. Yet > even if it was fixed in the certificate, so long as I, the Evil Server, stop > serving the cert prior to T=24, clients won't check the inclusion proof. This > is why it was remarked that some form of auditing - of the SCTs produced by > the log - would need to be asynchronously done, to ensure that SCT(X, 0) > wasn't 'extended' beyond that. It is definitely possible to generate new timestamps and not log them, but I was rebutting "they don't have to produce the list of SCTs they've signed", which is not true, unless "don't have to" is different from "not required to". Logs are required to produce the list of all timestamps they have signed when MMD has passed. That is what it means to be a log. /Magnus _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
