Public Notary Transparency (trans) IETF 102: 11:00 - 12:00 19 July 2018 Chairs: Paul Wouters, Melinda Shore Minutes by Melinda Shore (video at https://www.youtube.com/watch?v=ioxoCb9nLfM) Status update ------------- 6962-bis has six open items to resolve to be able to close the document: 1) change status from "Proposed Standard" to "Experimental Standard": There was some confusion about what was meant by "experimental." There was agreement that the revision from 6962 to 6962-bis is extremely valuable and everybody plans to implement -bis, but it's going to take some time. There didn't seem to be any objection 2) In EKR's AD review, he asked that we remove the "preventing tracking clients" claim. Andrew Ayer disagrees, as we don't know yet how gossip is going to work, and it might not be possible to deploy gossip if there's concern that it's going to lead to tracking. We'll take it to the mailing list 3) Also in EKR's AD review, he asked that we remove the "no security implications" claim. EKR was not in the room, so we'll delay discussion until he's available 4) Fotis Loukos requested that we clarify what we mean by "current NTP time." There is no proposed text. Given how late this is in the process, if someone doesn't give us text there's nothing to talk about, so if someone feels strongly about this they should contribute text. Nobody expressed concern. Fotis should produce text, or we'll drop it. 5) Using JSON format for error reporting: concern was that in some cases intermediates were being rate-limited but didn't know what the actual problem was. Corey Bonnell is going to produce text. Tim Hollebeek was concerned about making it mandatory and asked if it was going to be a SHOULD. We'll have it be a SHOULD for now, and if it works well we'll turn it into a MUST when the document is published as a proposed standard. 6) Option for CT logs to signal when rejections were due to rate limiting: this is covered by the proposal to use the JSON error reporting format Trans threat analysis --------------------- There hasn't been much progress and we don't want to keep the working group open for just this document. There doesn't seem to be much interest among working group participants. Rich Salz thinks we should flip a coin to settle the difference - he thinks the document has value. Paul and Melinda will discuss it after the meeting and take it back out to the mailing list. Other documents --------------- Gossip, binaries logging, and client behavior: if there's progress on those documents we can take it to a new working group. We don't need to remain open for those. NTIA is holding a workshop on software module transparency, and a specification may come out of that (wrt binary transparency), and Paul has a proposal for DNS transparency that doesn't reuse the CT format, so is probably a fit for another group. Redaction --------- Ben Schwartz asked about redaction and IP address certificates. Paul said that the people who are interested in working on that should write it up and organize a BOF. Tim Hollebeek said that the lack of activity on this is due entirely to the browser community, and that there are CAs who continue to be interested in doing something about redaction. None of the current methods work particularly well. Tim encouraged people who are interested in this to have discussions with browser root programs and to see if they can get some interest there, but this working group doesn't need to hang around for that. Ben pointed out that IP address certificates have very different security properties, and he's concerned about creating a situation in which there's an enumeration of every address that's ever requested an IP certificate. Tim said that IP certificates are rare and they have a number of issues, so they're being discussed actively in the CA/B Forum. Devin from Google Chrome asked why logging IP certificates is particularly concerning. Ben's use cases are services operated by clients that they want to be able to use securely from a browser but that they don't want publicly known. IPv4 addresses can be trivially enumerated but IPv6 addresses cannot, and he'd prefer if they weren't logged in CT logs. Tim pointed out that this conflicts with the "transparency" aspect of CT and he doesn't know how to weigh the tradeoffs. In existing redaction cases it turns out that people thought they were doing a better job of hiding things than they were. For example, most of the certificates not logged by Symantec ended up being logged by Google, anyway. EKR's review concerns --------------------- He's happy to go along with the working group decision on the "preventing tracking clients" text. His concern is that the text says "don't use deterministic signatures" and in the meantime the IETF is pushing people using RSA towards PSS, so those seem to be in conflict. He's not pressing towards any particular resolution. With respect to the "no security implications" text, it's fine with him. Andrew Ayer said that he thinks there was some confusion about this was in there in the first place. The original intent was anti-spam, but Andrew pointed out that it's not just anti-spam, but to link every certificate back to a certificate authority so that browsers can take action if there's a problem. So, there is a security implication and it's not just anti-spam. EKR suggested it would be useful if someone would add some text to that effect. The PR does include explanatory text. EKR: "looks good to me." He expects a new draft relatively soon. Shutting down ------------- Paul asked what happens to unfinished working items when a working group closes down. Alissa says that it's up to us, and the options are that the documents can be AD-sponsored, or they can just expire. For example, the gossip draft could potentially be AD-sponsored. Alissa said that we should keep the wg open until the -bis document is finished, and we might as well progress the other documents while we're open. Devin from Chrome asked what should be done if his group comes up with new proposals - where should those those be taken? We could potentially spin up a new working group. Chrome is hoping to have initial feedback around the time of IETF 104. EKR said that if what's found would just involve small changes, we could essentially rebadge 6962-bis as a proposed standard. If the changes are not small, we could spin up a new working group. Tim will probably have proposed improvements before 104, and he thinks they'll mostly take the form of new features rather than changes to the existing protocol. Those are better handled as new drafts rather than as -bis-bis. Alissa: close the group but keep the mailing list.