DANE Minutes IETF 84

**** DANE for Mail by Paul Hoffman (on behalf of Tony Finch)
Slides: http://www.ietf.org/proceedings/84/slides/slides-84-dane-1.pdf

First half of the presentation is about SMTP

-- Pete Resnick: TLS for SRTP document doesn't even specify the security semantics that the draft is attempting to capture. This is important.
    ... The DANE part is pretty straightforward once all of the other related questions in the draft have been answered.
    ... All of the other work (e.g. fixing starttls) needs to be done before we start trying to specify how to do DANE for SRTP
-- Paul ???: I have some comments on hardfail versus softfail in Section 3.2
   Answer: This gets back to what Pete was saying, whether to do hardfail versus softfail depends on semantics in starttls that have not been well-specified
-- Andrew Sullivan: Currently proposed mechanism (for signalling/tracking) may be crappy, but this is something we should definitely do (otherwise we will want it later and it will be a pain to add)
   Alexey M: All of this stuff can be easily fit into existing fields

-- Tony F: Comment to Alexy about 'transmitted' -- it is added by the client whereas 'received' is added by the client
   Pete Resnick: My guess is that we don't want to use TLS in SRTP for anything beyond, are you the domain name I was looking for. Further authentication is probably not useful.

Second half of the presentation is about MUA

-- Pete Resnick: This is something is architectually broken in DANE. You should not have chosen to do port number. In many cases what you want is to get authentication (cert) for the Service Name, and not the port number
   Answer: We may need to add a new RRTYPE 
-- Pete Resnick: The question is whether you are just securing the communication, or whether you are also securing the identity

-- Richard B: There is nothing about port number in the records. This is a fairly lightweight change since we are only changing the discovery of the records.

-- Tony F: To pete, in my drafts port number is not a problem because DANE is coming after the service->port lookup.
   Pete Resnick: Yes, but we may ultimately decide that we want to do the authentication differently than what you currently have in your drafts
-- Andrew Sullivan: Disagreeing with Richard. Changing the use of underscore for scoping is not a minor change. (It is no different than changing the RRTYPE)

-- Peter Koch: SRV chaining and MX chaining are essentially the same semantics
   Pete Resnick: DNS-wise they are equivalent, but from an applications layer point of view they may be used slightly differently

**** DANE SMIME by Paul Hoffman

-- Jim Schaad: Left-hand sides are case-insensative
    Answer: Not true, they "may" be case-insensative, depends on the mail server. They are protocol case-sensative, but often server case-insensative.
-- Mark Andrews: It seems that we will need rules for normalization the left-hand side, and then put this in the DNS (the rules for the normalizing for a given mail server should be published in the DNS)
   Answer: Let's take this offline. This may be work for the EAI working group.

-- Richard Barnes: Let's try to avoid the infinite well of nomalization . We should consider the privacy considerations for this. (Putting personal contact information in the DNS. For example, use hash of Left-hand-side to avoid tree-walking, or recursive-resolver caching.)

-- Dan York: I agree with Richard Barnes on privacy.

-- Tony F: I expect that most deployments will use wildcards rather than per-user records
     ... Normalization rules give me a massive amount of fear and loathing

-- Stephen Farrel: If we are going to move forward with this, I would like to have more assurance that there are actually people interesting in using this.
     Paul Hoffman: There are use-cases for this, we will make them more public on the list. (... mentions "mail VPNs")

-- Tony F: "Mail VPNs" are just a work around for the lack of draft-fanf-dane-smtp

**** DANE XMPP by Matt Miller

Pete Resnick: Current RFC for DANE, does it require DNSSEC?
     Answer: Yes
Pete Resnick: I am pretty sure what we want is the target. DNSSEC assures you that the delegation is right (even without DANE). So what we need for DANE is to make sure that we are talking to the right target. 

Note: POSH is for the case where we don't have DNSSEC

Richard Barnes: What Pete says is correct provided that you have DNSSEC for all the domains (not just the source domain), because there

Pete Koch: All DNSSEC gives you is that the response hasn't been tampered with in transit.
   ... Pete Resnick: Violent agreement. All you are assured of is that the record is legitmately in the zone that I have control over.
   Pete Koch: No, DNSSEC doesn't gaurantee the legitimacy of the presence of the record. DNSSEC says whether or not some record is actually in the zone file, not whether it 'should' (legitimately) be there.

Richard Barnes: We can't solve the opsec provisioning problem, period. There will always be that gap.

