IETF 81 - DANE ------------- Summary ------------- Draft-ietf-dane-use-cases has passed working group last call. Thanks to all who reviewed that document. The chairs believe the DANE protocol document (draft-ietf-dane-protocol) is almost fully baked. The chairs hope to resolve the few outstanding issues quickly and complete a working group last call before Taipei. If you haven't read the protocol document recently, now would be a wonderful time to do so. Note that the -09 version of the protocol document was published during IETF week and contains text in Appendix A on the issues of CNAMEs and Wildcards. The issue was raised at the meeting as to whether the working group needs an operations draft. No conclusion was reached at the meeting but there appeared to be some support for such a document. (This issue came up both in the use-cases presentation as well as the discussion of securing the last-hop of DNSSEC.) After the current protocol document is completed, there appeared to be some interest in doing work on the use of DANE with IPsec and the use of DANE with S/MIME. (Note that both IPsec and S/MIME are called out in the current charter.) No one expressed interest in any topics for future work which are not on the current charter. -------------- Raw Notes -------------- **** Use-Cases (Richard Barnes) -- -- Jim Schaad: I believe you mean "Chain to or chain through" for use-case #1 Answer: Jim is correct, slide is wrong -- Jim Schaad sent in more detailed text on delegated services, do we want to include that in the use-cases document ... or are Jim's concerns better addressed in the Protocol document? -- Jim Schaad: I assumed it would be addressed in the protocol (or a later operations draft) -- Paul H: I don't think Jim's text is appropriate in the Protocol document. We haven't given thought to an operations draft yet Warren (Chair): We will open on the list the issue of whether this group wants to do an operations draft **** DNSSEC Serialization (Paul Hoffman) -- This presentation is not specifically related to DANE, but it doesn't have a home in the IETF and it has been discussed on the DANE list (A related presentation was given in TLS at IETF 81 ... Interested parties could grab the audio recording of that session) -- Jeff Hodges: Note that Dan Kaminsky and Adam Langley have code for this Paul H: ... but the current code does not match the current version of Adam Langley's draft -- Steve Kent: If the Client can't get DNSSEC at all, then how do they have the root data to verify the DNSSEC blob you are giving them Paul H: Assume that client has out-of-band been configured with at least DNSSEC root information Steve K: There is an automated procedure once you have a root for getting updates to the DNSSEC root Steve K: If the client doesn't have online access to DNSSEC information, then we can't assume that what the client has is still useful/correct -- PHB: I don't think anyone who writes a client is going to depend solely on the ICANN automated mechanism There is a requirement that if you depend on DANE that you have a solution for the Root rollover problem There are many solutions to the Root rollover, including browser data configured out of band -- Eric Osterweil: I would like us to stop conflating issues E.g., root key rollover, where the validation occurs, etc Part of the reason this ends up conflated is that it starts with running code, which of course conflates many issues Serializing the dynamic DNSEC chain of trust and making it static, which can cause stale-ness -- Stephen Farrell AD: Maybe the working group should do its working group stuff. Let's not spend too much time on this. -- Peter Koch: I'm confused, this seems to me to be a solution in search of a problem What is being suggested is that DNSSEC (a mechanism to secure the transport of the DNSSEC) Paul H: No, it's not the transport, DNSSEC give you origin assurance for the data Peter K: I don't see what this is good for, and it will be an operational nightmare due to staleness and timeouts, keyrollovers You are taking a snapshot and putting it in a blob and people can look at it and see something that was true in the DNS at some point in the past Paul H: We can spec this so that the data you get is just as fresh as if you had gotten the data normally through the DNS Peter K: Is it a real world operation problem that my grandma blocks certain types of DNS records, is this a real operational problem? Warren Kumari: Yes, it is ... I experienced this when I first arrived at the Hilton Peter K: If you think you want DNS, but you don't want all of its operational features, then Warren Kumari: I see this as having some value, at least as a transition mechanism Peter K: I think the general view this week on transition mechanisms, has been lack of enthusiasm, I have a lack of enthusiasm for this idea as well Paul H: I don't view this as a transition mechanism PHB: Adam L's work is based on a survey and research that he did that identified a lack of reliability in getting DNSSEC data [It appears the figure was like 1.5%] I think this is much more useful for positive assertions of trust as opposed to negative/restrictive assertions Eric O: This seems like an optimization, the working group should be worried about correctness first -- Stephen AD: We should move on and talk about working group docuemnts **** Resolving Aliases and Wildcards (Phill Hallam-Baker) -- Key issue Wildcard: You can't sign a wildcard like prefix.*.example.com (Where DANE is using a prefix to identify the port that the DANE record applies to) -- Key issue Alias: www.example.com CNAME example.com ... does not map the prefixed DANE record -- Open issue: x.example.com CNAME y.example.com Does we use record prefix.x.example.com or prefix.y.example.com Claim: That we choose is more important than that we choose -- Chairs: Appendix A of the new DANE protocol draft (-09 version) addresses this issue -- Warren [not chair]: This seems like a generic issue that doesn't just happen with DANE Isn't it better to solve this once in DNSEXT for everyone to use, instead of every working group solving it themselves -- Jakob (from Jabber): CNAME is internal to DNS, we shouldn't be doing anything that requires exposing CNAME through DNS APIs -- Ondrej Chair: We should take this to DNSEXT and use whatever they decide is best In the meantime we will use what is in the -09 draft **** Securing the Last Hop (Ondrej : Chair) -- Issue: DANE has a serious problem if there is a man in the middle between the DANE client and the validating resolver. -- Note: Do we expect clients to trust any resolver received via any DHCP you happen to talk to? -- Is there a problem to solve or document by the DANE working group? Is this our problem or do we shove it elsewhere? It is a generic problem that just happens to have consequences for DANE? -- Lars Lieman : You seem to be dodging operational problems by creating hacks in the protocol. This makes me uncomfortable. The approach you need to take is that if you don't like your ISP at any location, you should choose another one If you don't like your programming library then choose another one -- Wes Hardaker: We have the luxury of being at the forefront of using DNSSEC in a novel way to solve a very important problem. As a result we have come up with a huge number of issues that aren't directly related to DANE We should only be working on the stuff that are show-stoppers for DANE ... other things we should just bring to the attention of the appropriate people Note: The IETF hotel in Prague once the IETF network was gone blocked outgoing port 53 TCP, so it worked fine for everything besides DNSSEC -- PHB: If people are actually going to use this, then it has to work for very reliably for essentially everyone ... The operations need to be at the crux of this working group -- Warren Chair: We should push really hard on these important DNSSEC issues, but many of them are not part of our charter -- Stephen Farrell AD: The charter says the working group will not define new mechanisms to solve the last hop, but will document the last hop issues and point to existing mechanisms -- Peter Koch: It is very tempting, but we (the IETF) need to stop reacting to the perceived lack of activity at the early part of the adoption curve ... by creating transitional mechanisms that create a moving target for deployment I'm more concerned about provisioning security (the first mile) than the last mile -- Paul H: We are the first working group where getting an A record in-securely is worse than getting an A record over traditional unsecure DNS ... I believe there should be a separate document (maybe in an operational document) not in the protocol ... Maybe this new document blocks the protocol document ... We don't have to make it perfect, but we do need to explain -- PHB: I do not regard this as a transition mechanism, so I disagree with Peter I believe the end-point of the trust is the user or organization not the machine I think it is a very bad idea to get any DNSSEC information from a resolver or middle-box that I do not trust -- Randy Bush: This is just security considerations, let's get back to interesting technical work [Side conversation: Randy Bush doesn't care if this is in security considerations or as a separate document] -- Ondrej Chair: What I hear is that we want a separate document to document operational considerations -- Warren Chair: We need to say in the protocol document that the client needs to be assured that the data came from DNSSEC and is trusted ... we do not need to say exactly what the mechanism is that assures that the DNSSEC data is trusted -- Paul H: We have intentionally written "less" on these type of operational issues, what I am hearing is that people who like to have "more" in the document -- Wes H: Separate document, so we can later mark it as Historic and not affect the protocol document **** Future of DANE (Ondrej Chair) -- We should be finished with the WGLC on the protocol around Taipei -- Stephen Farrell AD: We have open issues, then why are we talking about the future? Chairs: We don't believe there's anything to discuss face-to-face that would resolve open protocol issues -- Are we interested in DANE for IPsec? (currently in the charter) DANE for S/MIME? -- Paul Wouters: We should make sure the DANE protocol is completely finished before we start talking about DANE for IPsec -- Sean Turner AD: Yes, I would like you to do S/MIME and IPsec. Note that it is okay for the working group to go to sleep for six months after you finish the protocol (to let it settle) and then wake up and do IPsec or S/MIME later..