Certificate Transparency (trans) IETF 97: 11:00 - 12:00, 15 November 2016 Chairs, Paul Wouters, Melinda Shore Minutes by Allison Mankin [The AV isn't working, so we are using imaginary slides] Status update ------------ Other items for the working group include that gossip and binary object drafts exist, but moving slowly. Melinda asks if the proponents of the binary app are in the room. Eran Messeri speaking about 6962bis update: a few issues are left. Some log operators expressed interest in limiting certs accepted - need more options for restrictions on accepting. Two ways to address: 1. reopen, find a way for clients to query to see if they were accepted 2. change MUST to SHOULD, logs that behave differently will still comply. That is Eran's proposed solution for the first issue Second issue is about a new optional API for monitoring. Some exist in the bis already, e.g. looking up a cert by its hash (versus an entry by its hash). Name Redaction -------------- THird open issue is privacy concerns: what if a cert with private info finds its way to the log and owner doesn't want it to be there, or if logs have to remove a cert because of a legal or other issues. This could be done technically. It is not the same as name redaction. Suggestion build on top of 6922bis rather than delay 6922bis in the meantime. Melinda: a goal is to have fairly minor changes and not do a whole new WGLC. Alexey Melnikov (acting AD for session) - you don't have to do another WGLC Ryan Hurst - his opinion is that the changes are all pretty minor, the biggest one is the MUST -> SHOULD and that should be policy. Alexey: if you will change MUST -> SHOULD, good idea to add some text explaining, it will help the IESG in their review. Paul asks about a PR for this change - Eran: it doesn't exist yet, but given this minor change, it's easy to do a PR Ryan H - if it was left as a MUST, pretty much all CAs would violate it anyways. Name Redaction was taken out of the base document. Eran has slides about the potential solutions. See them in the tracker as we continue to have AV problems. Definition of Name Redaction: the ability to avoid publishing domains names in the logs. Hide certain parts or the entire domain name from the log certification. Can only be done for pre-certs, not for final ones used by clients. First idea as to replace each redacted label with ? and an indicator saying how many labels were redacted. Client must reconstruct the redacted labels to check the signature. Problem is client doesn't know what was intended in the ?s from among many possibilities. Second possible solution - monitors/clients that know what the possibilities are, can verify that the labels redacted go with one. Use hashes of the redacted labels or salted hashes of them. Still have in pre-certificate. Problem with this solution is that it can be reversed by brute force attack. Third solution - salt is moved from the pre-certificate to the found certificate, making it harder for observers to undo the redaction. Spent a lot of time trying to engineer all this, complicates clients, monitors, increases protocol complexity and WG could not get to a consensus. CAs and Browsers both unhappy, and requirements weren't clear. So this become a separate document to complement 6922bis. Need to know the requirements. E.g. do you want to redact more than the DNS names. Eran offers that people also contact him directly with info on requirements and he can summarize to list, for those who aren't sure about public discussion. Paul Wouters - did they shape up a redaction draft? There is one by Rich Salz, is this the one that is in play? Eran says that Rich's document includes one of the solutions at least, and there was a need to get WG adoption. Paul Wouters - can this also be used to help with issues around personal certificates? Eran - if the personal cert needs full removal from log, it is not covered by redaction, but redaction could apply to some personal cert needs. Ryan H - personal certs are a great example where we need requirements or use cases to settle what's in the redaction draft. This new draft needs to capture scenarios more clearly, right now it's a "great tool box, something for everyone" Paul: are there personal cert issues for the bis documents. Ryan H says no. Ryan Sleevi: I think with the MUST -> SHOULD change, the bis document has no personal cert issues. Peter Bowen (remote): there's how do we technically do this, and separately, should we do this? Subject names frequently end up with personal info in them. Logs might be able to reject certs now, but it's not clear if certs should be rejected because they appear to have personal info in them. Eran: are you saying that policy change from MUST to SHOULD won't be enough for the bis to handle personal certs? Peter: no, what will we do with a cert for a website that has a first and last name in Ryan H: can we ship these issues into the redaction draft and let the bis go forward? Peter says yes. Peter: another scenario that maybe still should be in the bis document is binding of knowing who is the issuer of a cert to various certs - knowing examplecorp's CA issues newthing's cert can breach a corporate secret. This can be in the redaction draft. Final issue in bis: addition of the API for historical fetching. Eran thinks it's a nice option, but it would be good for it to be in a monitoring API document. Ryan H: someone not in the meeting would like there to be a REST API - good idea to have a broad query API rather than bolting optional APIs in the bis document. Conclusion: small update and put the document into IETF LC Eran: note he has a personal (github) reference implementation. Currently only supports add-chain and get-sth, does not validate chain. New Items --------- Two new items: Log monitoring API - no body here for this Expact CT TLS header, which will be discussed in the HTTPBIS WG on Thursday Threat analysis --------------- Chairs: Looking for a volunteer to serve as editor of the threat analysis and get it to the finish line. Eran accepts the task and he will make sure it's consistent with bis. DKG: feels a bit responsible having raised the dual-CA attack. Too much discussion, too verbose. In terms of specifically describing the dual-CA attack, the text in the latest version of the document is correct. "Haven't looked at it recently because I didn't want to retraumatize myself" Melinda: right way to break it down: delete all previous state. Take a look at current document, David's response to current doc, and nothing prior to that. David's posts are pretty self-contained. Paul endorses this view. Rich Salz: if you look in recent Chromium and Mozilla mailing lists, it's become almost an NP-Hard problem these days to figure out whether two CAs are administratively different from each other. DKG: not sure if that's relevant. There are two different particular public keys associated with two different CAs. Rich: the attack is more relevant today, because there are* multiple things under the control of one party. AOB: NONE