IETF 79 - KIDNS BOF Minutes ====================================== Date: THURSDAY, November 11, 2010 Time: 1520-1720 (Local time) Location: Garden Ballroom 1 CHAIR(s): Warren Kumari Ondrej Sury Agenda: o Working group goals and agenda, charter, etc. Ondrej Sury 30 minutes o draft-hoffman-keys-linkage-from-dns 45 minutes Using Secure DNS to Associate Certificates with Domain Names For TLS. Paul Hoffman o draft-turner-dnssec-centric-pki-00 30 minutes DNSSEC-centric PKI. Tim, Russ or Sean o Discussions on what we are trying to accomplish in this group, charter poking, etc. Notes: Matt Lepinski Scribe: Jeff Hodges Security Area Director: Tim Polk Materials Links: =================== KIDNS BoF Misc http://www.ietf.org/proceedings/79/slides/kidns-2.pdf Some of the Early KIDNS Proposals http://www.ietf.org/proceedings/79/slides/kidns-0.pdf DNSSEC-centric PKI http://www.ietf.org/proceedings/79/slides/kidns-1.pptx -- WG Update: **** Background by Ondrej Sury -- Expect to move list to kidns@ietf.org fairly soon -- We would like to have input from more people, but we have gotten feedback that the volume of the list is making it difficult for new people to contribute / keep up -- Sam H: Talk to former chairs of (e.g. the IPv6 working group), there is wisdom in the IETF already about how to deal with high-volume/very-active working groups -- Most discussion on the list is about draft-hoffman-keys-linkage-from-dns -- Question: Should we secure the last mile as well? -- Paul H: Where did this last mile question come from? ANS: The question is more does the verification need to be done by the client? or what security considerations do we have in cases where the resolver does verfication on behalf of the client **** Some early KIDNS proposals by Paul H -- Not an advocacy presentation, instead Jacob and I have tried to pull out the breadth of ideas that have come up in discussions on the mailing list ... Note that some slides may contradict each other, it isn't a coherent proposal, it's an attempt to provoke thought -- Bottom line is that there are a lot of things to think about in this working group -- Note that the definitions in this presentation of CA Cert and EE Cert are technical inaccurate (if one is a PKIX weeny) ... but the definitions on slide 2 are helpful the purposes of this presentation -- Goal: Use the DNS to get some keying information to do some security protocol that makes use of certificates ... Note that this isn't all about browsers -- Key Point on Key Sematics: The key from KIDNS is the key that will appear in the security protocol that you are about to do ... If you don't see this key in the security protocol, then you aren't talking to me, stop -- you aren't talking to me -- Tough Question (on EE certs and KIDNS): The server cannot demand a local validation policy, but can it suggest one? What validation policies are reasonable for a certificate (or cert hash) obtained from KIDNS? ... Speed is good and important, but we cannot be any less secure than what we have today, so we need to be careful -- Important Design Consideration: Does the protocol make things worse if DNSSEC is not used? ... Keep in mind that the using application generally doesn't know if their DNS queries have reponses covered by DNSSEC ... Note that the first three drafts (see early in this presentation) have the property that they make things worse than they are today if DNSSEC is not used -- Saying PKIX only may simplify things significantly, but is that assumption too limiting? -- There are lots of people who do basic IPsec, but there are almost no one who interoperates with certificates in IPsec Should we worry about IPsec, when the IPsec implementors don't seem to give a #### -- The way things get revoked in the DNS is way cleaner than anything that gets done in the security area! -- On DNS Format ... "Your religion is fine, but hold it for a few months" -- Paul believes that we need to actually write down a problem statement, and the problem statement either needs to be in the protocol document or referenced in the first paragraph of the protocol document -- From Jabber Room (Phil HB): Claim that the current charter proposal has unrealistic milestones for first protocol document, can we agree that this topic is important enough that we need to take more time ANS: Milestones can be moved at the AD descretion, let's assume they'll do something reasonable **** DNS-Centric PKI by Sean Turner -- -- Pete R: Really difficult for us poor APPs folks ... There is a nice long menu of APPs problems that can be solved by this mechanism ... When I read Paul's presentation, I got that depending on what problem you want to solve and what security features you need to have, you can do all sorts of things ... Can we get a short list of the things that could conceivably attack with KIDNS, and then figure out concretely what we are going to solve -- Pual H: Yes, we should do this before we as a working group decide what order we're going to do things -- Steve Farrel: The claim that we must not make things worse, seems to not have been stated on the mailing list This seems to imply that we just can't deploy this ... there's nothing on the table that doesn't make things worse with the current lack of last-mile security in the DNS -- Steve Farrel: Disagrees with the characterization of Paul's policy slide (claims that a one-bit policy is still policy) -- EKR (remote): If the invariant is that you can't make it worse, and don't know how to not make it worse, than this seems like research -- Steve Schulze: With regards to last mile, if we can't secure the last mile (or assume its secure), then what benefit are we adding? Are we just adding the requirement that the man middle is also a man middle for DNS -- Warren Chair: I believe we are working on the assumption that the last mile is secure (and the client knows its secure) for DNS -- Steve Schulze: We need to think about a graceful path to adoption, given that from a practical point of view we don't have DNSSEC deployment today (and yet if we always do PKIX validation) -- Joe H: In the S/MIME example do you have a way to go from an address to a cert? ANS: There was a little magic in going from the SIA to the certificate that corresponds to the address you care about -- Bernie H: Are we going to be looking up by the Port number or the Service that uses the port number ANS: The solution might be either -- Rick Lamb: Have you played around with any examples trying to do this? ANS: Nope, it's too early for me to have sample code, since I keep saying wait on format -- Jeff Hodges: -- Phil HB (remote): Securing the last mile is out of scope, but the work here may not be useful without securing the last mile ... but this is easy to solve establish a secure tunnel to the resolver you've decided to trust -- Wes Hadaker : Where are we going today? The only problem I heard that we should be solving immediately is how we should refer to a cert/key Last mile validation is not hard (my phone does it) ... but it's very hard without application linkage to the resolver Application needs to be smart enough to understand the linkage --- Paul H: We need to work with other working groups ... we should really be talking to APPs folks and we haven't done enough of that yet -- Paul H: Note that this work does help DNSSEC deployment in any way, but it does rely about DNSSEC deployment (But for a given application, you might not need a path to the global root, e.g. for S/MIME within an organization you might use a local DNSSEC trust anchor) -- Chairs: Note that maybe this is DNSSEC's killer app (hubris by the chairs ) ================ Session Over