Administrivia DANE status, (appoint scribes, blue-sheets, agenda bashing) Chairs - 5 min DANE has a new charter, and the DANE specification documents will be revised by the end of next year, according to this new charter. DANE activites in Other WGs Chairs - 5 min Dan York: Reported on a draft proposing using DANE in SIP in SIPCORE WG, also a draft on using DANE with TURN servers in the TRAM WG in the RAI area. Working group documents: SRV and SMTP status http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-10 http://tools.ietf.org/html/draft-ietf-dane-srv-06 Chairs 10 min Awaiting final edits from the authors before conducting WG Last Call Matt Miller: Existing edits need to be sync’ed with co-authors, then submitted. Wes Hardaker: SMTP Draft functionally done. The SRV draft may want to look at the SMTP draft style for considerations and usage description. OPENPGP and SMIME status http://tools.ietf.org/html/draft-ietf-dane-openpgp-00 http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-usage-00 http://tools.ietf.org/html/draft-ietf-dane-smime-06 Chairs 5 min Call for comments on OpenPGP and SMIME. Eric Osterweil: Concerns that the suggestions on the mailing list (Feb’14) concerning deployment were not pulled into the draft Paul Hoffman: Did not see enough interest in this to integrate it it, but if there is more interest if this is applicable then we will put it in. Eric O: We have implementations. What is the right way to bring this to the group to ensure that there is notice and interest? Paul H: Sure - bring it up again. Olafur G: Tasked Eric to restart this discussion on the mailing list. DANEbis and operational guidance http://tools.ietf.org/html/draft-ietf-dane-ops-05 Wes Hardaker - 30 minutes. [see presentation] Paul Wouters: When you say “non-PKIX” do you mean “non-TLS”? Wes H: Right now for SMTP the only non-PKIX protocol is SMTP, but for now thats it. The protocol operators need to think about the world that they are in and their expectations and think about what types to use Paul W: But in switching you may need to run them for 10 years in parallel? Wes H: Yes Paul W: Should we think about this, and have a new usage type? Wes H: It would be great to say that this end system will only use PKIX-trust and this system will not. But how to signal this division is challenging. The protocol is that trumping one over the other. Victor D: non-PKIX means where there is not an established and used PKIX Phil HB: this is about what RPs should (or may) do. If a RP checks the DANE records are they allowed NOT to check PKIX revocation? (for example) Wes H: Why is a decision for a protocol to use DANE a deliberate decision? For these very considerations, as the protocol trust model cannot be left in an undistinguished state Olafur G: I am slightly confused. The decision of which to use (DANE or PKIX) would be left tot he protocol designers, rather than the operators Wes H: Yup. Don’t leave it to the operators Victor D: When clients support both then they are vulnerable to DNSSEC-only attacks. Olafur G: I thought that operators could chose to use DANE in SRV - you are saying that this is a protocol designer decision? Viktor D: The important thing to realize is that the choice of PKIX vs. DANE is a CLIENT-side choice that needs to be made. The server can publish whatever it wants, but clients need to pick which world they are in. Paul H: This WG needs to think about this to assist in the users of DANE Wes H: This sounds like future BCP material once we have some experience here Keith Moore: One of the issues here is mixed motives for DANE. Extend TLS into areas where the CA model has not worked well, and there are situations to use DANE where there was no CA model. These are different. You need a template that says what protocol design should specify. But this conflicts with the desire to extend existing protocols with DANE. This is messy. Dan Y: This is about best practices for a protocol to chose to use DANE or not Paul W: as a PKIX protocol you could use DNAE as an add-on to further restrict the PKIX model. Wes H: there are tradeoffs here TLSA Raw Keys http://tools.ietf.org/html/draft-ietf-dane-rawkeys-00 Paul Wouters 20 min (slides) "Should every protocol that uses TLSA records need its own RFC?” Wes: we just tried to not break things in our draft, but did not go into the semantics of when and how to use it in the TLS protocol. If you think there is just one more paragraph then great, send us the paragraph! Viktor: The draft suggests that any usage 3 works with RPK, but in fact only "3 1 X" works. Also with anything other than "3 1 0", there needs to be some way to convey the actual key (as in TLS). Paul: Yes you need to use the correct TLSA type that publishes the full public key Peter Koch: Existing protocols need this kind of specification, but are you also taking about future protocols? Paul: For a new protocol you can just use the TLSA record, and say so. Peter: you need to be explicit about the use of non-TLSA records Paul Hoffman: You don’t need to create a new record type with the same format as TLSA then if you are going to use TLSA for a non-TLS protocol then you should describe that use, and do so in the context of the protocol description. It may not need a dedicated RFC, but it does need to be described. Viktor: My intention was to put in enough RPK semantics into the OPS draft, to make a separate draft unnecessary. Dan York: We need to minimise the number of documents that an apps developer needs to refer to to implement an app Adam ?: there are situations of interop problems with RSA key use of explicit “null” values to parameters. Jeff Hodges: +1 to Paul Hoffman and Adam. You have to write all this stuff down. Wes: Is a document needed? Those 14,000 RFCS are all useful and valuable. [Really? :-) Your cynical minute taker!] Keith: disagrees with all the discussion item prompts. He argues in favour of explicit prohibition, against, reuse of existing RRtypes, against not requiring new specifications per protocol. Paul: DANE made these mistakes in the past, and this document tried to remove these restrictions and limitations on the usage of these types Olaf: Is this TLS of the use of TLSA? Keith: Well we are already in that zone and we can’t go back. Viktor: With TLS the server presents the public key to the client, provided it uses the same format on the wire as in DNS, it should just work. I've never seen any problems with 3 1 1 records with respect to SPKI encoding. And in practice all the keys are RSA. So it looks like the issue is absent in practice… (room) RFC3279: its already written down section: 2.3.1 Dan: Specification of the use of TLSA is good, but look at SIP - the glomming of PSTN goop in SIP lead to RFC5411, which is 42 pages of meta info about SIP that refers to the other RFCs. We should not reproduce this for DANE. That;’s what I want. Wes: Could be IANA Registry Paul: We’ve already lost that registry naming. Matt Miller: generic and simple. but. if folk have to write something for their protocol. then fine, but its good to think that this is generic. Phil HB: If you are going to put raw things in then it depends on the crypto - for example RSA has a lot of ancillary infer there, and if you use curve 25519 with short keys, then there is a point to this. 2048 bits of raw keys squished into a DNS would be a more comfortable fit. Adam: If you can do this for DNSSEC, then you can do this for DANE Keith: Section in a document that describes its usage in the context of DANE Paul W: Should the 6689 restrictions be dropped? Is there an objection to dropping these restrictions? Paul Hoffman: Well you should say when to drop and provide context: Paul W: I meant "drop the restrictions to PKIX-only" Paul Hoffman: Yes Paul W: Which document should include this dropping of restrictions Olaf: Should we think about a new RRtype for protocols that only use raw keys? Wes: Didn’t we have a failed key-type RRtype and didn’t it fail? Viktor: NO. 3 1 X is sufficient to represent keys. The SPKI selector already solves the problem. Peter Koch: Unless the protocol is clear in the beginning that it wants type “foo” Paul Hoffman: Agree with Victor - TLSA is sufficient Andrew Sullivan: Agree. on grounds of reuse of TLSA to make it simpler to use A DANE based solution for improving the security of HTTPS in CDN http://netsec.ccert.edu.cn/duanhx/files/2014/05/httpsincdn.pdf Haixin Duan -- 25 min Keith Moore: Doubts that additional security is being provided here Adam Langley: +1 Yoar Nir: Similar doubts. If you already have DNSSEC then the CNAME is enough. There is no other requirement for the TLSA record Viktor: Yes. Exactly. This proposal is fatally flawed. The design is broken. And failed to use the origin site cert for anything. Anyone can copy a cert! This is profoundly broken EV or NOT. Philip HB: Perhaps there is a need for a publication protocol to allow one to easily acquire and publish a new certificate, and thereby avoid delegation records Erik N; You need to be careful of conflating a bunch of discrete issues. There is some opportunities for opportunistic security in using DANE for TLSA records for traffic heading through a CDN. Chairs: Write an individual draft on the problem statement "Reverse DANE" i.e. can server check TLSA records for client? no draft Chairs - 10 min How can a server look up a client DANE key? Some protocols send names via handshake. Some protocols only have the addresses of the client. Can a server validate a client WG Feedback: There is the feel that this is interesting, and there are some challenges here, but it would be useful to start with some form of problem statement draft. Perhaps some use cases would help and perhaps the protocol should perform this itself? End of meeting