Subject: OpenDNS today announced it has adopted DNSCurve to secure DNS

From: Joe Baptista <[email-masked]>
Date: Tue, 23 Feb 2010 21:26:51 -0500

FYI

http://twitter.com/joebaptista/status/9555178362

regards
joe baptista

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 24 Feb 2010 09:56:30 -0000

> http://twitter.com/joebaptista/status/9555178362

I'm probably not alone in working for a company that blocks
twitter.com, and as the very nature of tweets is that they
are short, posting the tweet rather than the link on lists
such as this might make more sense.

Actually (since I have access via my own resources) the only
content beyond the subject line above is s bit.ly link.
So ideally the posting here would probably be to the
resolved version of the link. For those who also don't have
access, that's

http://blog.opendns.com/2010/02/23/opendns-dnscurve/

(I don't have any comments on the subject in general, or
that posting in particular.)

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Joe Baptista <[email-masked]>
Date: Wed, 24 Feb 2010 11:35:40 -0500

On Wed, Feb 24, 2010 at 9:40 AM, Wes Hardaker <[email-masked]> wrote:

> Anyone who's posting a link to a twitter message to an email message and
> seriously couldn't cut-n-paste a 140 character message into the email
> body is certainly doing so to attract followers as there is certainly no
> other motivation to make things more difficult for the reader.
>
>
Thats a good assumption. But like most assumptions it is easily invalidated.
Remember a twitter messages contains links not supported in email i.e. the
hash #.

regards
joe baptista

p.s. of course if you want to follow your welcomed but following is not
compulsory.

---

From: [email-masked]
Date: Wed, 24 Feb 2010 11:50:11 -0500

I'm not a lawyer, and neither is Bruce Schneier who is quoted in the
article below, but I suspect he's studied the ECC patent situation
more than I have (and I looked it quite a bit back when I was chairing
ipsec).

	http://en.wikipedia.org/wiki/ECC_patents

If it were up to me, I'm not sure I'd want to bet the DNS
infrastructure on whether or not patent lawyers with shark-skin
briefcases want to make a mint by instigating a lawsuit.  As we've
seen with the SCO lawsuit, even completely groundless legal disputes
can take years and years, and the only winner is the lawyers.  And
we've seen how much public key deployment was held back because of the
RSA patents; and most people who have lived through those dark times
really don't want to revisit them again.

As I told the Certicom folks over a decade ago, the best way they
could make their (hardware implementation) patents more valuable is by
explicitly making a non-assert pledge regarding software
implementations of ECC.  That would have cleared away a lot of the
hesitation around using ECC, since regardless of whether the claims of
ECC proponents that "no really, there's no problems here!" are true or
not, it would have calmed the fears who've looked at the situation and
who have perceived real risks.

Of course, the Certicom folks didn't listen to me back then, and I
doubt any of them would listen to me now....

						- Ted

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 24 Feb 2010 09:07:55 -0800

> really don't want to revisit them again.

right.

(shudder)

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 24 Feb 2010 10:00:34 -0500

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.

Given that record, why are we so sure that IETF processes are such a
good way to develop security specifications?

In practice the DNSEXT working group has been allowed to own this
issue for over a decade now. For the vast majority of that time the WG
has conducted itself as if it was in 'maintenance mode' for a
specification that has not been deployed. The response to each and
every real-world requirement that has been raised has been 'we have
been doing this too long to think about that'. And so it takes four
years to make fixes that should have been done in a month.

The W3C is not perfect by any means. But it does have a process that
has ensured that WGs begin with a wider range of requirements than
just what the people who bothered to show up for a BOF happened to be
interested in at the time. Each standards initiative begins with a
workshop that is open to all comers.

The problem with not holding that type of event at the start is that
it is much more difficult to hold one later.

We have a process that is focused on technology and on solutions. My
experience is that it is most important to focus on the problem.

On Wed, Feb 24, 2010 at 4:56 AM, Dearlove, Christopher (UK)
<[email-masked]> wrote:
> _______________________________________________
> Ietf mailing list
> [email-masked]
> 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/

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 24 Feb 2010 06:40:21 -0800

>>>>> On Wed, 24 Feb 2010 09:56:30 -0000, "Dearlove, Christopher (UK)" <[email-masked]> said:

CD> Actually (since I have access via my own resources) the only
CD> content beyond the subject line above is s bit.ly link.

Wes Hardaker
Cobham Analytic Solutions

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 24 Feb 2010 12:44:10 -0500

