Subject: Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 25 Feb 2010 15:01:29 -0500

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 <[email-masked]> 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/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 26 Feb 2010 16:16:13 -0500

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 <[email-masked]> wrote:
> On Thu, Feb 25, 2010 at 11:55:03AM -0500, Paul Wouters wrote:
> 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.
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 26 Feb 2010 16:18:50 -0500

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
<[email-masked]> 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
>
>
>

---

From: Joe Baptista <[email-masked]>
Date: Mon, 1 Mar 2010 11:34:53 -0500

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 <[email-masked]>wrote:

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: David Conrad <[email-masked]>
Date: Mon, 1 Mar 2010 09:16:17 -0800

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

---

From: Tony Finch <[email-masked]>
Date: Mon, 1 Mar 2010 17:45:03 +0000

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  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 1 Mar 2010 13:37:20 -0500 (EST)

> 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

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 02 Mar 2010 06:13:28 +0900

> 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

---

From: Wassim Haddad <[email-masked]>
Date: Mon, 1 Mar 2010 14:21:48 -0700

On Mon, Mar 1, 2010 at 2:13 PM, Masataka Ohta <
[email-masked]> wrote:

> 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.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 02 Mar 2010 06:42:29 +0900

Phillip Hallam-Baker wrote:

> You can design a PKI to meet many different needs.

No, PKI can be designed for imaginary needs only with no real security.

> Identity is one purpose, but not a very useful one.

It is an example of imaginary security.

> If you want security from a

Real accountability needs a real account with real *M*O*N*E*Y*
in it.

If you loss $1M by a wrong operation of a CA, the CA should be
able to compensated the amount of the loss, which is the
accountability.

*M*O*N*E*Y* is the reality.

Then, what if, a wrong operation of a CA causes $1000 loss for 1M
people?

Bankruptcy of the CA does not help the people.

A CA charging $2000 for 1M certificates may have $1000000000 in
its account and may be able to compensate $1000 loss of 1M people.
But, what the point of people paying $2000, only to receive $1000
compensation? It's better for the people not to pay anything to
the CA. What if, if the loss is $1M loss for 1M people?

The only thing serious CAs can do is to make the possibility of
wrong operation absolute ZERO, which is not human and costs
infinite amount of money, which makes the CAs not profitable.

On the other hand, less serious CAs do little, if not nothing, and
just sell imaginary security at low cost to people who really need
real security.

That's how PKI is designed and CAs work.

PKI is a system of fraud.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 02 Mar 2010 07:02:48 +0900

> a solution to enable DNSsec?
> 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

---

From: Shumon Huque <[email-masked]>
Date: Tue, 2 Mar 2010 12:26:15 -0500

> 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
  ISSN    0302-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.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 03 Mar 2010 05:29:03 +0900

> "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