IETF Public Notary Transparency Working Group 9:00 - 11:30 EDT, Friday 25 July 2014 Minutes by Karen O'Donoghue, summary by Melinda Shore 1) agenda bashing, administrivia 2) status update We have a new co-chair, Paul Wouters. The working group has a single milestone, getting the 6962-bis draft through working group last call and to the IESG in December 2014. Quick survey of who's doing implementations turned up 3; we will take that question to the mailing list, as well. 3) open issues in the working group issue tracker Eran Messeri ran through the list of open issues in the IETF trac issue tracker (https://trac.tools.ietf.org/wg/trans/trac/report/1). The document editors agreed that the issue tracker contents should be complete - that is, there should be tickets for each issue that needs to be closed for the document to be ready for working group last call. There was active discussion of the following tickets; see minutes below or listen to the audio log for more complete details. These were the tickets on which there was some disagreement and which need to be taken to the mailing list: Ticket 21: clarify the purpose and mechanism behind the log's signature checks Ticket 23: how can TLS clients match an SCT to a certificate Ticket 26: Precertificate format 4) 6962-bis Ben Laurie discussed the current state of the draft and what needs to be done before working group last call. This includes a gossip protocol, client behavior, and anything else. Linus Nordberg volunteered to produce a draft on gossip protocols more generally. The question of whether or not the CT gossip protocol ought to be pulled out of 6962-bis and produced as a separate, likely experimental RFC will be taken to the mailing list. The question of whether or not client behavior should be specified in a separate document also needs to be taken to the list. 5) CT for DNSSEC Dacheng Zhang presented a very early draft for DNSSEC logging. This received a mixed reception, in large part because of scaling problems. Considerable interest in further discussion, though. 6) CT for signed executable software Dacheng Zhang discussed the use of CT for logging executable signatures. There is not a draft yet, but there was considerable interest in seeing one. ============ raw minutes TRANS WG @ IETF90 9:00 - 11:30 EDT, Friday 25 July 2014 Manitoba Room Agenda:   https://www.ietf.org/proceedings/90/agenda/agenda-90-trans Chairs: Melinda Shore and Paul Wouters WG Agenda, Status, Milestone Review, and Implementation:  https://www.ietf.org/proceedings/90/slides/slides-90-trans-4.pdf Melinda covered all the administrivia including the Note Well, blue sheets, jabber scribe (Wendy Seltzer), and minutes (Karen O'Donoghue). She also welcomed Paul Wouters as the new and much appreciated working group co-chair. Finally, Melinda reminded the working group of the single milestone (RFC 6962-bis) in the charter (https://tools.ietf.org/wg/trans/charters).  Melinda asked the room who was working on implementations. There were at least three implementations in addition to the Goggle implementation. It was further clarified that these implementations were the log server component. Akamain and PHB indicated plans for internal implementations, and Linus Nordberg mentioned his plans for an open implementation. Google indicated that they are also working on the client side and a monitor.  Open Issues =========== Eran Messeri went through the open issues in the Issue tracker.  Issue tracker: https://trac.tools.ietf.org/wg/trans/trac/report/1 Slides: https://tools.ietf.org/agenda/90/slides/slides-90-trans-0.pdf See slides for all the tickets discussed by Eran. Tickets resulting in discussion are noted below:       Ticket 21: Clarify the purpose (& mechanism) behind signature checking the log performs. Steve Kent: A minimal set of checks is not sufficient. We should specify "the" set of checks. Allowing additional checks beyond a minimal subset leads to variation which you don't want.  Ben Laurie: Sounds reasonable.  Leif Johanson: What about if someone with a valid certificate tries to put it in after someone has already put in an invalid certificate.  Ben Laurie: Inclusion in the log doesn't say anything about the validity. The only check is to ensure that the signature chains to a valid CA.  Daniel Kahl Gilmore: From an auditing perspecive, would rather have a bad certificate in the log so we can find it.  Ticket 23:How can TLS clients match SCT to a certificate? (since they can be for non-EE certs) Steve Kent: Important point - this is going to take some effort to get right.  Eran: Should be discussed on the list Ticket 24: Logs metadata  Steve Kent: There needs to be a standardized way of doing it.  Ben Laurie: Clients trusting logs is like clients trusting CAs. Different clients will have different criteria for which logs to trust.  SK: actually talking about the metadata, contents  paul HOffman: completely disagree with Steve, it is fine that there must be one way that a log server must provide it. A client should not be forced to get it in a particular way Should be nothing about how clients must be able to get it. PHB: interop is not the only reason to put something in a spec.  Wes Hardaker: leveling up... work isn't complete, needs much more specification.  Leif : not worried about full specification, syntax is what we need to be worried about. SK:  BL: If you allow the log to specify its own Eran: Agree with Leif and Stephen, specify a format for the metadata. Can't specify how the clients get the metadata.  Melinda Shore: sensing agreement to specify a mandatory metadata format for the log servers.  Ticket 26: SK: Adding precertificates are adding complexity. Can we kill it off and simplify.  BL: We know that it is a decade long process to roll out across the Internet 6962-bis (Ben) ◦ current state ◦ what needs to be done between now and working group last call ◦ gossip protocol ◦ client behavior ◦ anything else potential new work ◦ logging dnssec (Dacheng) ◦ logging binary (executable) signatures (Dacheng) ◦ other proposals any other business? Ben Laurie, What between now and last call?  http://tools.ietf.org/agenda/90/slides/slides-90-trans-2.pdf log migration:  Basic plan: Shut down old log and start up new log. Old log stays with its entries. New log goes from there.  Gossip: SK: All clients... are you saying that TLS browsers are going to do this?  BL: If you want to defend from a split view attack, then you need to do this.  SK: This is an example of where not having a threat discussion is an issue.  BL: WE should have a threat model, and I"m happy to work on that.  PHB: I would prefer this isn't part of the core. Turtles all the way down. Not convinced this is the way to do it.  Linus Nordberg: Interested in gossip protocols outside of CT, would be interested in talking on general terms about this, willing to write a draft.  ML: Question for the list after this meeting is whether or not the to pull the gossip portions out of the core and putting it in a separate draft.  Leif: Great to have this written up in a draft so we can play with it. There is nothing stopping us from  Private Domain Labels: SK: Two observations: moderately complex mechanism that is not part of the original design, security considerations not sufficient, if we are going to continue with this we need to be clear when you really shouldn't do this Wes Hardaker: The word "internal" is an issue. There are instances where  Rick (Andrews) Symantech - many of our large customers , does make the spec more complex, it might simplify things if this were the only option, public option not a necesity, could do with just the private option.  Wendy Seltzer (from jabber): is that internal names or hostnames BL: hostnames      Client Behavior:  SK: need more specification ML: When, where, and how do you think this should be specified.  PH: Pull client behavior out into a separate and be explicit why there is no client behavior in the core document.  ML: Is there anybody who does not think we should pull this material into a separate document: SK: If we don't have any mandated client behaviors we just have a collection of mechanisms.  Rick Salz: I don't share Steve's concern.  Wes Hardaker: I do share Steve's concern.  BL: Not saying we have no idea how to do this, we are saying we are reluctant to nail down anything at this point.  Leif: Can we just do something?  PHB:  SK: This is supposed to be standards track.. this is a big enough deal to get something out really quick.  Wes Hardaker: What's the rush? Why are we trying to fast track one part of the standard.  Stephen Farrell: We are at the proposed standard stage. Don't go overboard on process.  Paul Hoffman: We talk about clients, we don't talk about client behavior.  Eric Burger (via jabber): Is it the end of the world to have two documents Paul HOffman: document needs a changes fro the RFC section...  Presentation of unchartered work for discussion purposes.  Certificate Transparency for Domain Name System Security Extensions  Dacheng Zhang  draft-zhang-ct-dnssec-trans-00  http://tools.ietf.org/agenda/90/slides/slides-90-trans-1.pdf BL: On the threat model,  (missed some comments and his answers to the four questions) Wes Hardaker: can't do CT for everybody, and if you can't do it for everybody you can't get anything out of it, fail to see how this is going to work on the deployment and validation side. But, having a log is useful for auditing.  Paul Hoffman: what would we use this for? For auditing yes, maybe other users.  Paul Wouters: I think there is a value in doing this.  Dan York: It is really critical to think about scoping this. Also, a bootstrapping issue. Actors need to be more clearly specified. Validation could be challenging  Casey Deccio: (missed points... ) Stephane Bortzmeyer - don't like this (heat related zone out...) (missed discussion involving Wes, Paul Wouters, DGH, and Dan York) Stephane Bortzmeyer... DNSSec is difficult enough so adding anything else from an operational point of view is madness.  Dan York: Key will be how you scope this, could be an extra switch in validation that could be  Certificate Transparency for Signed Executable Software Dacheng Zhang  (no draft yet)  http://tools.ietf.org/agenda/90/slides/slides-90-trans-3.pdf Wes Hardaker: How does this help you  Paul Hoffman: This log has more opportunity to be spammed than even the DNS log.  Linus Nordberg: This is the binary that I have produced.  DHG: I think this is useful...  PHB: distinction between evidence and proof BL: With a freebsd hat on, echoing DHG, we think this is useful... logging hashes of binaries seems less useful than logging binaries themselves Rich Salz: We are interested in logging binaries Melinda Shore... couple of quick  CT on DNSSEC: worth pursuing ~10, who objects to pursuing this -1 CT for binaries: worth pursuing ~10, who objects to pursuing this 0 Meeting adjourned: 11:13 am