Certificate Transparency BOF ============================ Date: 2012-11-06 11:44:46 PST Table of Contents ================= 1 standard up front stuff: 2 Introduction 3 draft-laurie-pki-sunlight 3.1 Requirements 3.2 Solution 3.3 Monitors 3.4 Trials 3.5 Threats 3.6 Deployment 3.7 Questions 4 Decoupling Deployment in CT -- PHB 5 Next steps 5.1 Questions about future: 1 standard up front stuff: =========================== BOF Chair: Paul Hoffman Minutes: Wes Hardaker Jabber: Yoav Nir 2 Introduction =============== + Question; what should we do with the (sunlight) draft? + what's the purpose: WG sponsored draft? 3 draft-laurie-pki-sunlight ============================ (presented by Adam Langley) + certificate transparency is about making certificates public record + Why? + CAs used to consider their data as customer lists + Want to know what's out there for a given domain + for existing + for a domain name you just bought + There are enterprises don't want some things public, and that's out of scope. 3.1 Requirements ----------------- + Want something stronger than just asking the CAs to pre-publish everything + Can't upgrade every https server on the planet during a flag day + Can't make blocking lookups in certificate validation + (IE, no requirements on third-parties) 3.2 Solution ------------- + Straw-man: just ask the CAs to publish things + Logs can say "yes we've received it", and "we will publish it" + A TLS client would receive a verifiable log message with a server cert, and the log message may say "we will publish this in the future" but it may not be now + From the log it should be able to query the PKI path to a root + Auditors need to make sure that the trees that are published are known to the world + During the time where the log is published, but the certificate is not, it is not considered a public certificate + during that time the certificate is considered to be 'valid' + there is a delay between the log publication and the certificate publication (and there is a window where something bad? could happen) + Paul H: how long is that window now? + 1 hour or so 3.3 Monitors ------------- + Expect applications to be written to do monitoring, like "send me email when a new certificate for example.com is published" 3.4 Trials ----------- + Tried putting it in the certificate bundle + broke old versions of android, IIS, ... + Tried wedging it into leaf certificate + worked fairly well, but not java + Tried to put it in the signed part of the certificate, but that has issues with the fact it hasn't been created yet + Can put it (SCTs) in a OCSP response + want to support RFC4680; can put logs in the supplemental data field 3.5 Threats ------------ + Have to make sure the logs don't contain spammed data + Logs must chain up to the reasonable root set (eg, mozilla, IE, ...) + and they must promise not to spam the log + If you have internal names, need to be able to say don't broadcast these 3.6 Deployment --------------- + Might start deploying the same as HSTS + Domain based opt-in for certain sites + Want to get to the point it's everywhere + Can pick a new future data where "every certificate must conform" + Some CAs are starting experimental tests 3.7 Questions -------------- + Stephan: you want to prevent spam. What do I submit for a log? + The certificate and the full chain (and the chain is checked). Only the end certificate is logged. + PHB: There are two parts: a notary infrastructure, and the CA infrastructure. There are two separate problems there. It would be nice to have a generic notary that someone could publish other data into promises/statements into the log. + The log technology should be reusable, but to prevent spam we're only going to accept certain things + PHB: what do we do if we come across a certificate which is not in the log but is otherwise ok? Options: 1. Accept 2. Reject 3. Connect but turn off padlock item 4. So the suggestion is don't make CT too expensive? (PHB: yes) Detailed opint + EKR: I assumed eventual goal was to have all browsers reject anything without a CT log + Yes + EKR: But that will only work if all CAs cooperate It's true that this is an ambitious proposal, + EKR: there are some sites that issue so many certificates that they don't know what they've done, and wouldn't look at the logs + This is an auditing scheme not a ?? scheme + Brad: Can't we prepopulate the log with known certs or from crawling data? + yes but we can't make sites prove they've included it + Jim Galvin: worries about large data + we want to use DNS and other caching infrastructures to help + Jim: is there one central place for a log? + No but there is many logs but each one has to be consistent + ?: What type of protocol does this run over and documentation structure? + current draft uses TLS like language, and that's what we were thinking of. + Danny McPherson: what about DANE and things that won't be in the logs? + DANE won't be allowed to be an end-run around this system. Logs would have to accept DNSSEC serialized signatures. + Google is about to rip the DANE support out of chrome + Jim Fenton: wondering how this work in a corp or gov where they might operate their own CA or a delegated CA? In some cases the users might bring in devices into these environments too? Won't this make internal certificates look bad? + [missed the response] + Erik: what's the gap analysis between the deployment of DANE and this coming to fruition? + DANE in exclusion mode (type 1/2); this is an audit system not a control system. DANE really solves a different problem. + Erik: auth of the certificate comes from external system + if the clients want both certificate transparency and DANE, then you don't want DANE to end-run around CT. So CT must audit everything, and we don't want to audit everything "but this set [DANE]". + You may trust DNSSEC enough that you don't want to audit it, but I think I'd want to audit it + Peter K: logging certificates DANE + there are no clients currently thinking of doing both CT and DANE. But I think we do want to audit DNSSEC + Peter: It's not just internal names that a problem, but you also don't want to publish external but not-published names. + yes: we are saying that all certificates must be published records + Peter: so I can't keep my domain names secret? + no, not if you don't want the world to connect with it + PHB: i think you definitely think that you want DANE certs logged. Because if I'm an enterprise that doesn't want to do DANE, then I want to check all logs for making sure no one else has published anything for me + EKR: too much too fast + the question is "when the log shows a problem, what's the mechanism". We still need to handle supporting revocation, etc. + Danny: Are you planning on block based on this data? + intent is in the long term then the certificate is not accepted, so we'd reject certificates that aren't logged + Me: lots of stuff + PKB: everyone is complaining that CT doesn't play nicely with DANE, but no one said that DANE has to play nicely with PKIX + ?: you've used the phrase auditing a lot, but i don't think that's what you're talking about + the client can only check for the pre-req to be audited + [missed more] + ?: the revocation mechansim is a core part of the security mechansim + Jeff Hodges: the whole transparency routine might be helpful in a private PKI, and I think that you need to be clear about that "not being public". + There is nothing preventing you from saying if you use these CAs, use these CT logs, ... There is nothing preventing that, but I'm not going to write code for it. + ?: Previously people have worried that there has been a concerned that there may be monopolies, but they could be self-auditing in that we need to simply remove anyone that says they won't publish their logs + right + ?: There is a group of people that think DANE is good enough, and I don't think it is, but that would be a good discussion to have. + PHB: how can you use the CT mechanism to help secure DNSSEC. DNSSEC will have issues in 10 years time and CT looks interesting in that context. 4 Decoupling Deployment in CT -- PHB ===================================== + Getting buy in from CAs is multi-step + I'm willing to reveal my certificates if they're willing to show theirs + Want to get a downpayment now on disclosing something about the certificates now (maybe just the serial number, etc). + maybe I can start publishing CT lists for my competitors since I'm crawling them anyway + Paul H: do you mean publishing them or them and you? + I meant them and me, but I could see just them too + final proposal: do CT but in a weak mode first, to try and convince people forward in steps to make it faster in the end 5 Next steps ============= + + steps? + individual + WG based + author's position: we'll do whatever the AD suggests + EKR: experimental seems the right track first, with IETF last call + at what stage should we publish it + Stephen Ferrel: if it makes sense to spit off part of this, then lets do that. I don't think taking 16 AD sponsored, intertwined, documents is the right approach and a WG is needed. + PHB: It's important to keep this under IETF IPR rules. It'd also be useful to have a workshop. + Paul H: you mean a interim BOF + Stephen: or IAB workshop 5.1 Questions about future: ---------------------------- + Hum: does someone want to form a WG real soon now, or leave it on mailing list and brought to an AD without a WG in the future for last call? + little stronger for continuing as is + Stephen: my bias is more toward doing an experimental RFC and then doing a WG + PHB: I'm not that set whether it's experimental now or WG now. But in order to get CAs bought into it unless we go to a WG. Trying to get a buy-in that we need to change a CA is hard. CAs are complicated organizations and not primarily technical organizations. + Warren: A WG helps create the illusion that there is a group, so I think that's right. It helps focus people's work. + Danny: I think this a good area for an IAB workshop. + Adam: we've only documented things we know, and there are many things not documented yet because we don't. + EKR: this sounds half-baked and still being worked on. + Hum again: + diminished support for a WG now + Hum: should do at IETF or away? + IETF: very many + Smaller number for crazy run away: 1