Minutes for TRANS at IETF-90
minutes-90-trans-1

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