Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
On Tue, Mar 02, 2010 at 06:13:28AM +0900, Masataka Ohta wrote: Phillip Hallam-Baker wrote: Moving to DNSSEC, regardless of the technical model does not eliminate the need for certificates or CAs. The purpose of EV certificates is to re-establish the principle of accountability. I don't know what EV means, but anything human, including CA, is not infallible, which is why PKI is insecure. EV = Extended Validation certificates. Re-establishing (Establishing?) the concept of accountability, I think, requires more than introduction of EV certificates. Assuming that there is even agreement that they have a more accountable CPS, it also requires removal of the allegedly non-accountable CAs from trust anchor lists. This hasn't happened. There is also the question of the actual effectiveness of EV certificates. Do they really work? Can their indicators be spoofed? And can normal users use their visual cues to actually make informed security decisions? There appears to be a growing body of empirical work that shows that the typical user is unable to make effective security decisions based on certificates and their complex set of indicators (whether they are EV branded or not). Here are a few pointers, which I'm sure many folks on this list are well aware of .. * An Evaluation of Extended Validation and Picture-in-Picture Phishing Attacks ISSN0302-9743 (Print) 1611-3349 (Online) Financial Cryptography and Data Security, 2007 http://www.adambarth.com/papers/2007/jackson-simon-tan-barth.pdf * Why Phishing Works http://people.seas.harvard.edu/~rachna/papers/why_phishing_works.pdf 2006 * The Emperor's New Security Indicators: An evaluation of website authentication and the effect of role playing on usability studies. http://www.usablesecurity.org/emperor/ May 2007 * Crying Wolf: An Empirical Study of SSL Warning Effectiveness http://www.usenix.org/events/sec09/tech/full_papers/sunshine.pdf July 2009 And the paper I know of that supports the effectiveness of EV: * Extended Validation SSL: Green Address Bar Consumer Research Verisign/Thawte/Tec-Ed study: http://www.verisign.com.sg/guide/ssl-ev/EV-SSL-GreenBarResearch.pdf There have been extensive discussions on this topic on various other lists (cryptography, w3c, etc), and I'm not sure I look forward to seeing all of it rehashed on the IETF list. But I would be interested in pointers to other credible studies on this topic. --Shumon. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
Shumon Huque wrote: EV = Extended Validation certificates. Extending human validation is still human. Re-establishing (Establishing?) the concept of accountability, No, thanks. For accountability with regard to full compensation for losses, that is, *M*O*N*E*Y*, CAs are not accountable at all. That's all. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
Who are these 'security researchers' of whom you speak? I am a principal in the security field, if you want to contradict me then you should either say that something is your personal opinion or you should specify the other parties you are referring to. The reason that I want to see what the key registration process is going to look like is precisely because the validation process matters. It is the reason that I sent out the invitations to the original meeting that started the process that created EV certificates. Moving to DNSSEC, regardless of the technical model does not eliminate the need for certificates or CAs. The purpose of EV certificates is to re-establish the principle of accountability. You can design a PKI to meet many different needs. Identity is one purpose, but not a very useful one. Which is the real reason that identity systems are so hard to deploy. If you want security from a PKI you will do better with a validation system that provides accountability. I use words very carefully. I know that you can use SSH keys protected by DNSSEC. But at the moment there is not a complete proposal for a Secure DNS system. Key parts of that system are being left to chance and that is why the prospects for an alternative system are much better than you imagine. On Thu, Feb 25, 2010 at 11:55 AM, Paul Wouters p...@xelerance.com wrote: On Thu, 25 Feb 2010, Phillip Hallam-Baker wrote: But SSH would be much better if we could integrate the key distribution into a secured DNS. See previous post. Already done and running. And self-signed SSL certs would be better if we could use hash values distributed through a secured DNS to verify them. Yes. The CERT/CERTQ record is still a bit of a problem and needs some work. If DNSSEC succeeds, the domain validated certificate business will have to either transform or eventually die. I think that for most CAs, the business opportunities from SSL+DNSSEC are greater than the opportunities from the current DV SSL business. DNSSEC cannot deploy unless the registrars have cryptography expperience, the CAs have that experience. If you ask security researchers, it has been proven that CA's sacrificed security for profitability. The CA model has failed to work. 2 second validation based on email, md5 based * root certificates signed, etc etc. The last two years saw a significant amount of attacks against CA's, and CA's have seen their profit margin fall to near zero, so even if they wanted to, they cannot increase security (you ask me a confirmation for my cert, I'll go to this other ssl provider that doesn't). CERT's in DNS(SEC) put the responsibility of the cert within the domain of the customer. If they care, they can do their security. The time of outsourcing security to CA's is over. Paul -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
Some CAs sacrificed security for profitability. Which was the reason I started the EV process. If the race to the bottom had continued the products we sold would have no value at all. Getting your root into a browser requires you to get a WebTrust audit against your CPS. The problem is that before EV there were no requirements for the CPS. So long as your process said 'I do absolutely nothing at all', you could get your WebTrust audit. Some of the browser providers impose other requirements, but none addressed the validation criteria until EV was created. http://technet.microsoft.com/en-us/library/cc751157.aspx The only thing that was holding the system together was the fact that the older browsers could not update their root stores. So new CAs could only get a start by paying to cross-certify with an existing root. And all the roots that were inserted pre-Web Trust had been required to provide a CPS that actually committed them to do something with at least some meaning. That is why it costs more to get your CA cross-signed by some roots than others, those that promised least can command the highest prices. At this stage there are far fewer older browsers due to natural attrition and the older roots timing out. And at the end of this year Microsoft is going to pull the 1024 bit roots from the program. That is a good thing from the crypto point of view but will eliminate the last vestiges of control in the DV market unless something is done. I would like to deploy DNSSEC for the same reasons that you give. The problem is that at the moment it runs straight into a buzz-saw of global international politics. That is in the process of being fixed. On Thu, Feb 25, 2010 at 3:18 PM, Shumon Huque shu...@isc.upenn.edu wrote: On Thu, Feb 25, 2010 at 11:55:03AM -0500, Paul Wouters wrote: On Thu, 25 Feb 2010, Phillip Hallam-Baker wrote: If DNSSEC succeeds, the domain validated certificate business will have to either transform or eventually die. I think that for most CAs, the business opportunities from SSL+DNSSEC are greater than the opportunities from the current DV SSL business. DNSSEC cannot deploy unless the registrars have cryptography expperience, the CAs have that experience. If you ask security researchers, it has been proven that CA's sacrificed security for profitability. The CA model has failed to work. 2 second validation based on email, md5 based * root certificates signed, etc etc. The last two years saw a significant amount of attacks against CA's, and CA's have seen their profit margin fall to near zero, so even if they wanted to, they cannot increase security (you ask me a confirmation for my cert, I'll go to this other ssl provider that doesn't). I'll refrain from inserting the obligatory Matt Blaze CA quote here :-) The time of outsourcing security to CA's is over. Paul Exactly. What many of us would like to see is the ability for enterprises to issue X.509 certificates themselves for their own application services. If we're going to have a global PKI, the way I think it should work is that CA's higher up in the hierarchy should certify CA's below them (enterprises or some trusted intermediaries) using 'name constraint's so that the subordinate CA's can only issue certificates for subject identities in the namespace for which they have authority. And ideally the higher level CAs should be multi-lateral non-profits, rather than states or for-profit corporations engaged in a collective race to the bottom. The current situation with commercial CAs is beyond horrible. Just take a look at how many root CAs are embedded in your favorite browser, and with virtually no constraints on the name space in which they can issue certs. Do you really trust all of them? Any of them, whether by malice or by being tricked, can issue a certificate for any of your services. Our security is basically as good as the the CA with the laxest policies worst security. And in terms of functionality, they are woefully inadequate too. Most of them can only issue certs for hostnames in subject or subject alternative name dnsname fields. What if I want to deploy a certificate with other types of extension fields to better compartmentalize security or to enable new functionality, eg. URI, SRVName, a custom SAN, or application-service specific EKU fields? Allowing organizations to issue their own certificates allows them to deploy security infrastructure that actually addresses their needs. Perhaps it's wishful thinking, but I kinda look forward to the day that DNSSEC is widely deployed. I look forward to using SSHFP, IPSECKEY, and (a better version of) CERT to displace the broken Internet PKI .. --Shumon. -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
Once you have established an SSH relationship the protocol allows you to determine with a high degree of confidence that you are connecting to the same end point in future. That is not a perfect security control but it is a very useful one. It is a much more useful control than any provided by infrastructure that is not deployed. On Fri, Feb 26, 2010 at 3:58 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Phillip Hallam-Baker wrote: SSH is not a bad security protocol. It provides a very high level of protection against high probability risks with little or no impact on the user. There is a narrow window of vulnerability to a man in the middle attack. As a security researcher, I can teach you that the security you observe is not of SSH but of return routability. Return routability over many third party ISPs is not 'verifiable', of course. Masataka Ohta -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
I just want to remind everyone that a DNScurve draft is on the table. http://tools.ietf.org/html/draft-dempsky-dnscurve-01 There is an urgent need to solve the DNS security issues within a reasonable period of time. Please remember the Kaminsky dns bug did not identify a security problem with the DNS but the UDP transport. DNScurve fixes the problem today without having to spend 15 more years getting it right. And it does not cost a fortune to implement. DNSSEC is more of a make work project then it is a solution. And DNSSEC does not solve the UDP issue. And that is the problem DNScurve fixes NOW. If there is any common sense left at the IETF. And I think there are sparks here and there. Then I strongly recommend IETF members get DNScurve established as RFC. We need leadership - not more DNSSEC blah blah blah. Together let's exercise some common sense and support draft-dempsky-dnscurve-01. regards joe baptista On Thu, Feb 25, 2010 at 3:01 PM, Phillip Hallam-Baker hal...@gmail.comwrote: Who are these 'security researchers' of whom you speak? I am a principal in the security field, if you want to contradict me then you should either say that something is your personal opinion or you should specify the other parties you are referring to. The reason that I want to see what the key registration process is going to look like is precisely because the validation process matters. It is the reason that I sent out the invitations to the original meeting that started the process that created EV certificates. Moving to DNSSEC, regardless of the technical model does not eliminate the need for certificates or CAs. The purpose of EV certificates is to re-establish the principle of accountability. You can design a PKI to meet many different needs. Identity is one purpose, but not a very useful one. Which is the real reason that identity systems are so hard to deploy. If you want security from a PKI you will do better with a validation system that provides accountability. I use words very carefully. I know that you can use SSH keys protected by DNSSEC. But at the moment there is not a complete proposal for a Secure DNS system. Key parts of that system are being left to chance and that is why the prospects for an alternative system are much better than you imagine. On Thu, Feb 25, 2010 at 11:55 AM, Paul Wouters p...@xelerance.com wrote: On Thu, 25 Feb 2010, Phillip Hallam-Baker wrote: But SSH would be much better if we could integrate the key distribution into a secured DNS. See previous post. Already done and running. And self-signed SSL certs would be better if we could use hash values distributed through a secured DNS to verify them. Yes. The CERT/CERTQ record is still a bit of a problem and needs some work. If DNSSEC succeeds, the domain validated certificate business will have to either transform or eventually die. I think that for most CAs, the business opportunities from SSL+DNSSEC are greater than the opportunities from the current DV SSL business. DNSSEC cannot deploy unless the registrars have cryptography expperience, the CAs have that experience. If you ask security researchers, it has been proven that CA's sacrificed security for profitability. The CA model has failed to work. 2 second validation based on email, md5 based * root certificates signed, etc etc. The last two years saw a significant amount of attacks against CA's, and CA's have seen their profit margin fall to near zero, so even if they wanted to, they cannot increase security (you ask me a confirmation for my cert, I'll go to this other ssl provider that doesn't). CERT's in DNS(SEC) put the responsibility of the cert within the domain of the customer. If they care, they can do their security. The time of outsourcing security to CA's is over. Paul -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
On Mar 1, 2010, at 8:34 AM, Joe Baptista wrote: Please remember the Kaminsky dns bug did not identify a security problem with the DNS but the UDP transport. The problem Dan Kaminsky exploited is a known weakness in the DNS protocol, specifically that a 16-bit identifier space is too small. DNScurve fixes the problem today without having to spend 15 more years getting it right. Not really. Ignoring for the moment that there is a limited amount of deployed software that supports DNScurve, DNScurve addresses the DNS protocol problem by protecting the channel of communication. It doesn't actually protect DNS data. And it does not cost a fortune to implement. How much did it cost you to implement DNScurve? DId you make your code open source or otherwise available? And DNSSEC does not solve the UDP issue. Actually, DNSSEC does address the DNS protocol issue by ensuring any modification to DNS data can be identified. In the DNSSEC world, it no longer matters how you get the DNS data or what channel the data comes over or how secure that channel is. The same is not true of DNScurve. And that is the problem DNScurve fixes NOW. DNSSEC is already deployed in 12 top-level domains and the root is in the process of being signed. Multiple interoperable implementations of DNSSEC exist in production software. Together let's exercise some common sense and support draft-dempsky-dnscurve-01. As has been pointed out on several occasions, DNSSEC and DNScurve are not mutually exclusive. Of course, if you implement DNSSEC, the protections provided by DNScurve are superfluous (and the opposite isn't true), but that doesn't stop anyone from deploying both. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
On Mon, 1 Mar 2010, David Conrad wrote: DNSSEC is already deployed in 12 top-level domains Add a half for .uk :-) It has a deliberately invalid DNSKEY this week, full deployment next week. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
On Mon, 1 Mar 2010, Tony Finch wrote: DNSSEC is already deployed in 12 top-level domains Add a half for .uk :-) It has a deliberately invalid DNSKEY this week, full deployment next week. There is more then the 12 in itar. From the top of my head: .br .us .museum and .pt, and of course a large part of the reverse (all RIPE zones) and ENUM. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
Phillip Hallam-Baker wrote: Moving to DNSSEC, regardless of the technical model does not eliminate the need for certificates or CAs. The purpose of EV certificates is to re-establish the principle of accountability. I don't know what EV means, but anything human, including CA, is not infallible, which is why PKI is insecure. Is EV divine? Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
On Mon, Mar 1, 2010 at 2:13 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Phillip Hallam-Baker wrote: Moving to DNSSEC, regardless of the technical model does not eliminate the need for certificates or CAs. The purpose of EV certificates is to re-establish the principle of accountability. I don't know what EV means, but anything human, including CA, is not infallible, which is why PKI is insecure. = Can you please explain in few lines what would be your preference(s) for a solution to enable DNSsec? I apologize if you have already submitted a proposal about it which I must have missed... in which case, I would appreciate a pointer. Regards, Wassim H. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
Wassim Haddad wrote: I don't know what EV means, but anything human, including CA, is not infallible, which is why PKI is insecure. = Can you please explain in few lines what would be your preference(s) for a solution to enable DNSsec? I apologize if you have already submitted a proposal about it which I must have missed... in which case, I would appreciate a pointer. If you are talking about a technical mechanism not to cause message size overflow beyond 512B even with 2048bit keys, the solution is to use different RR types for different kind of keys, which I proposed more than 15 yeas ago in draft-ohta-simple-dns-00: In general, data size for authentication is often as large as of 100 bytes or more. So, it is a bad idea to share a single RR type value between different authentication mechanisms, because querying them all will often break 512 byte limit of UDP query. So, authentication algorithms are distinguished by RR type values, not by something like an algorithm type field. It's crazy to share an RR type between ZSK and KSK. For key roll over, different RR types should be used for even and odd generations. You may also use elliptic curve cryptography, though I don't prefer it. But, later, I noticed fundamental fraud in PKI, against which no technical solution exists. Note that separation of ZSK and KSK was an impossible attempt make inherently insecure PKI less insecure. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
Phillip Hallam-Baker wrote: SSH is not a bad security protocol. It provides a very high level of protection against high probability risks with little or no impact on the user. There is a narrow window of vulnerability to a man in the middle attack. As a security researcher, I can teach you that the security you observe is not of SSH but of return routability. Return routability over many third party ISPs is not 'verifiable', of course. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
Phillip Hallam-Baker wrote: Once you have established an SSH relationship That's the (lack of) security of SSH by return routability. PERIOD. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
Paul Wouters пишет: DNSSEC declares out of scope: * the channel where DS records get added to the parent Is that actually out of scope or just not specified yet? Out of scope. It is the bootstrap problem. Though with RFC-5011 It is much more than bootstrap problem. and perhaps draft-wijngaards-dnsop-trust-history-02 the above bullet might should probably read were initial DS records get added Once you have established the first DS record, you should be able to rollover without losing the path of trust. There are planned rollovers but also there are comprometations, NS authority changes, etc. All of these things are normal in production environment and should be treated with standard procedures. And these procedures are out of scope of DNSSEC. dol@ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
Nikos Mavrogiannopoulos wrote: In general, public key cryptography is scure only if public key distribution is secure. Well as far as I know ssh works pretty well today With plain old DNS, yes, ssh works pretty well today. However, it should be noted that first ssh connection may be misdirected, if plain old DNS is attacked. That is, we know plain old DNS works pretty well today. and this model can be easy made verifiable (i.e. secure as you say) by the administrator verifying the keys of upstream. Verifiability does not scale, which is why DNSSEC, or PKI in general, is not really secure. Being secure heavily depends on what your requirements are Requirements may vary. However, my point is that DH (or equivalent elliptic curve cryptography) does not add anything to simple nonce. Is a typical bank in europe secure? Can a general go with an armory division and take the money? Of course he can, but banks don't consider this a threat. You, as a general, are free to assume typical ISPs in europe not secure and packet snooping possible, which means you must say DNSCurve insecure. Or, you, as an ordinary person, are free to assume typical ISPs in europe secure and packet snooping impossible, which means you must say simple nonce secure. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
You do not make problems disappear by declaring them out of scope. Security systems are social systems. If you have not considered the business and social issues you haven't got a system. Security is about people, not protocols. On Wed, Feb 24, 2010 at 2:30 PM, Shane Kerr sh...@isc.org wrote: Phillip, On Wed, 2010-02-24 at 10:00 -0500, Phillip Hallam-Baker wrote: I took a look at DNSCurve. Some points: * It could certainly win. * It is designed as a hack rather than an extension. * It considers real world requirements that DNSSEC does not. On the 'winning' front. Have people noticed that the IETF has only ever succeeded in developing security standards by appropriating systems that had already defeated the IETF generated solution? PGP was not developed in house, it was a reaction to PEM. SSL was developed by Netscape. X.509 came from OSI. DNSCurve and DNSSEC are orthogonal, and solve different - if related - problems. DNSSEC declares out of scope: * the channel where DS records get added to the parent * encryption (which I think DNSCurve provides) DNSCurve declares out of scope: * the channel where the magic NS records get added to the parent * the channel where records get sent from the parent to the name servers in the RRSET * master or slave name server compromises * off-line secret key handling Depending on what you consider important, either technology may or may not be what you want. You could, in principle, use both, and it actually would provide different types of security. -- Shane -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
I find blanket statements of the form 'Verifiability does not scale' to be inconsistent with the facts. We do in fact have a very successful PKI industry with multiple companies competing in a multi-billion dollar market. The only reason this is not heralded as the triumph of PKI is that some people thought that PKI would look different. The biggest mistakes I made in that business was not recognizing the need for domain validated SSL earlier and not realizing that self-signed certificates should be treated positively by UIs. A site with a self signed cert is always going to be at least as safe as a site with no cert. So the user should never be presented with a warning dialog for a self-signed cert. SSH is not a bad security protocol. It provides a very high level of protection against high probability risks with little or no impact on the user. There is a narrow window of vulnerability to a man in the middle attack. But SSH would be much better if we could integrate the key distribution into a secured DNS. And self-signed SSL certs would be better if we could use hash values distributed through a secured DNS to verify them. If DNSSEC succeeds, the domain validated certificate business will have to either transform or eventually die. I think that for most CAs, the business opportunities from SSL+DNSSEC are greater than the opportunities from the current DV SSL business. DNSSEC cannot deploy unless the registrars have cryptography expperience, the CAs have that experience. On Thu, Feb 25, 2010 at 3:31 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Nikos Mavrogiannopoulos wrote: In general, public key cryptography is scure only if public key distribution is secure. Well as far as I know ssh works pretty well today With plain old DNS, yes, ssh works pretty well today. However, it should be noted that first ssh connection may be misdirected, if plain old DNS is attacked. That is, we know plain old DNS works pretty well today. and this model can be easy made verifiable (i.e. secure as you say) by the administrator verifying the keys of upstream. Verifiability does not scale, which is why DNSSEC, or PKI in general, is not really secure. Being secure heavily depends on what your requirements are Requirements may vary. However, my point is that DH (or equivalent elliptic curve cryptography) does not add anything to simple nonce. Is a typical bank in europe secure? Can a general go with an armory division and take the money? Of course he can, but banks don't consider this a threat. You, as a general, are free to assume typical ISPs in europe not secure and packet snooping possible, which means you must say DNSCurve insecure. Or, you, as an ordinary person, are free to assume typical ISPs in europe secure and packet snooping impossible, which means you must say simple nonce secure. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
On Thu, 25 Feb 2010, Nikos Mavrogiannopoulos wrote: Ssh without secure public key distribution mechanism is not really secure cryptographically. In general, public key cryptography is scure only if public key distribution is secure. Well as far as I know ssh works pretty well today and this model can be easy made verifiable (i.e. secure as you say) by the administrator verifying the keys of upstream. It already is, using DNSSEC. dig +dnssec -t sshfp www.xelerance.org ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 5, ADDITIONAL: 1 ;; ANSWER SECTION: www.xelerance.org. 7200IN SSHFP 1 1 F79BDD2C882A9AC575198D507DE89D9B38145F00 www.xelerance.org. 7200IN SSHFP 2 1 B0B26D4895F3628AA721DAA0DB1B8236AFF02BF2 www.xelerance.org. 7200IN RRSIG SSHFP 5 3 7200 20100306233849 20100220075947 58970 xelerance.org. HgME4vnp12/NhZKRUP7YVrSs6aXPeUvaWSoZ1FIS1Mk/8o9qIQgSb8k3 nC9LiQ8HjwGgVf7T2fSywvvW2KrlnFg8geJPSuMPEFXA41eXLUcmHHxr YQNfxkNnoJPz1iayk9tPjhKtfGwQuoL+hWiGUpnnjBKKU8hiCww4UjN4 yMo= And from man ssh_config: VerifyHostKeyDNS Specifies whether to verify the remote key using DNS and SSHFP resource records. If this option is set to “yes”, the client will implicitly trust keys that match a secure fingerprint from DNS. Insecure fingerprints will be handled as if this option was set to “ask”. If this option is set to “ask”, information on fingerprint match will be displayed, but the user will still need to confirm new host keys according to the StrictHostKeyChecking option. The argument must be “yes”, “no”, or “ask”. The default is “no”. Note that this option applies to protocol version 2 only. See also VERIFYING HOST KEYS in ssh(1). Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
On Thu, 25 Feb 2010, Phillip Hallam-Baker wrote: But SSH would be much better if we could integrate the key distribution into a secured DNS. RFC 4255 Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
On Thu, 25 Feb 2010, Phillip Hallam-Baker wrote: But SSH would be much better if we could integrate the key distribution into a secured DNS. See previous post. Already done and running. And self-signed SSL certs would be better if we could use hash values distributed through a secured DNS to verify them. Yes. The CERT/CERTQ record is still a bit of a problem and needs some work. If DNSSEC succeeds, the domain validated certificate business will have to either transform or eventually die. I think that for most CAs, the business opportunities from SSL+DNSSEC are greater than the opportunities from the current DV SSL business. DNSSEC cannot deploy unless the registrars have cryptography expperience, the CAs have that experience. If you ask security researchers, it has been proven that CA's sacrificed security for profitability. The CA model has failed to work. 2 second validation based on email, md5 based * root certificates signed, etc etc. The last two years saw a significant amount of attacks against CA's, and CA's have seen their profit margin fall to near zero, so even if they wanted to, they cannot increase security (you ask me a confirmation for my cert, I'll go to this other ssl provider that doesn't). CERT's in DNS(SEC) put the responsibility of the cert within the domain of the customer. If they care, they can do their security. The time of outsourcing security to CA's is over. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
On 2010-02-24, at 15:50, Tony Finch wrote: On Wed, 24 Feb 2010, Shane Kerr wrote: DNSSEC declares out of scope: * the channel where DS records get added to the parent Is that actually out of scope or just not specified yet? The whole channel from end-user (registrant) to registry cannot usefully be specified in any general way because there is no consistent way of interacting with a registrar (in the name of open competition) and no consistent registry-registrar-registrant structure across all TLDs (for reasons that surely would require more than one parenthetical phrase to describe adequately). The component that concerns communication between a registry and a registrar does have one solution that has been standardised in the IETF, however, which is being implemented at some TLDs, I hear. http://www.ietf.org/rfc/rfc4310.txt Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
On Thu, Feb 25, 2010 at 11:55:03AM -0500, Paul Wouters wrote: On Thu, 25 Feb 2010, Phillip Hallam-Baker wrote: If DNSSEC succeeds, the domain validated certificate business will have to either transform or eventually die. I think that for most CAs, the business opportunities from SSL+DNSSEC are greater than the opportunities from the current DV SSL business. DNSSEC cannot deploy unless the registrars have cryptography expperience, the CAs have that experience. If you ask security researchers, it has been proven that CA's sacrificed security for profitability. The CA model has failed to work. 2 second validation based on email, md5 based * root certificates signed, etc etc. The last two years saw a significant amount of attacks against CA's, and CA's have seen their profit margin fall to near zero, so even if they wanted to, they cannot increase security (you ask me a confirmation for my cert, I'll go to this other ssl provider that doesn't). I'll refrain from inserting the obligatory Matt Blaze CA quote here :-) The time of outsourcing security to CA's is over. Paul Exactly. What many of us would like to see is the ability for enterprises to issue X.509 certificates themselves for their own application services. If we're going to have a global PKI, the way I think it should work is that CA's higher up in the hierarchy should certify CA's below them (enterprises or some trusted intermediaries) using 'name constraint's so that the subordinate CA's can only issue certificates for subject identities in the namespace for which they have authority. And ideally the higher level CAs should be multi-lateral non-profits, rather than states or for-profit corporations engaged in a collective race to the bottom. The current situation with commercial CAs is beyond horrible. Just take a look at how many root CAs are embedded in your favorite browser, and with virtually no constraints on the name space in which they can issue certs. Do you really trust all of them? Any of them, whether by malice or by being tricked, can issue a certificate for any of your services. Our security is basically as good as the the CA with the laxest policies worst security. And in terms of functionality, they are woefully inadequate too. Most of them can only issue certs for hostnames in subject or subject alternative name dnsname fields. What if I want to deploy a certificate with other types of extension fields to better compartmentalize security or to enable new functionality, eg. URI, SRVName, a custom SAN, or application-service specific EKU fields? Allowing organizations to issue their own certificates allows them to deploy security infrastructure that actually addresses their needs. Perhaps it's wishful thinking, but I kinda look forward to the day that DNSSEC is widely deployed. I look forward to using SSHFP, IPSECKEY, and (a better version of) CERT to displace the broken Internet PKI .. --Shumon. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
From: Shumon Huque shu...@isc.upenn.edu Any of them, whether by malice or by being tricked, can issue a certificate for any of your services. Our security is basically as good as the the CA with the laxest policies worst security. Sounds like a poor attribute for a security architeture... Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
Phillip, On Wed, 2010-02-24 at 10:00 -0500, Phillip Hallam-Baker wrote: I took a look at DNSCurve. Some points: * It could certainly win. * It is designed as a hack rather than an extension. * It considers real world requirements that DNSSEC does not. On the 'winning' front. Have people noticed that the IETF has only ever succeeded in developing security standards by appropriating systems that had already defeated the IETF generated solution? PGP was not developed in house, it was a reaction to PEM. SSL was developed by Netscape. X.509 came from OSI. DNSCurve and DNSSEC are orthogonal, and solve different - if related - problems. DNSSEC declares out of scope: * the channel where DS records get added to the parent * encryption (which I think DNSCurve provides) DNSCurve declares out of scope: * the channel where the magic NS records get added to the parent * the channel where records get sent from the parent to the name servers in the RRSET * master or slave name server compromises * off-line secret key handling Depending on what you consider important, either technology may or may not be what you want. You could, in principle, use both, and it actually would provide different types of security. -- Shane ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
On Wed, 24 Feb 2010, Shane Kerr wrote: DNSSEC declares out of scope: * the channel where DS records get added to the parent Is that actually out of scope or just not specified yet? Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
On Wed, 24 Feb 2010, Tony Finch wrote: On Wed, 24 Feb 2010, Shane Kerr wrote: DNSSEC declares out of scope: * the channel where DS records get added to the parent Is that actually out of scope or just not specified yet? Out of scope. It is the bootstrap problem. Though with RFC-5011 and perhaps draft-wijngaards-dnsop-trust-history-02 the above bullet might should probably read were initial DS records get added Once you have established the first DS record, you should be able to rollover without losing the path of trust. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
At 8:50 PM + 2/24/10, Tony Finch wrote: On Wed, 24 Feb 2010, Shane Kerr wrote: DNSSEC declares out of scope: * the channel where DS records get added to the parent Is that actually out of scope or just not specified yet? What part of DNSCurve did you think was specified yet? It's described on a web site that is not versioned. To date, the authors and his fans have not produced an Internet Draft, even after a bit of prodding. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
On Wed, 24 Feb 2010, Paul Hoffman wrote: At 8:50 PM + 2/24/10, Tony Finch wrote: On Wed, 24 Feb 2010, Shane Kerr wrote: DNSSEC declares out of scope: * the channel where DS records get added to the parent Is that actually out of scope or just not specified yet? What part of DNSCurve did you think was specified yet? Sorry, I didn't mean that post to be about DNScurve. It seems to me that there's still work to do on managing secure DNSSEC delegations, so I was surprised to see it listed as out of scope. I was thinking more of updating DS records on key rollovers rather than initial setup of a delegation, though. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
On 02/24/2010 01:14 PM, Paul Hoffman wrote: At 8:50 PM + 2/24/10, Tony Finch wrote: On Wed, 24 Feb 2010, Shane Kerr wrote: DNSSEC declares out of scope: * the channel where DS records get added to the parent Is that actually out of scope or just not specified yet? What part of DNSCurve did you think was specified yet? It's described on a web site that is not versioned. The web site is at version 2009.06.22 To date, the authors and his fans have not produced an Internet Draft, even after a bit of prodding. http://tools.ietf.org/html/draft-dempsky-dnscurve-00 -- Marc Petit-Huguenin Personal email: m...@petit-huguenin.org Professional email: petit...@acm.org Blog: http://blog.marc.petit-huguenin.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
At 1:50 PM -0800 2/24/10, Marc Petit-Huguenin wrote: On 02/24/2010 01:14 PM, Paul Hoffman wrote: At 8:50 PM + 2/24/10, Tony Finch wrote: On Wed, 24 Feb 2010, Shane Kerr wrote: DNSSEC declares out of scope: * the channel where DS records get added to the parent Is that actually out of scope or just not specified yet? What part of DNSCurve did you think was specified yet? It's described on a web site that is not versioned. The web site is at version 2009.06.22 To date, the authors and his fans have not produced an Internet Draft, even after a bit of prodding. http://tools.ietf.org/html/draft-dempsky-dnscurve-00 I sincerely apologize, particularly to Matthew. He did indeed tell me about the draft last August, and I read it then, and then forgot. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
Marc Petit-Huguenin wrote: http://tools.ietf.org/html/draft-dempsky-dnscurve-00 As I read the draft, it seems to me that DNSCurve without Curve (that is, with 96 bit nonce of DNSCurve as an extended message ID without elliptic curve cryptography) is secure enough. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
In message 4b85b7e5.1000...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes: Marc Petit-Huguenin wrote: http://tools.ietf.org/html/draft-dempsky-dnscurve-00 As I read the draft, it seems to me that DNSCurve without Curve (that is, with 96 bit nonce of DNSCurve as an extended message ID without elliptic curve cryptography) is secure enough. Masataka Ohta Except from players that can see the query. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
Mark Andrews wrote: http://tools.ietf.org/html/draft-dempsky-dnscurve-00 As I read the draft, it seems to me that DNSCurve without Curve (that is, with 96 bit nonce of DNSCurve as an extended message ID without elliptic curve cryptography) is secure enough. Except from players that can see the query. That's not a new cryptographical problem. As DNSCurve protection is like DH, it is subject to MitM attacks, which is no different from simple nonce. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
On Thu, Feb 25, 2010 at 1:07 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Mark Andrews wrote: http://tools.ietf.org/html/draft-dempsky-dnscurve-00 As I read the draft, it seems to me that DNSCurve without Curve (that is, with 96 bit nonce of DNSCurve as an extended message ID without elliptic curve cryptography) is secure enough. Except from players that can see the query. That's not a new cryptographical problem. As DNSCurve protection is like DH, it is subject to MitM attacks, which is no different from simple nonce. Not really. I Don't know what you mean by simple nonce, but as I understand dnscurve if implemented properly would have ssh-style authentication. Only the first request of the server key is vulnerable with mitm. Then it should be cached. regards, Nikos ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
Nikos Mavrogiannopoulos wrote: Not really. I Don't know what you mean by simple nonce, but as I understand dnscurve if implemented properly would have ssh-style authentication. Ssh without secure public key distribution mechanism is not really secure cryptographically. In general, public key cryptography is scure only if public key distribution is secure. For example, DNSSEC is not really secure because key distribution through trusted third parties is not really trustable. Only the first request of the server key is vulnerable with mitm. So, we agree that DNSCurve is valunerable to MitM attacks. Then it should be cached. As it is cached, a successful attack on the first request, which is easy if you can snoop packets, is more than enough. It invalidate all the legitimate replies and validate all the forged replies. If you can't snoop packets, long message ID is just secure. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
Masataka Ohta wrote: Nikos Mavrogiannopoulos wrote: Not really. I Don't know what you mean by simple nonce, but as I understand dnscurve if implemented properly would have ssh-style authentication. Ssh without secure public key distribution mechanism is not really secure cryptographically. In general, public key cryptography is scure only if public key distribution is secure. Well as far as I know ssh works pretty well today and this model can be easy made verifiable (i.e. secure as you say) by the administrator verifying the keys of upstream. Being secure heavily depends on what your requirements are and from whom you are protecting from. Is a typical bank in europe secure? Can a general go with an armory division and take the money? Of course he can, but banks don't consider this a threat. regards, Nikos ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
