RE: DNSSEC to be strangled at birth.
I wonder if the DHS has any idea what it's asking for. The news totally mangled what you might be able to do with that key. Even people on this list have trouble figuring it out. Perhaps they just heard about this root key thing, thought it sounded cool and important, and since they recently watched Sneakers they thought they better have it. The news articles didn't say whether they wanted to be the only ones to have it (which they could argue was a good idea because who better to secure the Internet, but it would mean they would have work to do), or whether they just wanted a copy (which would be of absolutely no value defensively - it constitutes a tool for mounting an extremely difficult and quickly detected attack on the Internet). --Charlie p.s. strangled at birth seems a bad metaphor. DNSSEC may still be in diapers, but it turned 10 in January. More like added another nail -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James A. Donald Sent: Friday, April 06, 2007 12:16 PM To: Nicolas Williams Cc: Paul Hoffman; [EMAIL PROTECTED]; cryptography@metzdowd.com Subject: Re: DNSSEC to be strangled at birth. Nicolas Williams wrote: Which means that the MITM would need the cooperation of the client's provider in many/most cases (a political problem) in order to be able to quickly get in the middle so close to a leaf node (a technical problem). Not a very large political problem. Most ISPs not only roll over for the DOJ, the FBI, and the DHS, they also roll over for the russian mafias. With the root key and the cooperation of nodes close to the client, you can intercept SSH and SSL communications that rely on DNSSEC. Without the root key, you cannot. This is huge. This, of course, means the sensible man configures SSH not to rely on DNSSEC by default, which substantially reduces the benefit of SSH. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] N��*m� ڦ �j)b����'���r��y��zwb� r��y ��a��j:+vsv� r�
RE: DNSSEC to be strangled at birth.
On 06 April 2007 00:50, Paul Hoffman wrote: because, with it, one can sign the appropriate chain of keys to forge records for any zone one likes. If the owner of any key signs below their level, it is immediately visible to anyone doing active checking. Only if they get sent that particular forged DNS response. It's more likely to be targeted. DHS man shows up at suspect's ISP, with a signed-below-its-level dns record (or a whole hierarchy of normally signed records) to install on just their servers and perhaps even to serve up to just one of their customers. Nobody else gets to see it. Plus, now that applications are keeping public keys for services in the DNS, one can, in fact, forge those entries and thus conduct man in the middle surveillance on anyone dumb enough to use DNS alone as a trust conveyor for those protocols (e.g. SSH and quite possibly soon HTTPS). ...again assuming that the users of those keys don't bother to look who signed them. I think that's a safe assumption. How are these users meant to look? Little lock-icon in the status bar? Because I believe that ISPs, not just security geeks, will be vigilant in watching whether there is any layer-hopping signing and will scream loudly when they see it. AOL and MSN have much more to lose if DHS decides to screw with the DNS than anyone on this list does. Can I point out that large telecomms corporations have been making a habit of silently acquiescing to whatever illegal and spuriously-motiveated requests the DHS or anyone else invoking the magic words war on terror is capable of dreaming up? Having said that, it is likely that we will be the ones to shoot the signal flares if DHS (or ICANN, for that matter) misuses the root signing key. But it won't be us that causes DHS to stand down or, more likely, get thrown off the root: it's the companies who have billions of dollars to lose if the DNS becomes untrusted. We already had this with PKI and SSL, and it basically failed. Works fine on a small scale in a tightly-disciplined organisation; fails totally to scale to Joe Internet-User. cheers, DaveK -- Can't think of a witty .sigline today - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
Dave Korn wrote: We already had this with PKI and SSL, and it basically failed. Works fine on a small scale in a tightly-disciplined organisation; fails totally to scale to Joe Internet-User. one could claim that PKI failed ... especially in its trusted 3rd party scenario ... since it was an amazingly complex and expensive deployment to solve a rapidly vanishing problem. the basic design point is the electronic analog for physical credentials, certificates, licenses used in the offline world ... or the electronic analog of letters of credit/introduction from the sailing ship days (and before) ... the trusted distribution of information for the benefit of relying parties that had no other recourse for the information. in an online world ... a paradigm designed for trusted distribution of information for an offline world, rapidly becomes redundant, superfluous and obsolete (besides enormously NOT cost effective). SSL was intended as countermeasures to two vulnerabilities 1) are you really talking to the server that you think you are talking to (among other things ip-address hijacking) and 2) evesdropping of information in transit. The SSL solution to #1 was predicated on the end-user having knowledge of a trusted binding between the server he thought he was talking to and the URL for that server. The SSL protocol then provided the trusted binding between the URL and the server the user was actually talking to. That weak-link in all of this was current infrastructure where end-users frequently have very little knowledge of the binding between the server they think they are talking to and the URL for that server. It isn't so much that SSL has failed to do what it was implemented to do, it is that SSL failed to take into account that part where end-users have very little knowledge of the relationship between servers and the URLs for those servers. It isn't so much a small-scale population that it works for ... it requires a (disciplined) population that maintains adequate knowledge of the relationship between servers and the URL for those servers. Even a well disciplined population is likely only to maintain knowledge of strong binding between servers and URLs ... for only a small number of servers and their corresponding URLs. The same population may be also be vulnerable when dealing with URLs and servers outside some well regulated domain. these series of posts talk about eliminating PKI and digital certificates for SSL ... and going to real-time public key operations in the domain name infrastructure ... as countermeasure to ip-address hijacking (original SSL) as well as domain name hijacking (as well as providing mechanism for encrypting information while in transit). http://www.garlic.com/~lynn/subpubkey.html#catch22 Aka the current domain name certification authority PKI-based paradigm has its root trust in the validity of the information at the domain name infrastructure. While the existing SSL/PKI related implementation was targeted at ip-address take-over ... it still remained vulnerable to domain name hijacking. however, the real-time domain name public keys, still doesn't address the vulnerability of end-users typically not having knowledge of strong binding between the website they think they are talking to and the corresponding URL (making them vulnerable to website impersonation and social engineering attacks that get them to click on arbitrary URLs). Solutions for these vulnerabilities ... typically involve some amount of additional trust operations by the users ... along the lines of local repository of trusted public keys with the corresponding trusted binding to trusted URLs (which starts to look somewhat like the PGP email public key repository). One of the issues for such solutions is that they lack the economic incentive for large scale deployment (i.e. there is no 3rd party taking in money selling digital certificates). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
On Thu, Apr 05, 2007 at 07:32:09AM -0700, Paul Hoffman wrote: Control: The root signing key only controls the contents of the root, not any level below the root. That is, of course, false, and presumably is _exactly_ why DHS wants the root signing key: because, with it, one can sign the appropriate chain of keys to forge records for any zone one likes. Plus, now that applications are keeping public keys for services in the DNS, one can, in fact, forge those entries and thus conduct man in the middle surveillance on anyone dumb enough to use DNS alone as a trust conveyor for those protocols (e.g. SSH and quite possibly soon HTTPS). I know you understand this stuff well enough to know these risks exist. I'm curious why you'd minimize them. Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
At 7:26 PM -0400 4/5/07, Thor Lancelot Simon wrote: On Thu, Apr 05, 2007 at 07:32:09AM -0700, Paul Hoffman wrote: Control: The root signing key only controls the contents of the root, not any level below the root. That is, of course, false, This is, of course false. In order to control the contents of the second level of the DNS, they have to either change the control of the first level (it's kinda obvious when they take .net away from VeriSign) or they have to sign across the hierarchy (it's kinda obvious when furble.net is signed by someone other than .net). and presumably is _exactly_ why DHS wants the root signing key: Um, since when are you (or I) so good at figuring out what DHS wants? For that matter, assuming that a massive bureaucracy like DHS has one thing that it wants also seems silly. For all we know, this could be one clue-deprived dork who can write press releases after not really listening to the one technical person whom he asked. Or it could be a conspiracy to take over the Department of Commerce. Or ... because, with it, one can sign the appropriate chain of keys to forge records for any zone one likes. If the owner of any key signs below their level, it is immediately visible to anyone doing active checking. The root signing furble.net instead of .net signing furble.net is a complete giveaway to a violation of the hierarchy and an invitation for everyone to call bullshit on the signer. Doing so would completely negate the value of owning the root-signing key. Plus, now that applications are keeping public keys for services in the DNS, one can, in fact, forge those entries and thus conduct man in the middle surveillance on anyone dumb enough to use DNS alone as a trust conveyor for those protocols (e.g. SSH and quite possibly soon HTTPS). ...again assuming that the users of those keys don't bother to look who signed them. Given that this thread is about an entity whom almost no one trusts being the key holder, that scenario seems unlikely. I know you understand this stuff well enough to know these risks exist. I'm curious why you'd minimize them. Because I believe that ISPs, not just security geeks, will be vigilant in watching whether there is any layer-hopping signing and will scream loudly when they see it. AOL and MSN have much more to lose if DHS decides to screw with the DNS than anyone on this list does. Having said that, it is likely that we will be the ones to shoot the signal flares if DHS (or ICANN, for that matter) misuses the root signing key. But it won't be us that causes DHS to stand down or, more likely, get thrown off the root: it's the companies who have billions of dollars to lose if the DNS becomes untrusted. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
On Thu, Apr 05, 2007 at 04:49:33PM -0700, Paul Hoffman wrote: because, with it, one can sign the appropriate chain of keys to forge records for any zone one likes. If the owner of any key signs below their level, it is immediately visible to anyone doing active checking. The root signing furble.net instead of .net signing furble.net is a complete giveaway to a violation of the hierarchy and an invitation for everyone to call bullshit on the signer. Doing so would completely negate the value of owning the root-signing key. You're missing the point. The root just signs itself a new .net key, and then uses that to sign a new furble.net key, and so forth. No unusual key use is required. It's a hierarchy of trust: if you have the top, you have it all, and you can forge anything you like, including the keys used to sign the application key records used to encrypt user data, where they are present in the system. Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
At 7:54 PM -0400 4/5/07, Thor Lancelot Simon wrote: On Thu, Apr 05, 2007 at 04:49:33PM -0700, Paul Hoffman wrote: because, with it, one can sign the appropriate chain of keys to forge records for any zone one likes. If the owner of any key signs below their level, it is immediately visible to anyone doing active checking. The root signing furble.net instead of .net signing furble.net is a complete giveaway to a violation of the hierarchy and an invitation for everyone to call bullshit on the signer. Doing so would completely negate the value of owning the root-signing key. You're missing the point. The root just signs itself a new .net key, and then uses that to sign a new furble.net key, and so forth. No unusual key use is required. And you seem to be missing my point. If the root signs itself a new .net key, it will be completely visible to the entire community using DNSSEC. The benefit of doing so in order to forge the key for furble.net (or microsoft.com) will be short-lived, as will the benefit of owning the root key. It's a hierarchy of trust: if you have the top, you have it all, and you can forge anything you like, including the keys used to sign the application key records used to encrypt user data, where they are present in the system. The only reason for concern is if the top of the hierarchy can forge without people noticing, or if people notice that they won't care. I claim that that isn't possible, particularly if the root owner is someone as unloved as USDHS. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
On Thu, Apr 05, 2007 at 05:30:53PM -0700, Paul Hoffman wrote: At 7:54 PM -0400 4/5/07, Thor Lancelot Simon wrote: You're missing the point. The root just signs itself a new .net key, and then uses that to sign a new furble.net key, and so forth. No unusual key use is required. And you seem to be missing my point. If the root signs itself a new .net key, it will be completely visible to the entire community using DNSSEC. The benefit of doing so in order to forge the key for furble.net (or microsoft.com) will be short-lived, as will the benefit of owning the root key. You assume the new .net key (and what's signed with it) would be supplied to all users of the DNS, rather than used for a targeted attack on one user (or a small number of users). Why assume the potential adversary will restrict himself to the dumbest possible way to use the new tools you're about to hand him? Do you really think that the administrator of the _average_ DNS client would notice that a new key for .net showed up? It's trivial to inject forged UDP packets, after all, so it is hardly the case that one has to give the new forged key chain to every DNS server along the way in order to run a nasty MITM attack on a client. Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
On Thu, Apr 05, 2007 at 04:49:33PM -0700, Paul Hoffman wrote: At 7:26 PM -0400 4/5/07, Thor Lancelot Simon wrote: On Thu, Apr 05, 2007 at 07:32:09AM -0700, Paul Hoffman wrote: Control: The root signing key only controls the contents of the root, not any level below the root. That is, of course, false, This is, of course false. In order to control the contents of the second level of the DNS, they have to either change the control of the first level (it's kinda obvious when they take .net away from VeriSign) or they have to sign across the hierarchy (it's kinda obvious when furble.net is signed by someone other than .net). You're arguement is that DHS couldn't do this covertly, but that's only part of the picture. I can imagine scenarios where they do things *overtly*. [...] Because I believe that ISPs, not just security geeks, will be vigilant in watching whether there is any layer-hopping signing and will scream loudly when they see it. AOL and MSN have much more to lose if DHS decides to screw with the DNS than anyone on this list does. Having said that, it is likely that we will be the ones to shoot the signal flares if DHS (or ICANN, for that matter) misuses the root signing key. But it won't be us that causes DHS to stand down or, more likely, get thrown off the root: it's the companies who have billions of dollars to lose if the DNS becomes untrusted. 1) It's untrusted now. 2) The argument could be that they are doing it to make it more trusted. I agree: highly unlikely. But not impossible. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
On Thu, Apr 05, 2007 at 04:49:33PM -0700, Paul Hoffman wrote: At 7:26 PM -0400 4/5/07, Thor Lancelot Simon wrote: On Thu, Apr 05, 2007 at 07:32:09AM -0700, Paul Hoffman wrote: Control: The root signing key only controls the contents of the root, not any level below the root. That is, of course, false, This is, of course false. In order to control the contents of the second level of the DNS, they have to either change the control of the first level (it's kinda obvious when they take .net away from VeriSign) or they have to sign across the hierarchy (it's kinda obvious when furble.net is signed by someone other than .net). Think of the DNSSEC root as the root CA of a universal PKI (finally). The root CA of any PKI can act as an MITM between any pair of peers in that PKI, no matter how many intervening CAs there may be between the root and each peer. The problem with wanting the DNSSEC root keys for facilitating MITM attacks is that people are likely to notice, and secrecy is typically something that an MITM attacker wants. To avoid detection the MITM would have to get between the target client and all of DNS; and that's difficult because typically clients get DNS cache service from their immediate network service provider -- which cache the MITM does not want to pollute, so as to avoid discovery... Which means that the MITM would need the cooperation of the client's provider in many/most cases (a political problem) in order to be able to quickly get in the middle so close to a leaf node (a technical problem). Then there's the need to scale this -- if you can only use this MITM capability occasionally, what's the point? And what targets would DHS have that it could subvert in this way but not in other, simpler ways? Criminals? Not likely (besides, isn't that DoJ's job?). Spies? Less likely. Clients abroad? Less likely still. Dumb spies/criminals? Well, there'd be other ways to attack those. IMO, DHS gets too little real value from having the DNSSEC root keys in terms of MITM attack capability. And it will not get much value in terms of DoS attacks on, say, ccTLDs -- alternate roots would spring up and if the DoS were widely seen as unjustified most of the world outside the U.S. would end up using the alternate root. A DoS on a ccTLD would be a one-time deal, politically. The DHS would get real value in terms of veto power over new TLDs, IFF it is the only one to possess the root private key. But that's not what the story said, IIRC. The real problem with DHS having these keys in _addition_ to ICANN is that the more fingers in the pie the more likely it is that the key will be breached, leading to key rollover. I must admit that I am mystified as to why DHS would want these keys. Count me as among those who think the story is in error, or that DHS has received bad advice. I am NOT among those who are prepared to believe the worst of DHS; I expect that those of you more paranoid than I will discount my analysis of the MITM attack potential. Or perhaps I discount the difficulty of pulling off these MITM attacks too much (perhaps noone would notice cache pollution?). Tell me. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
[[ Agree with Nico's MITM arguments; different point below ]] At 10:49 AM -0500 4/6/07, Nicolas Williams wrote: The DHS would get real value in terms of veto power over new TLDs, IFF it is the only one to possess the root private key. But that's not what the story said, IIRC. Whoever owns the root key would only get to veto the inclusion of new or current TLDs in the DNSSEC-protected namespace, not in the root itself. No one expects that ICANN will be signing the zone keys for most of the TLDs for many, many years, if for no other reason than those TLDs don't even want to be responsible for protecting their zone key. The real problem with DHS having these keys in _addition_ to ICANN is that the more fingers in the pie the more likely it is that the key will be breached, leading to key rollover. Fully agree. It also means that, if there is a breach, the first few days / months will be spent finger-pointing instead of fixing. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
Nicolas Williams wrote: Which means that the MITM would need the cooperation of the client's provider in many/most cases (a political problem) in order to be able to quickly get in the middle so close to a leaf node (a technical problem). Not a very large political problem. Most ISPs not only roll over for the DOJ, the FBI, and the DHS, they also roll over for the russian mafias. With the root key and the cooperation of nodes close to the client, you can intercept SSH and SSL communications that rely on DNSSEC. Without the root key, you cannot. This is huge. This, of course, means the sensible man configures SSH not to rely on DNSSEC by default, which substantially reduces the benefit of SSH. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
On Wed, Apr 04, 2007 at 05:51:27PM +0100, Dave Korn wrote: Can anyone seriously imagine countries like Iran or China signing up to a system that places complete control, surveillance and falsification capabilities in the hands of the US' military intelligence? How is this any different from plain-old-DNS? Except that now the number of attackers is limited to one - instead of worrying about the US or China or UK or India or Russia or whoever falsifying DNS records, you just have to worry about the US. And if/when you catch them at it, you know exactly who did it. -Jack - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
The DHS has requested the master key for the DNS root zone. Can anyone seriously imagine countries like Iran or China signing up to a system that places complete control, surveillance and falsification capabilities in the hands of the US' military intelligence? For anyone who hasn't been paying attention, the root zone is maintained by IANA which since February 2000 has been run by ICANN under a contract with the US Department of Commerce. DOC calls the shots and always has. I don't understand any better than anyone else why DHS sent out a press release that can accomplish nothing but get people upset, but at most this is a turf battle between two cabinet departments. The war was over seven years ago. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor More Wiener schnitzel, please, said Tom, revealingly. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
anti-rant At 5:51 PM +0100 4/4/07, Dave Korn wrote: Can anyone seriously imagine countries like Iran or China signing up to a system that places complete control, surveillance and falsification capabilities in the hands of the US' military intelligence? No. But how does having the root signing key allow those? Control: The root signing key only controls the contents of the root, not any level below the root. Surveillance: Signing keys don't permit any surveillance. Falsification: This is possible but completely trivially detected (it is obvious if the zone for furble.net is signed by . instead of .net). Doing any falsification will cause the entire net to start ignoring the signature of the root and going to direct trust of the signed TLDs. Surely if this goes ahead, it will mean that DNSSEC is doomed to widespread non-acceptance. More than it is now? And unless it's used everywhere, there's very little point having it at all. Fully disagree. Many ISPs and individuals will be happy to do direct trust of the significant zones (com/net/org plus maybe their local ccTLD) and simply ignore signatures on the rest. This has already been well-discussed in the ISP community even before this event: many are not sure they trust ICANN itself, much less its current sponsor. Note that I'm not supporting the US signing the root in the least. I'm just saying that predicting doom is grossly premature. /anti-rant --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
Dave Korn [EMAIL PROTECTED] writes: Surely if this goes ahead, it will mean that DNSSEC is doomed to widespread non-acceptance. I realise this is a bit of a cheap shot, but: How will this be any different from the current situation? Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
Dave, For the purposes of discussion, (1) Why should I care whether Iran or China sign up? (2) Who should hold the keys instead of the only powerful military under democratic control? (a) The utterly porous United Nations? (b) The members of this mailing list, channeling for the late, lamented Jon Postel? (c) The Identrus bank consortium (we have your money, why not your keys?) in all its threshhold crypto glory? (d) The International Telecommunication Union? (e) Other: _ Hoping for a risk-analytic model rather than an all-countries-are-created-equal position statement. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: DNSSEC to be strangled at birth.
On 05 April 2007 16:48, [EMAIL PROTECTED] wrote: Dave, For the purposes of discussion, (1) Why should I care whether Iran or China sign up? I think it would be consistent to either a) care that *everybody* signs up, or b) not care about DNSSEC at all, but I think that a fragmentary uptake is next to useless. As indeed the current situation provides evidence may be the case. (2) Who should hold the keys instead of the only powerful military under democratic control? (a) The utterly porous United Nations? (b) The members of this mailing list, channeling for the late, lamented Jon Postel? (c) The Identrus bank consortium (we have your money, why not your keys?) in all its threshhold crypto glory? (d) The International Telecommunication Union? (e) Other: _ Hoping for a risk-analytic model rather than an all-countries-are-created-equal position statement. Strawman. Not what I said at all. FWIW, however, I would like to see them held by a multinational civilian organisation. That could be a UN or ITU body, or an ICANN or IETF/IANA offshoot, there are many possibilities. The *important* point is that we have strategies and techniques available to us in democracies to prevent corruption or abuse of power: we have separation of powers, and bodies that bring together conflicting interests to share power in the theory that if anyone tries to get up to anything, the others will be watching, and since they have conflicting interests they are unlikely to collude. This seems to me to be a viable principle for management of internet infrastructure. Placing it all in the hands of a single interest group - whether that be the US (or anybody else's) military, the RIAA, or Bun-Bun the mini-lop, is a single point of failure for corruption/abuse resistance. BTW, there are lots of other reasons not to trust a military: lack of accountability and oversight. You were the first to mention democracy: just because the US army is the army of a democracy does not mean that it is in itself democratic. cheers, DaveK -- Can't think of a witty .sigline today - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: DNSSEC to be strangled at birth.
Dave mentioned: # Can anyone seriously imagine countries like Iran or China signing up to a #system that places complete control, surveillance and falsification #capabilities in the hands of the US' military intelligence? I'm not sure having control of the keys for the root zone would give you all that. # Surely if this goes ahead, it will mean that DNSSEC is doomed to widespread #non-acceptance. And unless it's used everywhere, there's very little point #having it at all. This issue came up on Dave Farber's [IP] list; my comments to him (which never appeared, perhaps because Dave was already sick of hearing about it, or simply because my comments were boring :-)) are included below, for what they may be worth: Three points to consider about the current DNSSEC who should signs the root? issue... 1) While DNS is a critical core protocol, and one which has garnered substantial miscreant attention, deployment of DNSSEC to fix some of DNS' current weaknesses is still only embryonic. Most sites on the Internet today neither sign their own zones nor have configured their name servers to cryptographically validate others' domains. Numerical estimates for DNSSEC penetration range from just 0.001% to 0.0015% (see slides 74-75 in my Port 53 Wars talk, available at http://www.uoregon.edu/~joe/port53wars/port53wars.ppt (or .pdf)), and the domains that *are* getting secured by DNSSEC are generally not the most popular domains, nor the ones which are being used for critical online banking or electronic commerce, nor even those which belong to market-leading (or thought-leading) technology companies. When DNSSEC is more broadly deployed it will be more practically useful; when it is more practically useful, it will be more broadly deployed. I'm sure it is no surprise to anyone that Internet bootstrapping can be tough, whether we're talking about IP multicast, IPv6, jumbo frames, or, in this case, DNSSEC... Until substantial adoption does occur, we're largely arguing about a theoretical issue of limited *practical* import. If you want to help make DNSSEC (and the issue of who signs the root!) one which *is* practically important, then folks need to *use* DNSSEC: -- if you operate name servers, configure the name servers you administer to check the DNSSEC signatures of other zones, -- if you control one or more domains, sign your *own* zones, and -- talk to critical Internet partners you work with about DNSSEC and the status of *their* name servers and *their* zones (can you imagine the impact if even some of the giants such as Google, Yahoo, CNN, the BBC, Amazon, AOL, IBM, Microsoft, Cisco, WalMart, Citibank, etc., began to actually use -- and actively encourage *others* to use -- DNSSEC?) DNS server admins who'd like to try DNSSEC can find pointers to recipes for signing their own zones, and recipes for configuring their name servers to check the signatures of others' zones, in my talk at slide 76. 2) So when *will* the question of *who* signs the root become technically important? Well, at the risk of offering a semi-tautological answer to a semi-rhetorical question, that will probably be when the root actually gets signed. The root zone is NOT signed today, and depending on your perspective, signing of the root is either (a) imminent, or (b) something which may *perpetually* remain at least six months away (see slides 55-58 from my talk). If I were reading the tea leaves which are currently visible, I think the indicator with the highest predictive value is likely Verisign's February 2007 announcement of Project Titan, a three year (and hundred million dollar) DNS upgrade initiative (see http://www.verisign.com/titan/ ). I believe their completion of Project Titan may be a defacto precondition for the potential signing of the root, although signing of the root may still not occur even once Project Titan has been completed (DNSSEC is clearly an after thought when it comes to that expansion effort, not the central operational/business driver). 3) Does this mean the whole matter of who signs the root is a complete non-issue? Most emphatically no. The issue of who signs the root is one which may be trivial as a *practical* *technical* matter *today*, but it is one which is potentially *huge* as a matter of policy and precedent, and as a *longer term* practical technical issue, and as an issue which has the potential to halt, slow, or potentially fragment DNSSEC's actual deployment. If the issue of who signs the root cannot be consensually resolved, the most likely impact will be for DNSSEC adopters
Re: DNSSEC to be strangled at birth.
Paul Hoffman [EMAIL PROTECTED] writes: At 5:51 PM +0100 4/4/07, Dave Korn wrote: Can anyone seriously imagine countries like Iran or China signing up to a system that places complete control, surveillance and falsification capabilities in the hands of the US' military intelligence? No. But how does having the root signing key allow those? Control: The root signing key only controls the contents of the root, not any level below the root. ... Falsification: This is possible but completely trivially detected (it is obvious if the zone for furble.net is signed by . instead of .net). Doing any falsification will cause the entire net to start ignoring the signature of the root and going to direct trust of the signed TLDs. If you control the root signing key, you can sign a new zone key for, e.g., '.com' and then create whatever content you want, e.g., 'example.com' and sign it with your newly created '.com' zone key. The signatures would chain back and verify to the root key. However, in practice I don't believe many will trust the root key alone -- for example, I believe most if not all Swedish ISPs would configure in trust of the .se key as well. One can imagine a web-of-trust based key-update mechanism that avoids the need to trust a single root key. /Simon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
* Peter Gutmann: Dave Korn [EMAIL PROTECTED] writes: Surely if this goes ahead, it will mean that DNSSEC is doomed to widespread non-acceptance. I realise this is a bit of a cheap shot, but: How will this be any different from the current situation? You can see that the keys change and draw your conclusions. Right now, you need to watch the actual data, which is a bit unwieldy (2.5% daily change rate for .COM/.NET and things like that). By the way, who else has expressed willingness to hold the key, under reasonable conditions? Would it be preferable if some non-governmental organization held the keys, after receiving an indemnification guarantee from Congress? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
Simon Josefsson wrote: However, in practice I don't believe many will trust the root key alone -- for example, I believe most if not all Swedish ISPs would configure in trust of the .se key as well. One can imagine a web-of-trust based key-update mechanism that avoids the need to trust a single root key. Indeed, and I already wrote an I-D for it: http://www.links.org/dnssec/draft-laurie-dnssec-key-distribution-01.html. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
* Simon Josefsson: However, in practice I don't believe many will trust the root key alone -- for example, I believe most if not all Swedish ISPs would configure in trust of the .se key as well. There are some examples that such static configuration is extremely bad. Look at the problems with bogon filters, or how long decommissioned root server IP addresses continue to receive queries. It's not a problem if you do this for .SE as a Swedish ISP because you notice quickly that something is amiss. But if too many people do this for most TLDs, it will become practically impossible to change keys. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
