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]
