IETF91 - DANE Notes Minutes (Summary) - The agenda was not bashed - No hums were taken during the meeting Play-by-Play Warren Kumari and Ólafur Guðmundsson - Opening Remarks -------------------------------------------------------- Plan: Start WGLC on SMTP, SRV right after the meeting, and then rawkeys. Hope to WGLC the other openpgpkeys drafts later in the year Editors are needed for the Jan-Sep milestones (4 docs) - see charter. Send email to the chairs with your “resume,” that is, why you would do the work well. Ólafur: This is a good opportunity for newbies. The Chairs will give people help in whatever ways needed, get people process guidance. New blood is sought. Warren: Also the Chairs will be happy to help new editors to sort out the tool stuff. Peter Koch asked if the timeline for going to Internet Standard is too fast, since DNSSEC hasn’t been advanced to IS yet. He also asked if the Chairs are looking for interop reports for these actions. Olafur answered yes about the interop reports questions and noted people are staring to do that for the smtp draft. Paul Wouters says they are writing code on IPSEC and DANE, and will contribute text too (though stopped short of owning doc). Quick Look at a DANE SMIMEA Prototype - Eric Osterweil -------------------------------------------------------- I’m Eric from Verisign Labs. Quick talk, willing to answer questions, but will defer to chairs on when. Ólafur: questions that aren’t about immediate prototype should be saved for after the SMIMEA draft talk Simple goals for the prototype: play with SMIMEA discussion in real life & eat some of our own dogfood. Heads-up approach, deal with problems we find. We embraced _sign and _encr, and used NAPTR as a “sort of lookaside thing.” Based it on the getdns implementation. We can do full validation at stub if we want. Manually provisioned the SMIMEA records - this is not a provisioning demo. Built into thunderbird, and we will open source this soon. Sits as a shim between Thunderbird and getdns. I can’t do a live demo, but will show what I would show you if I had the confidence for the live demo. Encryption: We took some effort to not write down the decrypted info into anywhere persistent. Which also leaves ciphertext to forward on later. Signing: click buttons. We wanted to learn with the buttons, e.g. there is telemetry when you push, and users can opt-in to share usage behavior for research. Really quck, but not “beat that dead horse” Daniel Kahn Gilmore (DKG) - thanks for doing this. Seems like it’s about key distribution (SMIMEA) and tbird has built in. Why not use tbird’s built-in stuff? Ans - the engineers found the SMIME support that was there was very good, but easier to not crack it open to put DANE inside. This was fast for us. DKG - I contribute to enigmail, and yes, it is a complete pain, but still the right thing is to crack it open. Sean Turner - how many people are using yet? Ans - mostly aspiration for users so far, but we will soon release. Sean Turner - the way you made some stuff up and held your nose is great, just right for a prototype. Ans - the dogfood was delicious. Dave Crocker (relayed from jabber) - DANE is domain based and SMIME is user based - how does SMIMEA work given this? Ans - There’s a domain in the name, but the entries are on a per-inbox basis. We found it interesting to have more granularity. Rick Lamb: great work. How far off till we see something like this from Outlook? Suggestion to show an Outlook one at RSA, e.g. Ans - we hope this can be useful to others as a reference implementation. Phillip Hallam-Baker - would like to meet to see how this works compared with my own DANE SMIME proxy. Strong email addresses, put hash of cert in the email addresses. Would like to map the hashes together. Some way of saying in the fingerprint, what algo? Could we come to some agreement, so we sync up on this? Ans - Good idea to meet. Dave Crocker (relayed) - per user labeling not in the spec? Ólafur - openpgp and SMIME doc use same hashing of email addresses Russ Housley - Sean has a draft about the hashing. Thanks for this work and for separating sign and key management: they are different and don’t have to be together, so they should not have to. George Michaelson - Eric, you are looking really hot! What happens when people retire a key, is this taken care of? Ans - It is taken care of in the prototype. Update on SMIMEA Draft - Jakob Schlyter ----------------------------------------- We thought with 07 we were done, but up came this stuff form Eric and others. Not much discussion. Then some more. Let’s discuss via an updated use case document. We need more attention on it. We have some proposed text to change 07 with the new use cases. One other item should get on the table: coordination of the SMIMEA and openpgp drafts. Paul Wouters - for openpgp, we have a code assignment and implementations. What coordination are you looking for? Jakob Schlyter - some of the proposals to update 07 would touch the packet format. The revocation part could apply to PGP as well. Paul Hoffman - and note that none of the uses cases in the current document specify SMIME versus openpgp, that’s why there might be coordination. We don’t know until we get through the use case document. End of their talk. Ólafur - we will talk about how to take this work forward. Do we need to wait for implementations? Enterprises Viewpoint (one slide) - Scott Rose --------------------------------------------------- Scott Rose - this is about large enterprises, slow-moving, with entrenched interests. Points: 1. The need to associate keying material with a function. This isn’t really about revoke but about whether a cert is acceptable for some function (and then maybe no longer acceptable for that function). Example - a cert is OK for some purposes, but not for encrypted email due to some institutional need. That granularity of association with a function, it is not just the status of the keying material. 2. The need to communicate across domains, not just within. DIRECT (a US Health and Human Services electronic medical record program) had to de-scope because this was so hard, though they have ended up being able to use the DNS CERT record for discovery. 3. The desire to leverage existing identity management - for instance, the US might want to include the 6 million US federal employee PIV(?) cards into the DNS. The current use of LDAP servers works inside domains, but does not work beyond a domain - we think SMIMEA could be a killer app. In summary, The Enterprise. Ólafur - goal of this work is to make it easy to use encryption technologies across the whole universe. If I want to send Scott Hollenbeck a signed message, I currently have no idea how to do this, even though I know his email address. Sean Turner - I want to have the encryption part magically figure out where my email peer’s cert is. I have a small enterprise, but talking to anyone else is a pain. We should get it working Paul Wouters - I would like to map the subject line into our planning on this.. Don’t forget to encrypt the subject, most tools leave it in the clear these days. Subject of the email leaks info. Paul Hoffman - encrypting of the subject works if you work this as an encrypted MIME message - external subject has nothing, the real subject is in the encrypted part. Poorly implemented in present tools, agreed. Daniel Kahn Gilmore (DKG) - I’m concerned with this discussion of putting individual’s keys into the zone. Enumerablity of zones in DNSSEC. Mark Andrews - we could use NSEC3 and not have them so. DKG - NSEC3 makes enumeration harder, but it has been broken; look at the nsec3walker tool. Mark Andrews - put in fake labels and it is hard to walk the zone. DKG - this is defeated too - you pre-list typical names and you can force through to walking the zone. Paul Hoffman - remember that SMIMEA exists in a world where you can find out if someone has email by probiing with an email to see if it exists, so there is already a necessary exposure. An enterprise may have to look at the tradeoffs and perhaps limit to the smallest set the people whose keys are in the DNS. Warren Kumari - couldn’t an enterprise put in fake labels? Paul Hoffman - yes, that is what people do with NSEC3. But even if enterprises can prevent a dictionary attack, they can’t prevent the email probe. Concern for the enumeration of individuals is why we started with plain old email left sides but instead went with hashed ones. Just because some enterprises have a walkthrough problem, that is not a reason for not doing the keys in the DNS. DKG - the probes are an online attack, whereas the breaking of enumerability is an offline attack. Enterprises have a harder time to defend against the offline attack. Proposals exist with online signing, e.g. the NSEC5 research. Victor Dukhovni (by jabber relay) - Early on, I proposed a salt to prevent rainbow tables ,and peoeple objected, but it would address this concern. Ólafur - the consensus is that this is important work. People need to supply info and text, state usage cases. We must try to wrap up reasonably soon. We will do the right thing. Eric Osterweil - we have sent some suggested text and running code. What else should we contribute at this point? Ólafur - we will consider all submitted text. There has been a sort of educational gap. People from DNS comm, email comm, R&E comm are all relevant here. Paul Hoffman - I’m confused about what next. Eric and Doug and Scott have an enterprise use case draft. Why don’t we discuss the long and well-thought draft that exists rather than start again on this. Ólafur - yes, start with it. But if Dan York or someone has other usage cases, they should bring them. Paul Hoffman - comment on the existing draft and also do those individual contributions. Great place to start Warren Kumari - we worded this badly [not sure what followed here] Paul Wouters - I’m really concerned about the IPR. I don’t want to take a document from someone who has an IPR problem. Andrew Sullivan - hard to see what possible encumbrance is relevant for a use case. Warren Kumari - wrt, what does an IPR statement mean to this, we have been working to get clarification on this. Is Brian Haberman in room? Brian Haberman - where do you want me to start? What I can say? Despite everyone buying into the Note Well, it’s apparent that people haven’t read the BCPs. I find the behavior of refusal around this astounding. But people are learning about new processes, so don’t attribute to malice. The IPR tool allows not declaring the license, and that is on purpose. Do not bash people over the head on any of this. Warren Kumari - if people are sufficiently concerned, another document is an option. Ólafur relayed from Stephen Farrell - he agrees with what Brian said. Warren Kumari - we’ll entertain other docs, and we’ll get clarification on the licensing. Paul Hoffman - then you want us to wait for the mailing list? I suspect people didn’t read something yet, but there are interesting issues that will cause a long line at the mic if you want a long interesting discussion. Warren Kumari - let’s do it now even if uncomfortable. Better in back and forth. Jakob Schylter - just to confirm, we will not proceed with SMIMEA until the use cases are ready. Ólafur - that’s right. Phillip Hallam-Baker - I don’t understand what IPR thing is being referenced. But during DKIM, I proposed every single possible use of DNS and keys you can imagine, and there is prior art of pretty much everything. Burt Kaliski - To the extent that these cryptic references to IPR decrypt to Verisign, I want to say that Verisign is in full compliance with the IETF’s IPR policy and if anyone has concerns, then please talk to me. Andrew Sullivan - most people haven’t read the use cases draft, as it wasn’t on the agenda. Paul Hoffman - the use cases draft regardless of the authors talks about stuff that has been true for well over a decade. There’s a topic in there that will cause long lines at the mic, but the issues are old, and there could be an IPR issue. If the chairs want to get the WG riled up, this will do it. Andrew Sullivan - I’m way less concerned on this, and I still don’t know what IPR on a use case is. Allison Mankin - Given that the draft was not put onto the agenda, and IETF really likes people to read the draft before discussions, I suggest using the technique that so many other WGs do, a virtual interim meeting. This will also mean that email folks can participate who aren’t in the room today. Danny McPherson - I agree with Andrew. We appreciate Paul Hoffman’s interest. We are not alone. There’s been a lot of dialog on the mailing list around these use case things. I’d like to remind the chairs and editors that they work for the WG, so please do be responsive. Ólafur - we will have a virtual interim; it will not be when Warren is in HK, even though Warren asked for the excuse to miss. SRV Update - Matt Miller ---------------------------- Changes are small. We think this is ready for WGLC. Ólafur - we’ll issue a WGLC for this and SMTP jointly, starting this week. Four week WGLC. Any comments in the room now will count as WGLC comments. There are NONE. Five people must review and comment on both docs. Please address the issue of what cross-document consistency is needed as well as your own comments. Review Volunteers: Paul Hoffman, Sean Turner, a person whom I couldn’t recognize. Viktor Dukhovni (relayed by jabber) - what about OPS, it’s also ready, and SMTP references it. Ólafur: it will go next, right after the SRV and SMTP. DANE Deployment Observations - Dan York ------------------------------------------ The rationale - DNSSEC is a broccoli tech but it’s not exciting to eat. DANE more like the spam misubi. You need to eat broccoli if you want your tasty cookies (or spam). Stuff happening - note there are now hosting providers advertising DNSSEC and DANE - German ads. What can we learn from active deployment, roadblocks, challenges, things we could do to improve things. Maybe we’re done when the docs are finished. Or is there more we could do, or in other WGs? Dan’s draft has a list. One of the biggest, being able to add TLSA through managed DNS services. Developer libraries - we have the getdns API. Crypto concerns - we’ve seen a well-known DNSSEC critic complaining about our 1024 bit keys (DJB). Stephane pointed out lack of TLSA monitoring. Ops issues as pointed out by Viktor. That fact that use of EC results in appearance of no crypto in many cases still. M Ströder said don’t underestimate how much the lack of DNSSEC support matters. Reality around the hosting issues. Discussion, thoughts? Eric Osterweil - some things we discovered when playing with SMIMEA, doing diff types of crypto services gave us different lessons. Please produce new records, learn about them, get to “play”. Let’s not be “super-circumspect” as some lessons can only be learned by developing and trying. Viktor Dukhovni (relayed) - in Germany, DANE is being promoted. How to get efforts like this in other jurisdictions. Peter Koch - the response to lack of deployment is not more stds. Operators don’t like moving targets. One part of the “success” in DE is that the SMTP part can be done under the hood. End-users need no exposure to DNSSEC. And even so registrars get exposure and experience. Richard Barnes - candidly, the browser case for DNSSEC is not good. Thinking of TLSA, browser developers consider DANE mainly as an RR, and this means concern about latency and extra round-trips. I propose that if we want the browsers, we should revive Adam Langley dnssec-serialization draft, put some RRs for DNSSEC proof into the TLS handshake. Second point, even if we get momentum, the crypto issue is big, the 1K RSA keys are very glaring. Dan York - I’ve heard that too. Jason Livingood - wrt to documents, what about a DANE cookbook? 15-20 use cases, and an example for each, showing how to. To get to the next level, it has to understandable by the average IT person. Dan York - this has been a focus at ISOC, but more is needed. Eric Rescorla - there’s a big problem when the TLSA certs are not domain-based - you can’t just use DANE as pinning, so you might as well do the cert pinning and not DANE. [This was a very high-speed comment so it maybe Ekr said something not quite like this…]. Sebastian Castro - in New Zealand we have a very big push involving registrar solutions. We had a registrar workshop and they said they are looking forward to widely enabling signed zones for DANE. We need to create progress and demand by talking with people. Check out activities. NZ registrars DNSSEC and DANE workshop 2014. George Michaelson - dnsviz is of enormous benefit, it should show TLSA. SMIME and well packaged crypto will be a major boost. SMIMEA is fairly close to a killer app (and I do not like to say things about killers apps). Also, while not trying to bag any particular CA, we need to take blobs of trust material out of the browsers. Eric Rescorla - There’s a trust relationship based on you getting the browser from us. A distributed trust hierarchy like DNSSEC is delegations. In the case of the browser CA, you can think of it that we (browser vendors) are the single trust anchor. Dan York - let’s not refight the trust anchors stuff here and now. Wes Hardaker - I do a lot of monitoring. It’s hard to figure out the tradeoff of security and operational monitoring - what does good look like? Operators are scared. They need to be able to watch traffic from afar, and that need may be a preventer of deployment. I also worry about Happy Eyeballs. Parallelization of lookups. Get there. Happy Eyeballs are heavily related to operator fears. Wrt to trust anchor - every app must decide for itself. MTA [?] has decided not to trust the CA bundle. Conflicting viewpoints exist, we will have to acknowledge this. Franck Martin - On the email side of things, one problem with DNSSEC is with load-balancing, what big orgs need to do. Push people to resolve correctly, like in IPv6, fragmented packets. Studies show people are worried about fragmented pkts. Dan York - a lot of us have said push on validation now. According to the Geoff Huston trend charts, about 12% of queries now have dnssec validation. Higher in many countries. Phillip Hallam-Baker - admin and strategic considerations. We should have close relationships to DPRIVE and TRANS. Puts in a plugs for his DPRIVE proposal. Guarantee I can get stuff there even with middle boxes. I want to make sure this is a strong requirement. TRANS - this is research built on rsrch built on rsrch - putting DNS roots for a zone in a TRANS notary archive could be incredibly powerful. I can show you in math terms - have a look at a paper of mine on my website. Could solve a lot of DANE troubles. I trust 50 root CAs, and don’t want to move to one, unless that one is me. That’s the heart of my (PHB) projects. However - yes, we have 3K organizations working as CAs. Don’t think of them as competitors but as channels. Their job is not issue certs. CAs are people who provide tech support to people who deploy crypto. A million, 10 million companies rare eached by that industry. Dan York - the perception that DANE doesn’t apply to me as somone who buys certs - more clarity or education around TLSA modes? Viktor Dukhovni - where are we with the last mile problem with DNSSEC? Dan York points to Warren to answer. Warren Kumari - DPRIVE has multiple mechanisms that address the last mile. Also it is handled by getdnsapi. Jim Gettys - Jason Livingood funded Simon Kelley to do DNSSEC in dnsmasq, but you need to replace a lot of devices to get it deployed. If local home is the primary, he doesn’t have signing of the domain done yet. Unidentified Speaker - DNSSEC is out of research and in production now. There are vendors who can turnkey it, including the load balancing and CDN stuff. Deploy, stop fiddling, use. Dan York - some Akamai folks are here, and there is Ólafur’s beach BOF about the CDN issues coming up. Jim Gettys - as we get IPv6 deployed, and therefore return to e2e traffic, naming begins in the home. Make it home-easy. Dan York - it sounds like we are mostly done, from a standards perspective. Warren Kumari - we will finish the documents we have on our agenda. Ólafur - our core document is done. Paul Hoffman - I would flip around what Ólafur said - with the SMTP doc and its deployment, there will be a bump in general TLSA deployment. Dan York - returning to web browser comments earlier, and then underlining the “under the hood” point made by Peter Koch: will it be strange if the driver for DNSSEC is DANE and the driver for DANE turns out to be SMTP? Are there other infrastructure things where DANE would be effective? I know there is work on DANE in SIP. Eric Osterweil - SMIMA is critical and I have to echo George: I can’t send an email to someone I know well because I don’t know how to learn their key. The ops draft is for TLS in mail, not web TLSA (per core). And SMIMEA is different from TLSA. If we want, we can identify SMIMEA as a high value target, giving the world a service it doesn’t have yet. And drag DNSSEC along with it. Viktor Dukhovni (relayed) - if you have suggestions for the ops draft, send them asap to me and Wes. Matt Miller - for XMPP we are seeing a lot of (non-US) adoption. Signing of SRV, not so much DANE. Stg going on. Nico Williams (relayed) - the killer app for SMTP with DANE is MUA security indicators and a button for “make this secure” (one button). The killer app for HTTP2 is harder to pin down and note especially that browsers trying to get away from UI sec indicators. Wes Hardarker - I encourages Eric Osterweil to respond about the ops document. It is meant to be generic. There are now words for raw keys, but it should get more, it’s supposed to be generic. Eric Osterweil - I think that we have such a well-written draft is great. Hard to have an ops draft for things we don’t operate yet. Could you say “this is a TLSA perspective” instead of saying it’s the all DANE one, and then allow for lessons not to be stated before we learn them. Per Sean Turner’s comment, whenthe ops draft says don’t put keys in, just fingerprints, then we can’t get the encryption key as needed. Suggest to be specific to where we have learned specific lessons. Wes Hardaker - as we move to more TCP over time, it will be possible to downgrade the recommendation not to send certs but only fingerprints. There’s no other large-scale security solution Viktor Dukhovni (relayed) - the ops document only says it updates 6698, so it is* TLSA specific, not SMIMEA. SMIMEA. Sean Turner - close the draft and move on. Paul Hoffman - what if we rename the ops draft “ops for servers.” Wes and Victor have done a good job, but it’s server-focused. What Eric has found in his early SMIMEA implementation and what Jakob and I have found in looking at SMIMEA suggest a different ops draft for those. Ólafur - we have been chatting with our AD and we’re approved interim meeting Dec 2. Stephen Farrell approved over jabber. Open Mic Session No takers. Adjourn a few minutes early.