The problem here is not that you might infringe the patent, the
problem is that if a patent suit is brought against you, it will cost
a minimum of about $5 million to defend. Just to get to the point of
having an opinion on the matter you would have to engage a competent
expert witness who was willing to work on patent stuff rather than
building stuff. Then they have to do maybe a months work on research
and explain the results to a group of lawyers. You are going to have
five or more people and rack up several thousand hours at lawyer
rates.

Those costs buy a lot of crypto accelerator boards.

I kept trying to explain this situation to the various people who
tried to sell their 'efficient CRL' hacks. Even if your system is the
greatest ever and you give it to me for free, it will cost more to
work out if it is legally safe than it costs to solve the problem with
raw CPU power.

If the 512 byte limit really is a problem, then the logical answer
would be to use DSA-SHA256 since the signatures generated in DSA are
not a function of the key size. DSA also allows for offline
calculation of the signature data which would address performance
issues for companies like Akamai.

There are also reasons to beware of DSA. Steve Bellovin pointed out
that if the random number generator is bad the private key can leak
out. But RSA is not without similar issues, companies that can't
generate a good random seed for DSA will probably not create secure
keypairs for RSA either.

---

From: Tony Finch <[email-masked]>
Date: Wed, 24 Feb 2010 18:04:22 +0000

> * It could certainly win.

It has a LOT of catching up to do. DNScurve has no publicly available
implementations. DNSSEC will be deployed in the most important zones by
the end of this year.

> * It considers real world requirements that DNSSEC does not.

DNScurve ignores algorithm agility and patent problems.

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: Wed, 24 Feb 2010 13:15:28 -0500 (EST)

> doubt any of them would listen to me now....

Didn't RIM buy Certicom (trumping Verisign) ?

I'm not sure who owns the patents and who owns licenses and whether
the new owners would allow their use freely and unrestricted.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 24 Feb 2010 10:23:43 -0800

>	http://en.wikipedia.org/wiki/ECC_patents

draft-mcgrew-fundamental-ecc-02.txt is much more authoritative and up-to-date than that Wikipedia article. Please read it and see if it changes your mind about the patent situation for ECC in IETF protocols.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 24 Feb 2010 10:27:47 -0800

>implementations. DNSSEC will be deployed in the most important zones by

DNSCurve also assumes that authoritative name servers are willing to do orders of magnitude more calculations per second, all the time, than DNSSEC requires of them. That is, cryptographic calculations are needed for every response. Placing that burden on the DNS may or may not be acceptable to current operators. It may or may not also lead to less stability.

>DNScurve ignores algorithm agility and patent problems.

How does it ignore patent problems? ECDSA and DNSCurve have the same patent exposure.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 24 Feb 2010 14:29:26 -0500

On Wed, 24 Feb 2010 12:44:10 -0500

> generate a good random seed for DSA will probably not create secure
I've pointed it out in the IETF, but I'm certainly not the one who came
up with that observation in the first place; please do not give me
credit for other folks' work.

