Edward Lewis <ed.le...@neustar.biz> writes: [Ed's well written and long thoughts about transfer issues removed]
Security vs operational practice has always been a contention. Security purists want the strictest of controls so that nothing can ever be stolen, misused, abused, modified, etc. They'd use 4-factor authentication if they could get away with it (something you have, something you know, something you are and something from another time and another galaxy that's amazingly hard to retrieve). I admit, when I lean, I lean this direction. But I've also done enough operational work in my life to know that in an ideally secure world where security is the only metric, nothing would get done. You can't leave the lead box and certainly penetrating wires wouldn't be permitted through it. But the internet itself was founded at the opposite end of the spectrum: purely concerned with operational practice. There was no need to secure IP, DNS, BGP, telnet, imap, etc. Security is often an afterthought, because the first thought is *always* "can we get it up and running quickly?". Not, "can we get it up and running quickly and securely?". Primarily because "quick security" is an oxymoron. So, as always: we're left with a need to make a balanced decision. Which is better: multi-factor authentication or real-world operational practice. Or something in between. I'll agree with you that by forcing a user over TLS to make any DS changes in the parent, you're functionally adding a second authentication form: (a really badly implemented, ad-laden, web login subject to password database theft and social engineering... but still a second authentication form). Or is it? Really it's "a different form". > If the KSK was exposed, then a forged CDS might pass as real and the > registrant can loose control of the zone - because only one factor was > involved and the one factor was gamed. If your password gets stolen, guessed, entropied away (yes, that's a verb; shut up spell checker), socialized, etc then you're just as vulnerable to a take over as if a fake CDS was inserted. It's still only "one factor", unless your registar requires two factors itself to log in (and most certainly don't). And the key/password bits needed to log in to your registrar are likely smaller than the entropy used to sign your zone. And the registrar login data is usually stored in two places: their data base and on your post-it note. Plus, as a colleague of ours frequently likes to iterate "Protecting your DNS keys with uber-security and not protecting the DNS data source itself buys you nothing -- Russ Mundy. Ish; I don't think he'd use 'uber'" If you have lost control of your zone enough that someone has inserted a CDS record, they can also insert a new KSK or ZSK to forge records with. So denying them the ability to publish a CDS record doesn't really prevent things anyway. But all of this brings me back to my starting point: security vs operation. It's not up to us to decide which zones are so critical that they should never be allowed to use CDS records because they must physical visit their registar with 5 forms of authentication (#5 being star dust from Justin Bieber's head to prove you have the right to modify JustinBieber.com). It's not up to us to deny an operator of 100k zones the ability to roll keys on a regular basis because it's easy to do and his organization has a high administrative turnover rate (Justin Bieber fan club (TM)). It's not up to us to give them absolute security or operational mandates. It's up to us to give them the tools so they can make the choices themselves for their environment. It takes the registrar and the registrant to want to publish a CDS for it to be used. Either one can decide they would prefer to use the ad-laden web page login because it's more secure or it has pretty pictures of Justin Bieber in a skin-tight racing suit. CDS is at least a decent middle ground that offers a middle point in the balance equation. It provides a decent point where security and operational practice might be at the top of the tradeoff bubble. And, that's why we have operational and security sections in RFCs in the first place: to document concerns and let the real world make their decisions based on that discussion. -- Wes Hardaker SPARTA, Inc. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
