These notes / minutes kindly provided by Matt Lepinski. DANE Working Group Meeting IETF 87 (Berlin) ====================================== Chairs: Ondrej Sury (ondrej.sury@nic.cz) Warren Kumari (warren@kumari.net) Chair Slides available at: http://www.ietf.org/proceedings/87/slides/slides-87-dane-3.pdf Summary: ----------- -- There was strong support in the room for merging the content of draft-dukhovni-smtp-opportunistic-tls into the existing draft-ietf-dane-smtp. The chairs will confirm this consensus on the list and work with the authors to facilitate the merge. -- There was support in the room for working group adoption of draft-dukhovni-dane-ops-01. (Additionally, there was no significant opposition to adoption of this draft by the working group) The chairs will confirm this consensus on the list and work with the authors on determining the appropriate status (i.e., BCP or Informational) for the document. -- For the time being, discussion of draft-ogud-dane-vocabulary should continue on the DANE list. The chairs will work with the authors of the document and the area directors to determine whether the document should go through the working group or pursue some other path (e.g., AD sponsorship) -- The discussions related to a proposal to add a TSLA record to the ietf.org domain did not produce a conclusion. Additional discussion and planning is required before any recommendation/proposal is made to the secretariat. Details: ---------- **** DANE for SMTP (Wes Hardaker) ============================================= Slides: http://tools.ietf.org/agenda/87/slides/slides-87-dane-2.pdf Draft: http://tools.ietf.org/html/draft-dukhovni-smtp-opportunistic-tls-01 -- Note: Viktor Dukhovni has written DANE within POSTFIX This presentation is based on his experience -- Presence of a DANE record indicates that you support TLS This prevents downgrade attacks Note: Draft is opportunistic use of TLS for SMTP -- This is different than the browser world. There is no user to click "OK" -- Note: This whole idea critically depends on DNSSEC (CAs can't help you) Usage 0 and Usage 1 have the same DNSSEC exposure as usage 3 -- Claim: Postfix has stated that they intend to follow the proposal in this document (probably if the IETF tries to make significant changes they will ignore us) -- Proposal: Merge this draft with Hum: Overwhelmingly in favor of doing this merge. Chairs will work with the authors to facilitate this merge. -- Lars-Johan Liman: I am very positive of this type of work. This feedback is good I do not share your view that CNAME use is legal as you said it was Be careful about stating this, it is on a case-by-case basis -- Dan York: (relay from Viktor) indicates agreement with Lars-Johan Liman -- Dan York: QUestion: Have you looked at Tony's draft, can they be merged? Ans: Drafts are complimentary, authors agree with everything in Tony's draft *** DANE Best Current Practice ================================================ Draft: http://tools.ietf.org/html/draft-dukhovni-dane-ops-01 Slides: http://www.ietf.org/proceedings/87/slides/slides-87-dane-1.pdf -- Again based on Viktor's Experience -- Advice: Hashes instead of Full Keys (or Certs) Try to avoid TLSA 0 0, and try to avoid TLSA 1 0 -- Advice: Servers should avoid publishing with SHA512 -- Operationally, it is virtually impossible to use DANE and CT at the same time (at the very least, CT says MUST reject for self-signed Type 3 DANE certificates ... But DANE says don't do CA checks for Type 3 DANE certificates ... This seems to be a conflict ) -- Advice in this document: Pick one of CT/DANE don't do both -- Dan (relay from Victor): XMPP should be largely the same -- Russ Housley: Seems like we need to get the CT folks and the DANE folks in the same room to sort this out. I notice that CT was updated right before the cut-off so there is active work in this area -- Paul Hoffman: CT is experimental. Pick one is the wrong advice. CT needs to get the logs out and deployed before people rely on it ... they have operational issues to work out Don't do both is the right thing to say ... Ben is very much thinking about how to do CT for DNSSEC This is actively being worked on -- Stephen Farrell[not as AD]: I think it is early to have any BCP guidance related to CT Wes: We need to talk about both together, but it is not sure what the right Forum is for that discussion Stephen: I think the best thing to do is to say nothing about CT in the document -- Dan (relay for Viktor): We just wanted to make sure that DANE is not shot down by the CT spec -- Eric Osterweil: Can you frame the two things you get from the two different approaches. That is, document the engineering trade-off -- Dan (relay Viktor): I am open to CT with 0/1, provided it does not cover 2/3 -- Wes Hardaker: The DANE operational document is not the right place to compare/contrast. There needs to be another document -- Advice: If you must do both DANE 1/3 and 2, CT doesn't apply. Don't try to do CT verification in either of these cases. Only consider doing CT for DANE Type 0 -- Dan (Viktor): CT adds no security when DNS is compromised. Successful attacks on DNS allow attacker to publish a DANE type 3 -- Wes Hardaker(in response to Martin Rex question about DANE Type 1): You still do PKIX validation for DANE Type 1, but the CA for DANE Type 1 would never be in a CT log. -- Hum for adoption: Overwhelming in favor of adoption. No significant opposition -- Dan York: Hopefully we can get other people to contribute to this discussion based on their experience -- Peter Koch: Should this be BCP or No? Chairs: Let's figure this out the list Strong support in the room for "Let's not decide now" -- Peter Koch: DNSEC Operational Practices, the slow deployment rate guided us towards Information to avoid making BCP guidance based on a VERY small sample of deployments Paul H: +1 to Peter -- Wes Hardaker: Text is going to say "Our recommendation is" in many places Currently, we have no recommendation stated related to SRV Chairs: We will try to get input from someone who thinks a lot about SRV to figure out reasonable recommendations ***** DANE Vocabulary (Olafur Gudmundsson) ====================================================== Slides: http://tools.ietf.org/agenda/87/slides/slides-87-dane-0.pdf Draft: http://tools.ietf.org/html/draft-ogud-dane-vocabulary-00 -- Note: This might be broader than DANE. It might be more broadly for Applications that use DNS to have terminology to talk about their use of DNS -- Paul Hoffman: I think it is useful. I don't think it should be done here (in DANE) This is going to get a lot more complicated But having all this complication in one document is very useful -- Wes Hardaker: Not clear where the right place is to do this Perhaps operations area? Ans: I was thinking APPS area -- Stephen Farrell[AD]: AD sponsoring might be a good option -- Peter Koch: I think this is generally useful. However, I don't agree with everything you say in the document Categorizing DNS records should happen elsewhere But it could be a good thing for DANE to specify guidance for applications that are looking to specify a DANE usage -- Eric Osterweil: I think this is very useful. I think it should happen here. It isn't just useful here, but enough of it is useful for DANE that this is a good place to do it. -- Dan (Relaying Martin Rex): This seems to be doing for DANE what 6125 did for PKIX -- Chairs: Let's keep using the DANE list for now. Unlikely to be published as a DANE document, but we have a good set of people on the list to discuss this **** Paul Wouters (no slides) on his drafts for OTR and PGP ============================================================== -- Paul Hoffman: I support this as a draft Having run the open mail consortium in the past, it was always a sore point of contention that PGP key servers were never specified very well. I think this is a very reasonable way to distribute keys for PGP -- Dan York: Thank you for sending in these drafts. These are excellent cases I also like the DANE with SIP draft. We need more DANE with FOO DANE is a great use case for helping to get DNSSEC deployed Browser vendors have pushed back on the web use-case for deployment reasons, and so it is good to work hard on other use-cases, to push DANE deployment -- Wes Hardaker: I am a big fan of putting everything in the DNS, so I like these drafts One problem (at least for security considerations of this document): We don't have a good way to securely get keys into the DNS (e.g. PGP keys) -- Dan (relaying Viktor): Toolkit (OpenSSL, ...) maturity is a major barrier. The Postfix code for DANE is highly non-trivial. Various other implementations are at this stage often flawed. Ans (Paul) : I put together a set of useful scripts hash-slinger See: http://people.redhat.com/pwouters/ **** TLSA for IETF.org ==================================================== Slides: http://www.ietf.org/proceedings/87/slides/slides-87-dane-4.pdf -- Question: Any reason why we wouldn't want to do this? -- Peter Koch: The mail part -- the spec isn't completely baked yet "That is catfood instead of dogfood" What is the purpose of this exercise? Ans (Wes): "This allows to encrypt mail to the IETF mail server, mail which is publicly archived" -- Peter Koch: It is a good idea to do this for WWW but let's wait for the mail part to be more baked How do we know if this succeeds or fails? -- Dan (Viktor): DANE is more mature for Mail than for Browsers. No Browsers do DANE validation but there exist mail servers that do -- Paul Hoffman: IETF.org is reasonably large and yet not so large that they don't process support requests -- Peter Koch: So we are demonstrating that it doesn't hurt if we do this -- John Levine: IETF mail server does not support STARTTLS (at least today) -- Dan (Viktor): Test case servers should NOT be real domains -- Eric Osterweil: Showing that we eat our Dogfood is good. Having a well-known domain that people can test against is good. Chairs: Nic.cz has test records up (for example) there are other test domains -- Russ Housley: We can also do this for iab.org, etc -- Wes Hardaker: We can get Greps out of the log to see who is asking for TLSA records -- Wes Hardaker: This could stop someone to mount a man-in-the-middle attack to prevent mail they don't like from hitting the IETF mailing lists -- Paul Hoffman: When we pitch this to the secretariat we should DEFINITELY emphasize the logging/measurement and make sure we are measuring the right thing and get publishable numbers to know if this is useful/useless and harmful/harmless -- : Let's put it in with a low TTL (since we don't have a big red panic button) -- Dave Crocker: Operational system. Don't mess with it without a plan. Do Ops planning -- Dan (relaying Viktor): Note: key rotation guidelines need to be well understood. Main risk is failure when cert is updated without prior TLSA update. Really short RRSIG lifetime. The TTL is less important.