More on-topic: unless I'm very much mistaken, DNScurve relies on
transmission security rather than object security; in turn, that
requires a pretty fundamental change in how the DNS works.  (Well, not
completely, but you wouldn't gain any security benefit against most of
the threats from cache contamination if you didn't change it.)  Maybe
the DNS can work that way or should work that way -- but I haven't seen
any analysis to show that the load is manageable without caching and
with lots of banging on the authoritative servers.

---

From: Shane Kerr <[email-masked]>
Date: Wed, 24 Feb 2010 20:30:30 +0100

Phillip,

> 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

---

From: Tony Finch <[email-masked]>
Date: Wed, 24 Feb 2010 20:23:02 +0000

On Wed, 24 Feb 2010, Phillip Hallam-Baker wrote:
>
> And I have been asking ICANN for months how I get a key for my
> DNS zones into the system and have never got a reply.

You should be asking your registrar and/or registry. In the mean time you
can put it in the DLV.

> Al that has been written or deployed so far is publication
> infrastructure. Nobody can deploy or test standards based validation
> infrastructure until the root is signed and a lot more happens besides.

DLV has solved that problem.

Tony.

---

From: David Conrad <[email-masked]>
Date: Wed, 24 Feb 2010 12:38:03 -0800

> You should be asking your registrar and/or registry. In the mean time you

Yeah, meant to respond to Phillip earlier, but got sidetracked.  To be clear, ICANN only deals with TLDs so many of the concerns I believe Phillip has regarding ensuring the child/parent transfer of keying material are much easier to deal with. The current TLD process is defined at https://itar.iana.org/.

> DLV has solved that problem.

Well, DLV has addressed some problems and created others -- there is the Law of Conservation of Pain you know.

Regards,
-drc

---

From: Tony Finch <[email-masked]>
Date: Wed, 24 Feb 2010 20:50:34 +0000

>       * the channel where DS records get added to the parent

Is that actually out of scope or just not specified yet?

Tony.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 24 Feb 2010 15:57:23 -0500 (EST)

> 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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 24 Feb 2010 13:14:11 -0800

>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

---

From: Tony Finch <[email-masked]>
Date: Wed, 24 Feb 2010 21:26:09 +0000

On Wed, 24 Feb 2010, Paul Hoffman wrote:
> 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.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 24 Feb 2010 13:50:13 -0800

On 02/24/2010 01:14 PM, Paul Hoffman wrote:
> 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: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 24 Feb 2010 14:29:21 -0800

>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

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 24 Feb 2010 17:41:38 -0500

> * It could certainly win.

If, just one time, the people involved in these conversations would
say what "win" means in this context, I would be a much happier
person.  (Those who know me will observe that that's not saying much.)
It is by no means plain to me that DNSCurve and DNSSEC solve the same
problems.  It's hard to say how one can win over the other in that
case.

> * It is designed as a hack rather than an extension.

This sounds to me like an argument over taste, and I don't think that
it's useful to debate it.

> * It considers real world requirements that DNSSEC does not.

And it fails to address real world requirements that DNSSEC did.  So
what?  DNSSEC doesn't solve everything that TLS does, either.  This is
the _Internet_.  Having different solutions to different problems is a
good thing, not a reason to have a Protestants vs. Catholics fight.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 25 Feb 2010 08:36:05 +0900

> 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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 25 Feb 2010 10:47:55 +1100

> ID without elliptic curve cryptography) is secure enough.

Except from players that can see the query.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 25 Feb 2010 09:07:46 +0900

> 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

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 25 Feb 2010 01:19:27 +0100

> 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

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 25 Feb 2010 11:09:14 +0900

Nikos Mavrogiannopoulos wrote:

> 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

---

From: Joe Baptista <[email-masked]>
Date: Wed, 24 Feb 2010 21:43:36 -0500

On Wed, Feb 24, 2010 at 1:27 PM, Paul Hoffman <[email-masked]> wrote:

>
> DNSCurve also assumes that authoritative name servers are willing to do
> orders of magnitude more calculations per second, all the time, than DNSSEC
> requires of them. That is, cryptographic calculations are needed for every
> response. Placing that burden on the DNS may or may not be acceptable to
> current operators. It may or may not also lead to less stability.
>

That made me laugh. I would rather burden a server with added clicks then
the added burden DNSSEC will cause the world - not only in bandwidth - which
will explode under DNSSEC but also the economic costs to business and
individuals of migrating hundreds of millions of domains in the DNSSEC make
work project. Let's not forget DNSSEC re-engineers the Internet to a
centralized control model that defeats the end to end basics.

regards
joe baptista

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 25 Feb 2010 08:55:47 +0100

> In general, public key cryptography is scure only if public key

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

---

From: Basil Dolmatov <[email-masked]>
Date: Thu, 25 Feb 2010 11:05:44 +0300

> Out of scope. It is the bootstrap problem. Though with RFC-5011
It is much more than bootstrap problem.
> 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@

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 25 Feb 2010 17:31:45 +0900

> 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

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

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

---

From: Martin Rex <[email-masked]>
Date: Thu, 25 Feb 2010 14:30:28 +0100 (MET)

> * It considers real world requirements that DNSSEC does not.

What does DNSCurve additionally provide
compared to a combination of traditional DNS with IPsec?

-Martin

---

From: Tony Finch <[email-masked]>
Date: Thu, 25 Feb 2010 14:15:07 +0000

> compared to a combination of traditional DNS with IPsec?

DNS-based keying.

Tony.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 25 Feb 2010 14:22:48 +0000

> which is no different from simple nonce.

I think the expectation is that you learn the server names (and hence
their keys) of child zones from parents, under DNSCurve's
cryptographic protection.  This is slightly different from plain DH.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Martin Rex <[email-masked]>
Date: Thu, 25 Feb 2010 15:43:20 +0100 (MET)

> > compared to a combination of traditional DNS with IPsec?

That appears to be an illusion.

My impression is that DNScurve can only distribute public keys
of authoritative nameservers, not of the _much_ more common
caching nameservers, such as you find on firewalls/gateways,
e.g. every DSL-router.

I'm not sure that all of the nameservers operated by ISPs for
use with their customers are authoritative nameservers throughout.

And it appears to me that you either have to entirely abandon
recursive queries with DNScurve, or consider whatever DNScurve 
authoritative nameserver you ask for a recursive query to
be authoritative for then entire DNS universe.

If there is one thing that I like about the idea of signed
RRs in DNSsec, then it is the limitation of the authority
of that keys to DNS zones.  Creating fake keys and fake signed RRs
is still possible for an officially authoritative nameserver
for his delegated zones ("subdomains"), but not upwards
the DNS hierarchy and into other DNS zones. 

(I beg your pardon if I may have misunderstood the technology,
 and where I may be using inappropriate terminology.)

-Martin

---

From: Paul Wouters <[email-masked]>
Date: Thu, 25 Feb 2010 11:13:34 -0500 (EST)

>> compared to a combination of traditional DNS with IPsec?

RFC 4025 - A Method for Storing IPsec Keying Material in DNS

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 24 Feb 2010 15:15:17 -0500

The same could be said of PGP when it was first launched.

There was only one version of PGP against multiple PEM
implementations. Phil Z. made clear he didn't give a wetslap about the
patents.And I have been asking ICANN for months how I get a key for my
DNS zones into the system and have never got a reply.

Signing the .com zone is irrelevant until we have a process for
putting the key in. Several people are aware that I am asking this
question and will be speaking on DNSSEC at RSA next week. The fact
that the answer has been invariably 'I will get back to you on that'
and not 'here is the document you need to read' is itself rather
significant.

Note however, that I said that DNScurve could win, not that it would.
The IETF response to Phil Z. was to tell him to get lost and not
bother them. As a result PEM did not address the issues that Phil Z.
raised, and Phil went off and wrote his own code. The PEM group could
have taken Phil seriously instead, taken note of the objections and
actually answered them.

As a result we ended up with two systems, neither of which could have
been as good as if the PEM folk had been willing to be more open.

There is another approach to DNSSEC that could get us to market in a
fraction of the time that current systems would, or DNScurve for that
matter.

Instead of positioning DNSSEC as an alternative to SSL certificates,
co-opt the legacy base and more importantly the legacy infrastructure
of domain validated certificate providers. There is a base of a
million already issued certs out there. DNSSEC is way outside the
comfort zone of most registrars, it is something that the SSL
providers can easily support.

Al that has been written or deployed so far is publication
infrastructure. Nobody can deploy or test standards based validation
infrastructure until the root is signed and a lot more happens
besides.

If DNSSEC is successful it will inevitably erode and eventually
eliminate domain validated SSL certs. Which would provide a pretty big
business incentive for the incumbents to oppose. If instead we make a
minor adjustment of approach we could create a very major incentive
for most of the SSL certificate issuers to back DNSSEC.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 24 Feb 2010 15:39:10 -0500

I was attempting to refer to the fact you considered the break
noteworthy rather than that you were the source, my apologies if that
was not clear.

I think we do need to change the DNS model. But not necessarily as
drastically as DNScurve and not to get rid of caching.

I would like to see us create an assumption that a given machine will
only use recursive resolution services from a specific trusted source.
This in turn requires us to add some features to the protocol as we
need to add mechanisms for access control. We also need to make some
changes to get around widespread DNS hacks used to support roaming
WiFi provision.

[Oh we are so not close to being done with deployment here. If turning
on DNSSEC means the typical Web surfer cannot get their WiFi access at
Panera without reconfiguring their machine then DNSSEC is stone cold
dead.]

Rather than using the approach in DNScurve, I would want to see
something like the following:

* When a new machine is brought up the configurer is asked which
network they want it to be a part of, identified by a DNS name. This
will be the place that the system will use to look for the trusted DNS
resolution service. Since I use 8.8.8.8 I would enter 'google.com'.
The default could be taken from DHCP
* New RR to allow a machine to locate a trusted resolution service for
the network and authentication protocols supported. The initial
bootstrap could be taken from the DHCP service.
* Key agreement mechanism that allows the client to establish a
persistent binding represented by a kerberos style ticket
* Packet encapsulation mechanism that enables a kerberos style ticket
to be entered into client request packets.

The situation we have at the moment is similar to the one you get with
a large tub of lego. We have all the pieces we need, but they are
mixed in with a much larger amount of stuff that we don't really need.
Telling people they can build this from IPSEC, Kerberos and SASL is
like telling people they can do brain surgery if they read some
wikipedia articles.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 24 Feb 2010 19:28:25 -0500

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.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 25 Feb 2010 09:00:48 -0500

> compared to a combination of traditional DNS with IPsec?

They appear to have an interest in actually listening to real world
requirements.

The DNSSEC folk just tell us that every hard problem is 'out of
scope'. If an issue is out of scope for the IETF and out of scope for
ICANN, then who is going to address it?

You cannot solve a problem by ruling it out of scope.

Of course a combination of DNS and IPSec would be a better solution.
But nobody has specified how to do it. DNS is a bootstrap protocol,
you have to specify how the initial key exchange is achieved. Full
IPSec assumes that each side maintains state per connection. That is a
bad choice for DNS. You would want to adapt IPSec to use a Kerberos
ticket like approach so that only the DNS client needs to maintain
state.

It is not that difficult for Vint Cerf and Steve Crocker to get
Microsoft to put checkbox support for DNSSEC protocol into their
product. Getting a feature added to a Linux distribution is even
easier. But there is a huge difference between doing that and getting
a commitment to support it.

Defining the protocols is the easy part of PKI. The hard part is
specifying the social interface that gives the PKI specific meaning.
At the moment this is being left to DNS registrars, most of which have
no idea what a CPS or a CP is and have no interest in finding out.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 25 Feb 2010 09:14:21 -0500

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.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 25 Feb 2010 11:31:12 -0500 (EST)

> 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.	7200	IN	SSHFP	1 1 F79BDD2C882A9AC575198D507DE89D9B38145F00
www.xelerance.org.	7200	IN	SSHFP	2 1 B0B26D4895F3628AA721DAA0DB1B8236AFF02BF2
www.xelerance.org.	7200	IN	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

---

From: David Conrad <[email-masked]>
Date: Thu, 25 Feb 2010 08:38:37 -0800

[For some reason, I seem to receive Phillip's messages later than other people who are responding to his messages.  Odd.]

Hi,

> putting the key in.

Not really.  If VeriSign were to sign .COM tomorrow and publish their key somewhere well known, people who run validating resolvers could fetch that key, validating it however they see fit, and install it as a trust anchor in their resolver.

This is among the reasons ITAR was created.  To date, 12 TLDs have listed their keys in ITAR (see https://itar.iana.org/anchors/) using the same authentication mechanisms used to validate TLD update requests.

> Several people are aware that I am asking this

Not really, other than in the sense that people are really, really busy and, having presented on the ITAR in numerous venues over the past year or two (I've forgotten when we stood up the ITAR and can't be bothered to go look it up), generally assume people who have need of ITAR services can find out about it.

> Instead of positioning DNSSEC as an alternative to SSL certificates,

Huh? Who is positioning DNSSEC that way? People have mentioned that DNSSEC could, maybe someday in the far future, perhaps provide an alternative PKI infrastructure but that generally is not how DNSSEC is being positioned, at least to my knowledge.  DNSSEC is primarily being positioned as protection against MITM DNS-based attack.

> Nobody can deploy or test standards based validation

Sure they can, and in fact do.  ISPs in Sweden, for example, have (I'm told) been validating .SE domains for some time now.  For TLDs, there is ITAR.  For folks in islands of trust, there is DLV (if you trust ISC and are willing to accept the implications of using DLV).

Regards,
-drc

---

From: Paul Wouters <[email-masked]>
Date: Thu, 25 Feb 2010 11:41:55 -0500 (EST)

> only use recursive resolution services from a specific trusted source.

Trust no one. More and more devices will do their own DNSSE validation,
and just use caches to get the data. That's the beauty of DNSSEC and
one of the two main bottlenecks of DNSCurve (the other is requiring cpu
for crypto on every packet)

> need to add mechanisms for access control.

There is already access control possible, eg TSIG/SIG(0). Just no one
seems to use it on the stub resolvers.

> We also need to make some

Most of those have moved away from DNS already and just hijack the IP
port 80 stream instead.

> Panera without reconfiguring their machine then DNSSEC is stone cold

The fix for this will come from the browsers, who have to deal with this
situation anyway to avoid your 20 open tabs from reloading into a portal
page.

> to be entered into client request packets.

Seems much easier to me to store 1 DNSSEC root key and do it yourself.

Paul

---

From: Tony Finch <[email-masked]>
Date: Thu, 25 Feb 2010 16:43:05 +0000

On Thu, 25 Feb 2010, Phillip Hallam-Baker wrote:
> distribution into a secured DNS.

RFC 4255 "Using DNS to Securely Publish Secure Shell (SSH) Key
Fingerprints"

Tony.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 25 Feb 2010 11:50:04 -0500 (EST)

> Of course a combination of DNS and IPSec would be a better solution.

It would have the same flaw. You cannot expect to ask various DNS
servers in a row perfectly encrypted DNS data, then start an encrypted
browser session to 74.125.77.19, and expect people not to know you
just went to gmail.com. DNSCurve might have obfuscated some of your
queries, but any eavesdropping still knows exactly what DNS you looked
up and where you went to.

Once you realise encryption of DNS is not really possible, what is it
that DNSCurve offers that DNSSEC does not? Nothing. And previous postings
have illustrated the long list of shortcomings in DNSCurve over DNSSEC.

> a commitment to support it.

How many TLD's does it take for people to finally say DNSSEC is adopted?
See www.xelerance.com/dnssec/ for a google map.

> no idea what a CPS or a CP is and have no interest in finding out.

Many IETF people are active in the DNSSEC Coalition, a group of DNS experts
that is helping them solve that problem properly. The Registrars are not
"left to die". Far from it.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 25 Feb 2010 11:55:03 -0500 (EST)

> distribution into a secured DNS.

See previous post. Already done and running.

> And self-signed SSL certs would be

Yes. The CERT/CERTQ record is still a bit of a problem and needs some
work.

> unless the registrars have cryptography expperience, the CAs have that

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

---

From: David Conrad <[email-masked]>
Date: Thu, 25 Feb 2010 09:01:08 -0800

On Feb 25, 2010, at 8:41 AM, Paul Wouters wrote:
> Trust no one.

You have to trust someone.  Really.

> More and more devices will do their own DNSSE validation,
> and just use caches to get the data.

This must means those devices trust your their validator (and the operating system it is running on).  Which is fine (and, in fact, what I'd argue is the right answer), but it means you have to figure out how to securely obtain and install the root trust anchor (or the TLD trust anchors or the DLV trust anchor).

>> Panera without reconfiguring their machine then DNSSEC is stone cold

You have to do this in many cases with non-DNSSEC DNS already.  T-Mobile Hot Spot service, for example, requires you to use their DNS servers so you can't run your own validator.  It really is quite annoying.

Regards,
-drc

---

From: Joe Abley <[email-masked]>
Date: Thu, 25 Feb 2010 13:05:56 -0500

> 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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 25 Feb 2010 13:39:16 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Joe Abley
> Sent: Thursday, February 25, 2010 1:06 PM
> To: Tony Finch
> Cc: Phillip Hallam-Baker; IETF Discussion
> Subject: Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today 
> announced ithas adopted DNSCurve to secure DNS)
> 
> 
> 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.
> 

Implementation experience has uncovered some deficiencies in 4310.  A
proposal to address the deficiences is being developed as an individual
submission:

http://www.ietf.org/id/draft-gould-rfc4310bis-05.txt

Scott

---

From: Shumon Huque <[email-masked]>
Date: Thu, 25 Feb 2010 15:18:03 -0500

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

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 26 Feb 2010 17:58:20 +0900

> the user. There is a narrow window of vulnerability to a man in the

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: Masataka Ohta <[email-masked]>
Date: Fri, 26 Feb 2010 18:23:23 +0900

> cryptographic protection.  This is slightly different from plain DH.

No, it is not expected that gtld servers will become
"???????????????????????????????????????????????????.gtld-servers.net",
only to cause message size overflow.

						Masataka Ohta

---

From: Florian Weimer <[email-masked]>
Date: Fri, 26 Feb 2010 09:31:25 +0000

> only to cause message size overflow.

Wouldn't compression kick in if they shared keys (assuming that
DNSCurve doesn't sift the key from only the first label), making the
overhead negligible?

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 26 Feb 2010 18:50:44 +0900

> DNSCurve doesn't sift the key from only the first label), making the

There are several ways, such as anycasting, to overcome the problem.
However, they will require wide distribution of secret keys.

Anyway, my point is that there was no expectation.

Another evidence is lack of the concept of "root key" and other
things. If relying on security of root and other zones, which are
not really secure, was seriously considered, there should be
provisions for more complex mechanisms such as key roll over to
make the system a little less insecure.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 27 Feb 2010 07:39:45 +0900

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