On 17 January 2017 at 10:30, 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?
It assumes the malicious log doesn't backdate a SCT.. It also assumes the client has a clock that is correct to the order of a few days... -tom _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
