On Tue, 17 Jan 2017 16:30:23 +0000 Rob Stradling <[email protected]> wrote:
> On 17/01/17 15:34, Paul Wouters wrote: > <snip> > > So I think there might be a different perception here of the goal of > > CT. I think you are looking at a 100% catch-before-it-happens > > scenario. While the document is only about "exposing rogue parties". > <snip> > > So personally, I would like to know that ACME-style issued > > certificates would start being accepted within a few minutes. At > > least for those sites that did not have a certificate before. If we > > are talking about renewing, then it should be able to properly > > submit new entries to log before actually activating the new certs, > > so some latency wouldn't matter. > > Forking the thread to propose an idea: > > Let a domain owner specify (perhaps via an extension to the proposed > Expect-CT HTTP header?) the minimum age of each SCT that TLS clients > may accept when establishing TLS connections to servers within that > domain space. (I'm imagining that minimum SCT ages would typically > be measured in days, rather than weeks or months). > > This mechanism would transform CT from a detection system to a > prevention system. Well, sort of. Since each cert for that domain > space would have to be publicly logged some number of days in advance > of it being used, the legitimate domain owner would have a window of > opportunity to detect a misissued cert (and request that it be > revoked) before an attacker could actually use it for their nefarious > purposes. > > Of course, the downside of this mechanism is that it's a footgun. If > a domain owner forgets to obtain a cert and to publicly log it > sufficiently far in advance, there will be a period of time during > which they can't serve a compliant cert to TLS clients, even if they > have a correctly issued cert ready to go. > > Any comments? I think it's a good idea. It's a footgun, but it's much safer than HPKP, since the minimum SCT age needn't be more than a few days. If you screw up HPKP, you're bricked until the pins expire, which could be months. I would like to propose a similar mechanism that tells the client to expect that an inclusion proof be included in the TLS handshake. This will save clients from having to validate the SCT, which is fraught with difficulty. This is a worse footgun, since it will lock server operators into using a TLS server implementation that supports inclusion proofs, but this will become less bad as more TLS servers add support. It's still safer than HPKP. Regards, Andrew _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
