I was there and felt that was an excellent presentation. Thanks for taking the time to bring that to us. -- Glen Wiley
Principal Engineer Verisign, Inc. (571) 230-7917 http://vbsdcon.com A5E5 E373 3C75 5B3E 2E24 6A0F DC65 2354 9946 C63A On 6/25/15, 6:50 PM, "Patrick Ben Koetter" <[email protected]> wrote: >Greetings, > >I gave a presentation called "One year of DANE - Tales and Lessons >Learned" at >the 34th M³AA3WG General Meeting in Dublin a few weeks ago. Barry (Leiba) >asked me in an offlist mail to share the slides with you on this list and >also >write about the experience we've made during the last 1,5 years. > ># Slides >Here's a quick rundown to give an idea what my presentation was about: > >The first part is technical. It starts off naming the issues traditional >opportunistic TLS faces today. Then they show an approach/plan to solve >the >named issues only to present DANE as a solution next. The slides then >show and >discuss current use cases for DANE (with a strong focus on email) - HTTPS, >SMTP, OPENPGPKEYS, SMIMEA. > >The second part deals with adoption, possible markets and reasons why the >one >or the other TLD has a better starting position to adopt DANE. It also >lists >things we have learned during the last 1,5 years working with DANE or get >to >hear often when we talk with people interested to DANE-enable their >infrastructure. > >Download the slides at https://sys4.de/download/dane-maawg.pdf. > > ># Experience >Barry also suggested I summarize our experience with DANE. Here's a list >of >things we've learned or I believe to have understood (sudden moments of >clarity >are a great thing [tm]): > >DANE is server and client > DANE may be used by clients and offered to others. This is obvious >once > you've become aware of that, but people seem to focus at the "offering > DANE part" above average. And they seem to fade out the client side. > > When they realize the server side isn't low hanging fruit they seem >to get > stuck. Shifting their focus to the client side helps. That's the low > hanging fruit (assuming you have DANE capable clients at hand). > >Using DANE in a client is easy > You need a DNSSEC-capable resolver and DANE capable client software. >It's > simple, compared to offering DANE, because these componets are >simplier to > control and problems stay your own. Failures have comparatively >limited > effect. Postmasters change settings within their well-known >application. > They don't need to deal with a DNS server, which they might not know >as > well or need to talk a hostmaster to do something for them (they don't > feel comfortable with). > >DNSSEC-enabling your infrastructure requires careful thinking > DNSSEC is about security. The right way [tm] to do DNSSEC on a host >is to > equip it with a local DNSSEC-capable resolver. If you want to add > fallback resolvers (resolv.conf) *all* of them need to be >DNSSEC-capable > or you might end up with a (bad,insecure,...) DNS reply that would >have > been suppressed by a DNSSEC aware resolver. > >Careful if your run your own, internal TLD > Local TLDs are not DNSSEC signed by default. DNSSEC-aware resolvers >will > suppress answers unless you DNSSEC-enable the internal ZONE or >configure > the resolvers to ignore the DNSSEC chain of trust for that particular > domain. Test before or you will risc needless service outage. > >Check your firewalls > TLSA, SMIMEA and OPENPGPKEYS queries to DNS servers end up in TCP >answers. > Your firewall must permit TCP on 53. (Most people will probably have >that > in place if they also serve DKIM. If not this might be the answer to >these > strange DNS problems... ;) > Check also that your firewall doesn't filter RRs. It might drop >requests > for TLSA and all the other new RRs. It works from inside, but fails >for > outside requests. > >Offering DANE RRs is all about DNSSEC > Offering DANE requires a DNSSEC-enabled DNS server. Everything after > DNSSEC-enabling the DNS server is comparatively easy. > >DNSSEC-enabling is the hardest part > People are scared to DNSSEC-enable their domain(s). They have to >upgrade > their applications. They have to clean up/refactor/get a better > understanding of their service. (You're up and running in a few >minutes > and once that works you don't spend time with DNS anymore - unless >you're > a large player or do DNS for business). > >Registrars don't invest in DNSSEC > Offering DNSSEC means to invest in security. It requires to invest in >a > race to the bottom market where cheaper seems to be more important >than > more secure. The market interest for DNSSEC isn't great enough at the > moment to invest into DNSSEC. (In .nl the goverment subsidizes > DNSSEC-enabled domains. Surveys indicate 50% of .nl is >DNSSEC-enabled!) > >DNSSEC-capable registrars are hard to find > At least in .de its hard to find a registrar offering DNSSEC. One of >the > question we get to hear all the time is if we could recommend a list >of > DNSSEC registrars in Germany. To me this seems directly related to the > little invest we see in DNSSEC on the registrars side - a chicken egg > dilemma. > >Monitor your DNSSEC domain > Keep an eye on your zones signature TTL. If it expires DNSSEC-capable > resolvers will suppress replies. They will ignore your domain until >you've > renewed the signature. Monitor your DNSSEC domain. Monitor TTLs and >TLSA > pinned certificate enddates (see next lesson). > >RR rollover requires more careful handling > If you need to roll in a new TLSA (or any other DANE related record) >make > you do it in advance. Leave the old one and add the new one. Wait two >TTL > cycles. Give clients out there time to revisit and learn the new RR. >Only > then remove the old one. > > If you forget to add the new RR you risk receiving no mail from DANE > enabled clients. They check the RR and if you publish an old TLSA, >but use > a new cert they will not send. That's just how DANE should work. ;) > > Automate the rollover and make sure the rollover works reliably >*before* > you upload your zones signing key to your registrar and publicly > DNSSEC-able your domain. > >DNSSEC obstructs DANE > People who critice DANE usually criticise it because of DNSSEC. They >say > DNSSEC hasn't been worked on for too long time. The standard should be > updated. They say it doesn't provide the level of security it could >and > should for something as important as DANE to build upon. From their >point > of view DANE security is directly linked to the level of security >DNSSEC > provides. I'm no DNS expert to tell how much substance there is in >their > criticism. If there is updating DNSSEC standards might help to break >the > ice. > >There's no market for DANE at the moment > Everybody seems to wait for everybody else to start using/offering > DNSSEC/DANE. Those who DANE enable their clients find only few DANE > enabled servers to communicate with. Those who could DNSSEC-enable >their > domains and could start serving DANE-related RRs don't see the >benefit to > go through all the required work. > > We - heise.de (Germany's most popular IT magazine and portal), BSI > (Federal Office for Information Security), DENIC (Germanys .de TLD > registry) and sys4 - spent about half a year to prepare a DNSSEC-Day. > > DNSSEC-Day will take place next week Tuesday (June, 30th) between 2 >p.m > and 6 p.m. (CEST). It will be a (German language only) video >livestream > (see: http://www.heise.de/netze/dnssec-day) where all four parties >will > discuss topics related to DNSSEC and DANE. Articles and screencasts > complement the broadcast. > >DANE is for machine to machine communication > As it is there's almost no support for DANE functionality in end user > applications. If there is, the code is not part of the core, but an > add-on. It should reside in the core for security reasons. The/some > reasons why there's no core support in end user clients at the moment >have > been discussed on this list. > For the time being DANE remains limited to machine to machine > communication. > > >That's it for the moment. I hope this summary is useful and we will see >wide >adoption of DANE soon. > >p@rick > >-- >[*] sys4 AG > >https://sys4.de, +49 (89) 30 90 46 64 >Franziskanerstraße 15, 81669 München > >Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 >Vorstand: Patrick Ben Koetter, Marc Schiffbauer >Aufsichtsratsvorsitzender: Florian Kirstein > _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
