DNS-based Authentication of Named Entities (DANE) Minutes

Meeting : IETF80, WEDNESDAY, March 30, 2011.
Location: Vienna/Madrid. 0900-1130 Morning Session I
Chairs  : Warren Kumari <warren@kumari.net>
          Ondrej Sury   <ondrej.sury@nic.cz>
Minutes : Matt Lepinski <mlepinski@bbn.com>
          Version 0
==============================================================


These notes attempt to capture the discussion at the DANE Working Group meeting of IETF 80. No attempt was made to capture information contained in the slides, which are available online. 

The primary outcomes of the meeting were:
-- Concensus was reached on the need for a use-cases and/or requirements document
-- The chairs will see that a new Internet Draft is created to capture use-cases and/or requirements. This document may be published as an RFC, or may instead be incorporated into the TLSA protocol document
-- EKR and PHB have both agreed to send use-case text to the list to help facilitate the creation of this document

Additionally:
-- PHB agreed to send text to the list regarding a proposal he had for adding an extra bit to TLSA records that would affect client validation. (This came up in the context of EKR's question on restricting vs supplanting existing validation)


============================
============================ 

*********************
**** How the Working Group Works (Chairs Presentation by Ondrej)
*********************

-- See slides (no discussion)


*********************
**** TLSA Presentation (Paul Hoffman)
*********************

-- See slides and draft-ietf-dane-protocol-06

-- Note: Paul and Jakob are editors on behalf of the working group
     ... adding to document based on working group feedback and chair consensus calls

-- Note: We do not have a clearly written problem statement

-- Presentation will be mostly review. We do not intend to close many (any) issues during this face-to-face meeting

-- Note: The authors are doing their best to be consistent with TLS and PKIX nomenclature. 
         They believe that they have the nomenclature correct in most places

-- Question (Jeff Hodges): Are you open to wording changes
    Answer: We are VERY open to wording changes. We apologize if we have given the impression that we are not open to wording changes

-- Note: On Hash Type 0
         You probably don't want to send the hash of a CA cert
         If you send the Hash of a CA cert you are assuming that the client already has the CA cert in their trust anchor store
         ... the client might, but in general this is probably not a good assumption

-- Note: It is very likely that the IANA registries for cert type will be expanded in the future
         Both with regards to Hash algorithms (e.g., SHA-3) and cert types (e.g., PGP or Bare Keys)

-- Peter Kock: I haven't seen language regarding forward compatibility
              How does a client conformant to today's specification handle a certificate or hash type that it doesn't understand
    Answer: There is text in Section 3, it wouldn't be a bad idea to put it in Section 4 as well as to make the text more explicit

-- Paul: One security concern is that you don't want a compromised CA to be able to issue certificates for you
  PHP: Without DANE or a DANE-like mechanism (e.g. CAA) 
  Paul: There is a proposal out there that  
   PHP: There is a proposal out there for which I have obtained support from the Certificate Authorities (about 60% coverage)
   PHP: The way that you are promoting DANE is driving some people away
  Randy B: We are here for the technology; let's get back to the presentation

-- Paul H: Sending text is good, don't count on the authors to create document text that correctly captures your concerns

-- Paul H: Can you hold comments until after the next presentation (we'll have an open mic)

-- Note: Please look at the diffs for new versions of the protocol document
         Draft will continue cycle, don't assume that -06 means the document is essentially done

-- Steve Kent: We had experience with IPsec where we put the mandatory-to-implement algorithms in the core document
      ... have you considered putting the mandatory-to-implement algorithms into another document?
   Ans: One caveat is that the DNSEXT working group has tried to put the mandatory-to-implement algorithms into the IANA registry
      ... This turned out to be very complex
   Russ Housley: Separate document please

-- Jim Schaad: You were very specific to say that you chain "to a CA" and not "through a CA", is this correct?
          ... this seems like a change
    Ans: We truly mean "to a CA"

-- EKR: Convention in TLS is that there is often ambiguity in what the top-level is
     Therefore, you should chain until you reach something that YOU (the client) believe is a trust anchor
     Current document reflects this approach

-- Anderew Sullivan (from Jabber room): With regards to algorithms in a separate document
       ... DNSEXT does not have experience with algorithms in a separate document, DNSEXT is currently discussing this in the working group
    Paul H: I'm sorry, what I met was that there was a lot of confusion among developers in the DNSEXT working group when the working group was discussing this approach

-- [Defer IPv6 question to later]

***************
**** DANE and PKIX (Richard Barnes)
***************

-- This presentation is really to provoke discussion

-- Note: Slide five definitions are just for the purpose of this presentation and discussion today

-- Martin Thompson: When you say add to the TA store? Do you mean add or replace?
    Answer: We mean replace
   PHP: DANE over-rides PKIX!
        When your client is doing this DANE stuff, if you don't find a DANE certificate, you reject the connection
        This is very important
        Issue: If I try to deploy DANE for my web server, my mail server will break (or vice versa)
    Chair: I believe that the port numbers in the spec keep your mail server from interfering with your web service and vice versa
       ... this was put in response to the issue Phil raised on the list
   Richard: For the purpose of the particular validation you are doing, if you get a 'type 2' DANE certificate it replaces every other TA

-- Jeff H: Is there something in the spec, where you can inherit key parameters (when you add a TA)
     ANS: It's not in the current draft, if it should be take it to the list

-- EKR: I agree the TLS spec is poorly written, the working group did not consider the terminology carefully
    ... Intent is not fuzzy, there was no intent from the working group to ban self-signed certificates
   Richard: Whatever interpretation you have of the TLS spec that you have, we can accommodate it with DANE

-- Note (name unknown at the mic) : There is an orthogonal issue that if you validate the DANE certificate, you need to manage expiration in conjunction with DNS TTLs
    ... you can use the multiple response feature of DANE to publish a new cert before the old one expires

-- Richard: PKIX folks are unhappy with using a cert that isn't validated 
     ... so if we are not going to validate the cert, it is the moral equivalent of bare keys

-- EKR: There is a fundamental question of what this work is for
     1) Cert Lock ... make it difficult for the CA to misbehave
     2) Supplanting the trust anchor infrastructure
   One is purely restrictive and the other is permissive
    ... this is related to the question of DNSSEC, and DNSSEC last hop 
        (if the goal is only 1, then DNSSEC doesn't really matter)
    In my opinion, the most compelling use-case is certificate lock

-- PHP: Plus 1 on EKR
    ... you could have a bit that says whether you want to put the restrictive [cert-locking] part
     Is the goal here to enable crypto, or to turn on the padlock icon
     If A is talking to B, in which case is it worse to encrypt?
     If you fall back to non-TLS, using anything you have (even if it's expired, or DNSSEC wasn't used or whatever) is better than not encrypting

   Chairs: Phil please send to the list ... specifically your proposal about the bit


**************
**** Open Discussion
**************

-- Steve Kent: The comments we are seeing gets back to something we touched on early
     ... The working group would benefit a lot from a clearly stated requirements / goals / problem statement

--  Paul Wouters : I am very nervous about accepting non-valid information from certificates into clients
     If you are not going to validate the certificate you should go to bare public keys
     I think that whether DANE supplants PKIX or vice-versa should be a client decision not a DANE protocol issue

-- Stefan S: I'm concerned that this [DANE] makes fishing a greater problem 
      ... this (along with IDNA) makes it easier to convince people to go to the wrong domain name
      ... EV-certs, along with visual recognition (upcoming spec) help with fishing, but does DANE defeat the protections of these mechanisms 

-- Paul H: Many applications that use TLS (not TLS itself) say that the you must get the domain name from the certificate itself
      ... DANE won't hurt people who want green bars (or whatever), as long the CA in DANE uses green bars 
          Otherwise, DANE is not providing value for these kinds of users/applications

-- Glenn Zorn: I want to second Dr. Kent's request for a problem statement and list of use-cases

-- EKR: I agree with Dr. Kent and Glenn Zorn

-- Randy: We have a document and we don't have goals or use-cases

-- Jeff H: So who is going to write to a use-case / requirements document?
   
-- EKR: Fundamental question is whether you are doing restrictive or supplemental or both

-- Paul H: We don't currently have working group consensus on this question
    Chairs; Agree

-- EKR: There is existing logic in browsers
    1) You do the browser logic and then if that passes you invoke DANE
    2) The other option is in 
   Point of the first is to protect against browser malfeasance, the second is to not have to deal with comercial CAs
   