Pete Resnick: Yes, there is a gap, but it is not a gap that any of us in app really care about.

Tony F: This delegation problem is the same (or worse) in the mail case

Wes Hardaker: You have documents for how to do this in DNS and how to do this in HTTP. If you are going to publish both of these, then there needs to be a clear statement of which has precident if they are both present and they conflict.

Richard Barnes: There is a protocol here prior to authentication that could be used to negotiate proof type. 
   ... Matt Miller: We ahve thought about doing some type of proof type negotiation but we haven't put it into any draft because we are not sure if it is trustworthy. (E.g., downgrade attacks)
**** Future of DANE by the Chairs

Note: DANE is only a half-year late, which is pretty good for the IETF

Note: Seems to be no interest in IPsec which is in the charter. (Chairs thus suggest removing it)

-- Paul Hoffman: SMIME is probably ready for some last discussion. However, there needs to be a lot of discussion of mail outside the working group (SMTP + MUA). I suggest that the working group go into haiatus. (With haiatus deadline being a milestone of when APPS area gives us guidence on mail and XMPP.)

-- Paul Wonters: There is IPsec interest. However, this could be done in IPSECME
   ... Paul Hoffman: IPSECME is also trying to shut down. I don't want this in the IPSECME working group, especially if this is something that I and Paul could easily figure out ourselves now that DANE TLS is done.
-- Andrew Sullivan: Every working group that I know of that tried to go into Haiatus has gotten new work (which it generally hasn't been able to get done). I think haiatus is a bad idea, working groups are not good at haiatus.

-- Richard Barnes: I think DANE could try to write a general "delegation in DANE" document that is mail vs xmpp agnostic.

-- Matt Miller: Haiatus would be a bad thing. XMPP needs something soon, we don't want to have our work in XMPP derailed because DANE goes on haiatus.

-- Olafur Gudmundsson: Haiatus doesn't work. Doing DANE for any protocol is easy ... except for all of the corner cases that people didn't think about when they wrote the original protocol document. 

-- Murray Kucherawy: I am interested in the "fanf" drafts, but I worry that if DANE disappears that these drafts will end up in one of my working groups ... which would be bad.

-- Pete Resnick (as APP AD): A lot of what we have heard in this meeting, is that the work in indirection (that Richard was talking about) has more to do with getting the semantics straight. And once we understand the semantics, the DANE work might be a no-op.

-- Warren Kumari: We have had (security) semantics issues in APPS protocols for a long time, but the existance of DANE seems to be bringing these issues to the foreground ... which might be a good thing.

-- Paul Hoffman: Withdrawls haiatus suggestion. Suggests that we charter to do SMIME and a general-purpose delegation draft, and nothing else. (Charter should make it clear that this group will not do any work on any apps protocols until we get clear guidence on semantics from the apps area.)

-- Wes Hardaker: We need to recharter for those things that span a wide variety of protocols. I think there is a delegation problem that spans a wide variety of protocols. We have the right collection of security/apps/dns experts coming  to this room to and so we should keep this group together.

-- Elliot Lear: Is there a general deployment problem that requires general guidence from DANE? We might not have enough operational experience yet with DANE to answer this question.

-- Pete Resnick: Wes, if it turns out to be the case that all of these applications don't actually need redirection, and there are no DANE-specific question, is  there still a reason to keep the group together?

-- Wes Hardaker: Yes. I think there is a security / delegation problem that people in this room have already begun to understand but if we try and do it in another group we will spend forever getting that group to understand what DANE has already struggled to understand.

-- Stephen Farrel: Sounds like no one wants to do this haiatus thing, but there are some drafts that could be on a new charter
   ... but this group should not become a phychiatrist's couch [for other workigng groups?]

-- Eric Osterweil: We don't know whether there is anything general to learn. But the only way we figure that out is by trying to get DANE to work with a bunch of different protocols. Also, I believe that this group has been a very useful touchstone to bring together a group of people to have valuable discussions about other protocols that wouldn't have happened otherwise.

-- Paul Hoffman: If we recharter, we should not recharter with Tony's draft (initially). We should charter around something like what Richard volunteered to write.

-- Stephen Farrel: We don't put something about redirection in the charter until there is a concrete draft that has been written (and hopefully read by a few people)

-- Russ Houseley: If you are considering rechartering, ask yourself the BOF questions ... recharter if and only if you have sufficient answers to these questions.

-- Eric Osterweil: Don't try to generalize before we have done some work on drafts for individual protocols