Thank you! Great summary, I learned a lot. /Olle
On 26 Jun 2015, at 00:50, 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