-- PHB: Also agreeing with Steve Kent ( ) 
        I was told early on that no one wanted to deal with the requirement of helping to deal with CA mis-issuance
   PHB: I think a many people have mis-spoken and said that this DANE work will prevent CA mis-issuance 


-- Dave Crocker: The immediate task is not a requirements document, but a version of use-cases which is written as elevador pitches

-- Paul H: I'm going to put in a preference for EKR doing this writing, because he seems to be the most skilled as stating use-cases concisely

-- Glenn ZOrn: I don't want to have to go through the 
      ... I want it to be an Internet Draft, I don't care if it ends up as an RFC
      ... I see an issue-tracker as a tool for the chairs and not the working group

-- Stefan S: Agreeing with Glenn

-- Mark Andrews: Make the use-case / requirement draft permanent, it should eventually become an RFC

-- PHB: I think I've actually got most of the text
   Chairs: Phil, please sent to the list. 
           
-- EKR: [I didn't really understand EKR's point about SSl servers today]
        [I think he was saying that SSL servers that create self-signed certs today, aren't set up to make cert chains]

-- Steve K: I think that part of the motivation here, is to elevate the self-issued cert case 
       ... I think what clients are doing today (with regards to error cases or whatever) is not necessarily our goal for the future
    EKR: No argument

-- EKR: I think what Richard is proposing is putting additional load on server operators
    Paul H: But note that this is happening at the same time that they are adding code for DANE
    Steve K: They are already doing something new with certs (putting them in DNS) it shouldn't be hard to create two certificates
    
-- Stefan S: I worry that we're adding confusion that will be incompatible with existing crypto-libraries
      [I wasn't really able to follow Stefan's point]

-- Paul W: People told me that there was not much support for Bare Public Keys
      Can we re-consider that? (I sent a proposal to the list for doing this in TLS)
    Chairs: It seems that this would need to make it though TLS working group, before we can consider it in DANE
   Paul W: We need a format before I can write the TLS extension
    Paul H: Whatever the TLS working group decides on for format, this working group will accept that format

--  Martin T: On bare keys, is there any concern about the lazy administrator who leaves the key in for 10 years
      Chairs: yes, but there's no way to stop an administrator from screwing themselves
    Martin T: As an implementer of a server, as a datapoint, given the APIs that we have access to, 
          it would be difficult to generate a self-signed cert and then use it to issue another cert under it


-- PHB: We've been delving into the PKIX and Cert cruft, are we also going to get into the DNS cruft
    ... aren't we going to break CNAMEs and wildcards when we put in prefixes
   Paul H: There is an open issue for CNAMEs
   PHB: There is an open issue, but it may be an unsolvable one

-- EKR: You'll have email in your box in a second
      ... One reason that cert validation in the browser is so screwed up is that a large percentage of existing certificates is bogus
      ... only a small fraction of bogus certificates are truly bad, which creates a tension for browser vendors 
      ... Anything that you can do which causes perfectly fine certificates to throw up warnings on certificates aren't truly bad (insecure) is not helpful

-- Stephen Farrell: I agree with EKR, it's important to make this something that is better and more likely to work 
     ... please demonstrate why this is better (and not just 

-- Jeff H: Browser vendors will need to do something to implement DANE, I hope they are involved in the conversation
    Chairs: We have some browser vendors on Jabber

-- Paul H: I don't actually think that everything is a web browser
      ... for example, I get my email over PoP using TLS
      ... the interface for non-web TLS use is important
      ... the warnings that my mail client gives me when my mail server cert expires is even worse that what you are used to with the web
      ... TLSA is meant for all applications, not just web

-- <missed the name>: We are looking at using TLS within Internet of Things

-- Paul H: Someone mentioned earlier that we didn't mention IPv6
      ... In particular, 

-- Harry Helpern (W3C): The W3C sees making things less broken for web security to be a key strategic goal
        ... W3C recognizes that there is good security expertise in the IETF 
        ... If you give us clear specs to address the low-hanging fruit, we can help communicate to browser vendors
    Paul H: I think that WebSec is the most relevant working group for what your interested in

-- PHB: It's been 12 years since we started trying to get browser vendors to hard-fail on revocation (OCSP) failure
       ... If the browser vendors won't implement OCSP, hoping they implement DANE is unrealistic        

-- Scott Cantor: I think there is potential for non-browser applications
        ... I want to see an alternative to PKIX come out of this working group
        ... we may need more semantics to faciliate non-browser applications
    Paul H: We have had lots of IETF security failures with implementors mis-interpreting semantics
        ... so more semantics written into the documents is a good thing


**** DANE and S/MIME by Paul H

-- PHB: One big change from doing S/MIME vs TLS
     ... It makes sense for TLS to have EE certificates in the DNS
     ... However, for S/MIME you really want to have CA certificates in the DNS and chain to them
  Paul H: I think some people want EE certificates in the DNS for S/MIME
     ... but Phil is correct that there are internationalization issues that would need to be considered if we wanted to use the left-hand-side of an email address as a DNS search key