Minutes, trans working group, IETF 98 Tuesday, March 28 2017 Summary: -------- . 6962-bis still has some open issues to resolve, most have been addressed. Rest will be brought to mailing list. . will produce a draft describing how to provide stronger guarantees to clients . there are three existing proposals for how to do redaction; Symantec has implemented and deployed one of them. There is a question about whether or not redaction is compatible with transparency goals, particularly given the additional complexity it introduces . there is interest in logging binaries but the current draft is not seen as a good basis for further work Introduction ------------ Agenda-bashing Thank you to Stephen Farrell. Status update ------------- No changes to the charter, still behind schedule. 42 open tickets, many of them new. 6962-bis did not complete working group last call successfully. Several competing proposals for name redaction. Threat analysis document is stuck and we need to get this done. (Deb Cooley has since volunteered to wrap it up and get it out). CT Gossip has completed working group last call and has been sent to the IESG (many thanks to the authors, and to those who reviewed and commented). No update on CT-DNSSEC. There was some interest in the room in seeing it progress, but we need drafts. New interest in picking up work on CT-binaries, will be discussed later. 6962-bis update (Eran Messeri) ------------------------------ During wglc, received significant feedback from Mozilla, in roughly 4 categories: 1) architecture, 2) data structures, 3) editorial, and 4) http api. Goal was to provide stronger guarantees to clients. All issues have tickets in the issue tracker and almost all have been triaged. There's agreement on almost all recommended changes, and they will be brought to the working group for consensus. All of the editorial suggestions seem sensible. Please review open tickets and provide feedback. One issue that needs to go out to the mailing list is the question of whether or not the timestamp should be removed from the STH, as it doesn't help with proof of liveliness. The question of BCP 190 compliance received extensive discussion and needs to go to the mailing list as well. The goal of BCP 190 is to avoid overly constraining web application deployment by preallocating portions of the namespace. On the other hand log operators do not feel overly constrained, and this may be a case of adding complexity for no actual purpose. Richard Barnes and Eran will work together to resolve several issues around the set of artifacts a log is expected to produce, and bring it to the mailing list. No agreement on: 1) whether log IDs should be OIDs or INT32s, and 2) whether OIDs should come from an IANA-managed registry. Way forward: . Write up clarifications/suggestions in filed tickets, . Pull requests for issues where there's agreement, . Post each change to mailing list, . Hash out few remaining disagreements, and . New document to describe a variant of CT with stronger guarantees for clients Privacy and redaction --------------------- Saba Eskandarian presented a redaction proposal and privacy-preserving proofs - the problems he addresses in his work are . Private subdomains, . Privacy-preserving proof of SCT exclusion, . Actionable proofs of exclusion, . Privacy compromises, and . CT and short-lived certificates but he focused on the first two during the meeting. Work is based on a commitment scheme. Most of the concerns raised about this particular scheme apply to redaction more generally. Clint Wilson presented an overview of the state of redaction in CT, to provide background and set a baseline for further discussion. He drew a distinction between withdrawing information from a log (for example, a legal requirement to remove PII), which he said is not worth pursuing right now in the working group, and not logging sensitive information in a certificate in the first place. There are three active proposals today: . Rob Stradling's proposal, from 6962bis-17 . Saba's proposal (from earlier in the session) . Symantec's precertificate transformation extension DKG reinforced the difference between dealing with toxic data that need to be removed, on the one hand, and data in logged certificates that needs to be concealed. Wes Hardaker pointed out the inherent tension between committing to logging certificates and then complicating things considerably by choosing not to log some data. Because we were short on time, the discussion was moved to the mailing list. Logging binaries (Frank Xia) ---------------------------- Goal is to reuse CT technology to log binary (software), or its digest, to provide public auditability of software distributions. Issues raised include: . How to avoid log spam (certificates have signatures that can be verified, but how would you avoid logging random hashes? . Richard Barnes pointed to some work at Mozilla in which a digest of the binary is encoded into a domain name, put into a certificate, and the certificate is logged via CT . DKG pointed to some work going on outside the IETF with free software distributors. It is important to log identity and version of the software, and it's not clear that that's in the current draft. . Martin Thomson asked if the machinery associated with an SCT is really necessary . Adam Langley said that it needs to be tied into verifiable builds and other mechanisms associated with provable provenance . EKR said that what Mozilla is trying to accomplish is to establish confidence that when you download a version of a piece of software, you're getting the same version as everybody else. Verifiable builds are a worthy goal but a simpler mechanism is still useful . He also said that the reason Mozilla went with putting digests in certs is that there's an existing infrastructure they were able to leverage, and there are logs operating today. . Rich Salz pointed to attribute certificates as an example of certificates that do not have associated keys as a way to address both the spam issue and the identity issue. . Phill Hallam-Baker pointed to Comodo's code-signing infrastructure, and mentioned problems around differences in code signing practice among CAs. Hums taken: Is there interest in seeing this work go forward in the IETF, even if not in the trans working group? Some interest. Is this draft appropriate as a basis for this work? No.