Subject: [dnsext] New draft has been posted

From: Basil Dolmatov <[email-masked]>
Date: Tue, 07 Apr 2009 13:45:28 +0400

Hello!

Proposed draft for update DNSSec protocol in order to
support GOST cryptographic algorithms in it has been posted to I-D 
repository.

This work was done as a followup of discussions on the IETF meeting and
dnssec-deployment mailing list where the necessity the minor protocol
changes in order to support GOST cryptograpy was agreed upon.

Draft has the name draft-dolmatov-dnsext-gost-dnssec-00.txt.

We would like to have the WG adopt this document.

Thanks in advance,

dol@

========
Basil Dolmatov
Cryptocom Ltd.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Basil Dolmatov <[email-masked]>
Date: Thu, 09 Apr 2009 12:43:57 +0400

Sorry for misfiring, now it is available.

> support GOST cryptographic algorithms in it has been posted to I-D 
===
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> 	Title		: Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC
> 	Author(s)	: V. Dolmatov, A. Chuprina, I. Ustinov
> 	Filename	: draft-dolmatov-dnsext-dnssec-gost-00.txt
> 	Pages		: 8
> 	Date		: 2009-4-8
> 	
> This document describes how to produce GOST signature and hash algorithms
>    DNSKEY and RRSIG resource records for use in the Domain Name System
>    Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035).
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-dolmatov-dnsext-dnssec-gost-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/

dol@

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 13 Apr 2009 16:06:02 -0400

Dear colleagues,

This is a request that WG members to express their opinion as to whether
draft-dolmatov-dnsext-gost-dnssec-00.txt should be adopted as a WG
item.

We have already had two expressions to the mailing list explicitly
expressing support for the adoption of the document.

Remember that we must have the commitment of at least five (5) people
willing to adopt the document, and to review it.  In practice, it is
better to have more than five people, since we require at least five
supportive reviews in order to send the document on to the IESG.  If
we can't get five people to say something is a good idea, it is
probably not a candidate for IETF standardization.

Best regards,

Andrew (for the Chairs)

> support GOST cryptographic algorithms in it has been posted to I-D  

[&c.]

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

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 13 Apr 2009 22:42:28 +0200

I have read the draft and support the adoption.

Ondrej.

-- 
Ondrej Sury
technicky reditel/Chief Technical Officer
-----------------------------------------
CZ.NIC, z.s.p.o.  --  .cz domain registry
Americka 23,120 00 Praha 2,Czech Republic
mailto:[email-masked]  http://nic.cz/
sip:[email-masked] <[email-masked]> tel:+420.222745110
mob:+420.739013699     fax:+420.222745112
-----------------------------------------

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Apr 2009 13:45:22 -0700

>draft-dolmatov-dnsext-gost-dnssec-00.txt should be adopted as a WG

Yes, including the review requirement.

--Paul Hoffman, Director
--VPN Consortium

---

From: Dan Simon <[email-masked]>
Date: Tue, 14 Apr 2009 11:29:37 -0700

Does the WG have any formal statement of criteria by which it will judge this and future proposals to add algorithms to the DNSSEC standard?  If not, then perhaps it should.  I'm concerned in particular about two dangers:

1)  The proliferation of "vanity algorithms":  Because DNSSEC is expected to become an extremely widely used standard, it's also an ideal conduit for entities (national governments or even enterprises) that wish for one reason or another to promote their own cryptographic technology.  If a bandwagon forms of governments, say, using DNSSEC to promote the products of their domestic cryptography communities/industries, then DNSSEC users--that is, pretty much the entire world user community--will be greatly inconvenienced, as they repeatedly scramble to update their software to support the new algorithms.

2)  Encumbered algorithms:  A particularly worrisome scenario would be the adoption by the administrator of a large, important zone of an IPR-encumbered algorithm, thus effectively giving the IPR owner (presumably allied with the zone administrator) the power to control code on the host of every single client on the planet that needs to securely locate a host in that zone.

There may be more dangers I haven't thought of, but these two alone, I think, suffice to make it worthwhile for the WG to attempt to define some formal policies regarding new algorithms in DNSSEC, before charging ahead and adding them.   

			Just my 2c,

			Dan Simon
			Microsoft Corp.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Sullivan
Sent: Monday, April 13, 2009 1:06 PM
To: [email-masked]
Subject: Request for adoption (was: [dnsext] New draft has been posted)

Dear colleagues,

Best regards,

Andrew (for the Chairs)

[&c.]

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

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 14 Apr 2009 11:31:22 -0400

>expressing support for the adoption of the document.

<hat=RFC3658 editor>
This document as it stands is performing two actions:
         adding a new public key algorithm signing algorithm
         adding a new DS digest type.

The threshold for taking these two actions is quite different:
         the first one has a medium threshold
         while the second one has a high threshold.

Because the document is adding a new DS digest algorithm,
I oppose the adoption of the document.

Each time a new PK/digest algorithm is added there is a cost to everyone
as implementations need to be updated.  Once the IANA registry entry is made,
there is a lag before the algorithm is widely available in 
implementations, followed by a deployment lag. During this time a 
prudent organization that
has deployed DNSSEC but one that wants to migrate to the new algorithm is
"required" to sign their zone with two algorithms.
(right now there is no reliable mechanism to discover the deployment of new
algorithm support, but there is an expired ID for an EDNS0 option that can
express algorithm support).

If a zone goes exclusively with a new algorithm before the algorithm is
generally supported it (and potentially its children) will be seen as 
unsigned.

Each time a new DS digest algorithm is added zones are forced to have 
a DS record
for digest algorithm per key. Depending on how DS records are submitted to a
parent the parent may not have the ability to calculate the DS record with the
new digest.

<hat=old-DNSSEC-guy>
The early years of DNSSEC deployment were dominated to a large extent by
political considerations to a great decrement to the actual protocol work.
When DNSSEC work was started oppressive export regimes controlled use and
distribution of cryptography, and on top of that there were IP issues
surrounding the use of the preferred algorithm (RSA). During IESG review of
the draft leading to adoption of RFC2065 the IESG mandated that a second
algorithm be added: DSA.
This happened after the RSA IP holder had provided a non-discriminatory
non-fee usage license for the algorithm, and the RSA patent was expiring
in less than 2 years.

 From these experiences I have a real bitter taste of government
involvement and dealing with IPR FUD. The last thing I want to see is
that DNSSEC PK algorithms become "vanity" algorithms because if we open
that door we will see more than just one.

 From interoperabilty standpoint it is better to have fewer algorithms.

<hat=DNSSEC-crypto-guy>
The PK algorithm proposed is an elliptic curve algorithm, the WG needs to
think about adding ECC PK algorithms. I would love to see how this
algorithm stacks up against other suggested ECC algorithms: p256, p384 and
Curve25519.

We also need to know that implementations are available from multiple sources
with licenses that major vendors can use,
for example NLnetLabs and Microsoft have different policies on what they can
use in their DNSSEC implementations.

         Olafur

---

From: Edward Lewis <[email-masked]>
Date: Tue, 14 Apr 2009 15:09:17 -0400

Not a WG criteria but my thoughts...

The chief goal of the IETF process is to document approaches to 
achieving interoperability.  If someone wants to create a vanity 
algorithm for DNSSEC and there's wide-enough appeal to assign a 
number to the algorithm, then it is in everyone's interests to know 
what the algorithm number maps to - whether or not they have the 
software to make use of the knowledge.

The discouragement regarding the proliferation of vanity algorithms 
is that it is not economically sensible to generate your own 
algorithm and control it.  If you go to the expense to develop an 
algorithm and no one else adopts it into operational practice, you 
lose your investment.  Signing with your own algorithm benefits no 
one if no one can evaluate the signature, and validating your own 
algorithm is no good if there are no one generating signatures in it.

In some of the early discussions I heard about GOST my point was that 
economic interests trump both technology and politics.  I am not 
saying the GOST is a political ploy, what I am saying is that 
defining it for DNSSEC does not set a precedent for algorithms that 
might be.  (Far be it for me to be able to judge if a cryptographic 
algorithm was politically motivated.)

Encumbered algorithms aren't a threat either.  If they are so 
encumbered that the validators can't run them for free, then no one 
will sign. If signers have to pay, they will seek lower (0) cost 
alternatives and only offer them.

I think the confusion is sometimes over "registering a number", 
"mandatory to implement" and "mandatory to use."  I never advocate 
for a standard to be "mandatory to use".  To me "mandatory to 
implement" is okay if by that you mean "if you are compliant with RFC 
WXYZ" which defines the mechanism.  "Registering a number" isn't much 
of a hurdle or stage to me.  (We can always expand a number space if 
we *must*.)

At 11:29 -0700 4/14/09, Dan Simon wrote:
>Does the WG have any formal statement of criteria by which it will 
>judge this and future proposals to add algorithms to the DNSSEC 
>standard?  If not, then perhaps it should.  I'm concerned in 
>particular about two dangers:
>
>1)  The proliferation of "vanity algorithms":  Because DNSSEC is 
>expected to become an extremely widely used standard, it's also an 
>ideal conduit for entities (national governments or even 
>enterprises) that wish for one reason or another to promote their 
>own cryptographic technology.  If a bandwagon forms of governments, 
>say, using DNSSEC to promote the products of their domestic 
>cryptography communities/industries, then DNSSEC users--that is, 
>pretty much the entire world user community--will be greatly 
>inconvenienced, as they repeatedly scramble to update their software 
>to support the new algorithms.
>
>2)  Encumbered algorithms:  A particularly worrisome scenario would 
>be the adoption by the administrator of a large, important zone of 
>an IPR-encumbered algorithm, thus effectively giving the IPR owner 
>(presumably allied with the zone administrator) the power to control 
>code on the host of every single client on the planet that needs to 
>securely locate a host in that zone.
>
>There may be more dangers I haven't thought of, but these two alone, 
>I think, suffice to make it worthwhile for the WG to attempt to 
>define some formal policies regarding new algorithms in DNSSEC, 
>before charging ahead and adding them.
>
>			Just my 2c,
>
>			Dan Simon
>			Microsoft Corp.
>
>
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Andrew Sullivan

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Getting everything you want is easy if you don't want much.

---

From: Peter Koch <[email-masked]>
Date: Tue, 14 Apr 2009 22:45:42 +0200

> draft-dolmatov-dnsext-gost-dnssec-00.txt should be adopted as a WG

while formally correct, I believe the question is too narrow.  The problem is
that all the registries affected by the draft have an assignment policy of
"Standards Track", which either means WG adoption or the AD sponsored
approach.  I do not feel qualified to judge the cryptographic properties
of the algorithms involved and I'd like to understand well better than I do
currently the layer 9 issues behind the proposal.

Maybe the authors could help by explaining some of the operational considerations
for "algorithm competition" (where we've been using "algorithm agility" for
renewal and increasing resilience, so far).

In the end, we can't prevent a Babylonian variety of DNSSEC algorithms
by just not looking at the proposal.

That said, the draft mixes protocol (implementation) and operational
considerations and those should be separated IMHO.

-Peter

---

From: Dan Simon <[email-masked]>
Date: Tue, 14 Apr 2009 14:10:57 -0700

Edward, that's a very reasonable position to take in the context of DNSSEC as it is today--a little-deployed, little-relied-upon technology.  And as long as DNSSEC stays that way, of course, we all have nothing to worry about.

But I assume that most of this WG's participants, at least, expect DNSSEC to become a widely-deployed essential component of Internet infrastructure at some point in the future.  And at that point, the situation changes drastically:  zone administrators will have a great deal more leverage, because users will depend on DNSSEC for their applications to work properly and securely.

I would like to make sure that by then, the established precedents won't come back to haunt everyone.  A simple set of declared criteria, established in advance, could go a long way in that direction.

				Just my 2c,

				Dan Simon
				Microsoft Corp.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Apr 2009 14:30:53 -0700

At 10:45 PM +0200 4/14/09, Peter Koch wrote:
>I do not feel qualified to judge the cryptographic properties
>of the algorithms involved

That is a reasonable concern. The WG can ask the Crypto Forum Research Group of the IRTF for an opinion. Their charter (<http://www.irtf.org/charter?gtype=rg&group=cfrg>) says "IETF working groups developing protocols that include cryptographic elements are welcome to bring questions concerning the protocols to CFRG for advice."

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Apr 2009 14:59:01 -0700

At 11:29 AM -0700 4/14/09, Dan Simon wrote:
>Does the WG have any formal statement of criteria by which it will judge this and future proposals to add algorithms to the DNSSEC standard?

Not that I can see.

>  If not, then perhaps it should.

Doing so has not served other IETF WGs well.

>  I'm concerned in particular about two dangers:
>
>1)  The proliferation of "vanity algorithms":  Because DNSSEC is expected to become an extremely widely used standard, it's also an ideal conduit for entities (national governments or even enterprises) that wish for one reason or another to promote their own cryptographic technology.

It is a conduit, but one that comes late in the game. S/MIME, IPsec, and TLS all precede it.

>  If a bandwagon forms of governments, say, using DNSSEC to promote the products of their domestic cryptography communities/industries, then DNSSEC users--that is, pretty much the entire world user community--will be greatly inconvenienced, as they repeatedly scramble to update their software to support the new algorithms.

That has not happened in the case of the three aforementioned WGs. There are plenty of vanity algorithms (to use the derogatory term; I prefer "niche algorithm") that have been standardized in those WGs. The S/MIME WG was, I believe, the first target for GOST. Few of the common clients have support for many of those niche algorithms; the clients in the communities that encompass those niches do.

>2)  Encumbered algorithms:  A particularly worrisome scenario would be the adoption by the administrator of a large, important zone of an IPR-encumbered algorithm, thus effectively giving the IPR ow…

That makes no sense. A client does not "need" to securely locate a host in that zone. It might really want to, but every implementation decision weighs benefits against costs. IPR encumbrance adds a myriad of costs (money, lawyer time, time spent dealing with IPR zealots of many flavors, and so on).

>There may be more dangers I haven't thought of, but these two alone, I think, suffice to make it worthwhile for the WG to attempt to define some formal policies regarding new algorithms in DNSSEC, b…

I come to the opposite conclusion: the namespace is nearly free, let people use it as long as their use helps interoperability at least within their niche.

--Paul Hoffman, Director
--VPN Consortium

---

From: Dan Simon <[email-masked]>
Date: Tue, 14 Apr 2009 15:15:56 -0700

Paul, there's a huge difference between offering an algorithm for use in S/MIME, IPsec or TLS and using it to sign DNSSEC records.  In the former case, any two parties that want to ignore the new algorithm are free to do so--and as you've noted, that's generally been the response to niche algorithms.  In the case of DNSSEC, though, as long as one party finds itself in a zone whose administrator happens to be fond of the niche algorithm, anyone else wishing to locate it securely has to support the niche algorithm.  That makes DNSSEC a much more powerful (and therefore, I fear, even more attractive) lever for promoters of niche algorithms.  

Again, I understand all the economic arguments why users won't demand support for a large, motley collection of niche algorithms *today*.  But if DNSSEC becomes as widespread and depended-upon as we all hope, then those economic incentives will shift dramatically, and the DNSSEC lever will become very powerful.

				Just my 2c,

				Dan Simon
				Microsoft Corp.

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Tuesday, April 14, 2009 2:59 PM
To: Dan Simon; Andrew Sullivan; [email-masked]
Subject: RE: Request for adoption (was: [dnsext] New draft has been posted)

Not that I can see.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Apr 2009 15:35:36 -0700

At 3:15 PM -0700 4/14/09, Dan Simon wrote:
>Paul, there's a huge difference between offering an algorithm for use in S/MIME, IPsec or TLS and using it to sign DNSSEC records.  In the former case, any two parties that want to ignore the new algorithm are free to do so--and as you've noted, that's generally been the response to niche algorithms.

That's not completely true. A party who is identified by a trust anchor that uses a niche algorithm can only be verified by other parties who also know that algorithm. This is closer to...

>  In the case of DNSSEC, though, as long as one party finds itself in a zone whose administrator happens to be fond of the niche algorithm, anyone else wishing to locate it securely has to support the niche algorithm.

That's partially true. A better statement would be "In the case of DNSSEC, though, as long as one party has chosen its name to be in a zone whose administrator only signs the zone with the niche algorithm, anyone else wishing to locate it securely has to support the niche algorithm." If you need to control a zone that needs to be validated by many people, you will either pressure your superior zone to make that possible or pick a different superior zone.

>  That makes DNSSEC a much more powerful (and therefore, I fear, even more attractive) lever for promoters of niche algorithms. 

There is no stronger promotional mechanism that national laws.

>Again, I understand all the economic arguments why users won't demand support for a large, motley collection of niche algorithms *today*.  But if DNSSEC becomes as widespread and depended-upon as we…

We thought that about S/MIME, IPsec, and TLS. Only the latter has proven worth notice. Even with that, your company's web browser does not support all the niche algorithms that have been defined for TLS, much less for S/MIME and IPsec.

--Paul Hoffman, Director
--VPN Consortium

---

From: Edward Lewis <[email-masked]>
Date: Wed, 15 Apr 2009 09:25:27 -0400

At 15:15 -0700 4/14/09, Dan Simon wrote:
>In the case of DNSSEC, though, as long as one party finds itself in a zone
>whose administrator happens to be fond of the niche algorithm, anyone else
>wishing to locate it securely has to support the niche algorithm.

That is the same situation as for the other examples cited.

Outside of a brief flirtation, I have never used PGP yet can read 
mail from people that PGP'ify their email.  Securely?  Well, it 
hasn't mattered, I've never been in a situation where the "security" 
of an email message has been an issue.

When it comes to mechanisms for digital signature, the receiver can 
ignore the security cruft and still see the message.  The receiver 
does not have to buy into the security algorithm.

Backwards compatibility was one of the features we fought to keep in 
DNSSEC.  Just so "unknown algorithms" could be present and not throw 
the receiver into SERVFAIL land.  DNSSEC is supposed to be a "slap 
on" addition - not get in the way of existing operations and just add 
value to those that invest in it.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Dan Simon <[email-masked]>
Date: Wed, 15 Apr 2009 08:51:31 -0700

Edward, I agree with you completely that in scenarios, such as your PGP experience, where security is a completely unnecessary option, fallback to insecure operation is a perfectly acceptable alternative in the case of algorithm incompatibility.  Of course, if all scenarios were like that, then DNSSEC would be a complete waste of time and effort that ought to be abandoned immediately.

However, those of us who care about DNSSEC presumably do so because we believe that security in DNS is--or at least will be, in the foreseeable future--a very important and valuable feature in many scenarios.  If we're correct about that, then a statement like, "people can always fall back to insecure DNS" is not a satisfactory answer to the problem of algorithm incompatibility.  We want people to be able to rely on secure DNS, not to have to hope for the best, design more dependable alternatives, or give up on secure host location altogether.  

Let's not forget that DNS itself was once young, incomplete and untested enough that application writers made sure not to rely on it for important host location tasks.  Does that mean that we'd be comfortable with major zones adopting non-backward-compatible record formats today, since people can always fall back to whatever non-DNS methods they used back then?

				Just my 2c,

				Dan Simon
				Microsoft Corp.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 15 Apr 2009 14:37:46 -0400

At 8:51 -0700 4/15/09, Dan Simon wrote:

>However, those of us who care about DNSSEC presumably do so because we
>believe that security in DNS is--or at least will be, in the foreseeable
>future--a very important and valuable feature in many scenarios.

The question in front of us now is how to get there.

There have been a number of technologies that have died which started 
out with grand ideas but, at least in part, they were too rigid in 
their assumptions about the environment they came to an end.  I am 
thinking of Asynchronous Transfer Mode, MacOS before X, DEC, etc. 
Technologies that molded themselves to the environment have 
flourished, including MS Windows (yeah), POSIX-like operating 
systems, IEEE 802, etc.

DNS is a great example of something poorly specified succeeding 
because of it.  It's a come-as-you-want-to-be technology.  The lack 
of rigidity in operations meant it has avoided cracking at it's 
pressured points.  As we developed DNSSEC we became more and more in 
awe of this.  At first, we moaned that DNS wasn't tightly defined 
enough to be secured.  But as we struggled with the problem we began 
to admire how the flexibility had given the DNS life.

This is where we are with DNSSEC now.  If we take on a rigid stance 
when it comes to something like the cryptographic algorithms, we will 
not only crack DNSSEC (such as tempting interests to fragment and 
sign the root differently or setting up some house-of-cards 
architectural nightmare where one bump topples the entire structure) 
we will be running counter to the DNS architectural philosophy.

It is one thing to be rigid in architecture and another to be rigid 
in implementation.  I think that should be explained.  If the 
architecture is flexible we can do a lot with it.  An architecture 
should serve the needs without restricting unnecessarily the 
functions within.  Implementations are different - if an 
implementation is lax in enforcing security (drilling to that because 
that's the topic), it is hard to harden against newly considered 
threats because it is hard to enforce field upgrades and patches.  I 
mention this because DNSSEC has a restrictive trust model (the reason 
trust anchor repositories are always in the mail these days) but 
should be liberal in cryptographic work.

If the WG had cryptographic expertise I would be for restricting 
algorithms based on their cryptographic chops.  Instead, what I look 
for is interoperability, network-wide adoption and the like.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 16 Apr 2009 11:15:38 +0200

Dan,

> Edward, I agree with you completely that in scenarios, such as your PGP experience, where security is a completely unnecessary option, fallback to insecure operation is a perfectly acceptable alter…

I really don't see difference between DNSSEC and PGP (or S/MIME).
DNSSEC is not something which should be mandatory for every zone in
the DNS and it should never become so.

> However, those of us who care about DNSSEC presumably do so because we believe that security in DNS is--or at least will be, in the foreseeable future--a very important and valuable feature in many…

Those of us who care about DNSSEC will use well-supported algorithm.
Rest of the world will not use DNSSEC at all anyway - and why should
they?

Is there a value of signing all my domain names I have? Nope. I will
sign only zones which hold something important (like my blog :-P).

Also if I understand it, there are places in the world where RSA(DSA)
is not acceptable (by law) and for those people we need to provide
flexibility. I am not big supporter of entirely free market and I
think some regulations are required for the sake of people, but right
here right now I would take more laissez-faire approach.

 sip:[email-masked] tel:+420.222745110

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Thu, 16 Apr 2009 02:54:32 -0700

Ondrej and all,

  I hope you will change your mind on this.  DNSSEC is unfortunately
necessary as miscreants of various sorts are picking the DNS to pieces
at the expense of the market place to which you so well and so strongly
support.  I hope as a responsible person, that you want all users
to have a safe and secure Internet experience, and DNSSEC is one
step in moving in that positive direction.  I am also sure that your
government also feels likewise as it positively benefits the vast majority
of Check citizens by improving the safety and security of electronic trade
opertunities with my country and others accordingly.  I am sure you nor
your government wants to put at further risk IP sensitive goods as
well, and DNSSEC plays a role in reducing that risk.

Ond?ej Surý wrote:

> > Edward, I agree with you completely that in scenarios, such as your PGP experience, where security is a completely unnecessary option, fallback to insecure operation is a perfectly acceptable alternative in the case of algorithm incompatibility. Â Of course, if all scenarios were like that, then DNSSEC would be a complete waste of time and effort that ought to be abandoned immediately.
>
> > However, those of us who care about DNSSEC presumably do so because we believe that security in DNS is--or at least will be, in the foreseeable future--a very important and valuable feature in many scenarios. Â If we're correct about that, then a statement like, "people can always fall back to insecure DNS" is not a satisfactory answer to the problem of algorithm incompatibility. Â We want people to be able to rely on secure DNS, not to have to hope for the best, design more dependable alternatives, or give up on secure host location altogether.
>
> > Let's not forget that DNS itself was once young, incomplete and untested enough that application writers made sure not to rely on it for important host location tasks. Â Does that mean that we'd be comfortable with major zones adopting non-backward-compatible record formats today, since people can always fall back to whatever non-DNS methods they used back then?
> >
> > Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â Just my 2c,
> >
> > Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â Dan Simon
> > Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â Microsoft Corp.
> >
> >
> > mail from people that PGP'ify their email. Â Securely? Â Well, it
> > ignore the security cruft and still see the message. Â The receiver
> > DNSSEC. Â Just so "unknown algorithms" could be present and not throw
> > the receiver into SERVFAIL land. Â DNSSEC is supposed to be a "slap
> > NeuStar Â  Â  Â  Â  Â  Â  Â  Â  Â  Â You can leave a voice message at +1-571-434-5468
> >

Regards,

Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln
"YES WE CAN!"  Barack ( Berry ) Obama

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
[email-masked]
My Phone: 214-244-4827

---

From: Michael Graff <[email-masked]>
Date: Thu, 16 Apr 2009 05:24:38 -0500

Jeffrey A. Williams wrote:
> step in moving in that positive direction.

I know I'm going to get flamed for this...

- From my point of view, I know DNSSEC is happening, and it fixes many DNS
problems (cache attacks, the infamous ID guessing attacks).  However, I
tend to feel that an increase in transaction security would have also
fixed many of these attacks.  DNSSEC seems, in many ways, to be a very
complicated and somewhat fragile(*) solution that took 10 years to find
a problem.

We are, in deploying DNSSEC, requiring that every resolver that wants to
be secured, track a root key.  Forever.  Securely.  And all the software
has to be changed to check signatures, or otherwise be DNSSEC aware.

Since many bits of software are changing, why not just make the ID field
be 128 bits long?  EDNS provides the perfect method to do this, and the
change is far less drastic than DNSSEC.  It would cause little to no
operational impact (other than changing resolvers of course).

I know this is a rather simplistic view on things, but sometimes I
wonder if we aren't pushing DNSSEC as hard as we can for reasons that no
one but those pushing so hard can justify.

(*) Fragile, in this case:  Zones are no longer one-time configure and
leave them for years.  They have expiration dates.  So much new code is
coming into play, and the failure modes are far more and far harder to
explain to users.

- --Michael

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 16 Apr 2009 13:14:01 +0200

> operational impact (other than changing resolvers of course).

You cannot do that without backwards compatibility. And if you keep backwards
compatibility you are prone to downgrade attacks, ie.:

Case 1:
edns1_client: 128bit ID query
edns1_server: EDNS1+128bit ID response

vs.

Case 2:
edns1_client: 128bit ID query
edns0_server: normal ID response

vs.

Case 3:
edns1_client: 128bit ID query
attacker: normal ID response

(edns1_server: 128bit ID response)

How do you differentiate Case 2 and Case 3 (without some sort of handshake)?

Ondrej

---

From: Michael Graff <[email-masked]>
Date: Thu, 16 Apr 2009 06:27:47 -0500

> How do you differentiate Case 2 and Case 3 (without some sort of handshake)?

Why not have a handshake?  I know DNS is stateless, and needs to remain
so.  We're already multiplying traffic by something obscene in using
DNSSEC, it would hardly be wrong to either add such a handshake, or
retransmit more than once with a 128-bit keyid, and each retransmission
using a different 16-bit query ID, and compare the results.

Sure, that will break load balancers which return fast changing
information, but from what I remember DNSSEC already does that too.

I'm not anti-DNSSEC, btw.  I think it is what will happen, if only that
it has a lot of effort behind it.  I'm just not certain it is the right
solution to the problems people seem to hope it to fix, and the problems
it causes and the price people pay to use it are not insignificant.

- --Michael

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 16 Apr 2009 06:05:56 -0700

OOPs: minor corrections...

Non-upgraded authorities see TRIPLE the load.

And yes, I was previously down on double-sided changes outside of  
DNSSEC in the past.  I've changed my mind, as a result of Ondrej  
Sury's question, which made me realize we can handle the "downgrade"  
attack and maintain compatibility.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 16 Apr 2009 06:01:56 -0700

> compatibility you are prone to downgrade attacks, ie.:

Actually, you are NOT prone to downgrade attacks.  Here's why:

In order to construct a downgrade attack, the attacker needs to be in  
path.

And as I repeatedly rant, I dont' care about in-path attackers (except  
for the ISP's own recursive resolver) when securing DNS, because DNS  
isn't the end protocol, and if the end-protocol is vulnerable to an in- 
path attacker, its dead anyway regardless of DNSSEC, and if the end- 
protocol is immune to an in-path attacker, it never really trusted the  
DNS name.

And frankly, we can use the marketplace and incentives to solve the  
out of path attacker by the EDNS extended query ID mechanisms:

edns-ping_resolver: 128bit ID query

If the authority (or attacker) doesn't include the extended query ID  
in response:

a)  Do two more queries, if the results are identical, accept it.  If  
the second or third reply includes the correct extended query ID,  
accept that.  (Handles the attacker case).

b)  If the name is NOT stable, do a TCP connection to the server for  
the query.

c)  If it refuses TCP, accept one of the three results but DO NOT  
CACHE THE RESULT.

Thus you have effectively full backwards compatibility, AND protection  
from downgrade attacks:

For stable names:

If the server is not upgraded to do the 128b edns reply, it just sees  
at most double the load.

Attacker can't do a downgrade attack, as he needs to with 3 races in a  
row.

For unstable names:

If the server is not upgraded to do the 128b edns reply:  If the name  
is made slightly stable (2-3 queries from the same resolver in a  
couple of seconds sees the same result), it just sees at most double  
the load.  Attacker can't do a downgrade attack.

If the server is not upgraded and the name is unstable:  It sees a  
large TCP load.  Attacker can't do a downgrade.

If the server is not upgraded, the name is unstable, and it refuses  
TCP:  It sees a huge increase in requests as they are not cached.   
Attacker is limited to blind transaction attacks rather than blind  
cache attacks (FAR less powerful an attack).

But you notice: it still all works, and now there is a nice incentive  
not to screw up, and an attacker can't just ignore the EDNS bit in its  
reply, because you still have the legitimate server, and the attacker  
would have to win THREE races in a row.

Thus:

a)  THe attacker has to guess a 128b EDNS query ID, for all cases  
except unstable, non-TCP supporting names
a')  Even against unstable, non-TCP supporting names, the attacker is  
now limited to blind transaction attacks.

b)  DNS still works, with good protection, for stable names without it  
(3x queries with 0x20 -> >60b of entropy),

c)  DNS still works, for unstable names without it.

d)  Partial deployment WORKS!, as authorities will slowly see their  
load increase as resolvers are updated, if the authorities don't change.

So although an EDNS ping is a "double sided" change, its an actually  
deployable double-sided change.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 16 Apr 2009 15:43:24 +0200

Hi Nicholas,

Thank you for this very good EDNS ping story.  The EDNS ping draft
should be saying this sort of thing.  Your work completes the draft nicely.

The actions look reasonable to me; but you forget to factor in that if
the three outstanding queries are done at the same time, some sort of
birthday paradox would happen (since fake packets can match 3 queries at
the same time).

> Non-upgraded authorities see TRIPLE the load.

Well, how about my forgery-resistance draft; it also has the same work -
about triple the load, but only requires resolver deployment.

I think it worth protecting the in-path too.

Best regards,
   Wouter

---

From: Paul Vixie <[email-masked]>
Date: Thu, 16 Apr 2009 13:54:45 +0000

michael, no flame intended here.  path security helps against various kinds
of problems but does nothing for "provider in the middle" attacks where a
hotel middlebox, or a load balancer, or an nxdomain remapper, can break the
"domain owner's intent : rrset content" mapping.  this, combined with the
comparatively minor problem of kaminsky-style poisoning or other off-path
attacks, means that there is no reason for confidence in dns's results,
which discourages the development of a whole class of applications.  (and
as kaminsky has showed, it also fails to discourage a whole class of
applications who show designed-in misplaced confidence in the answers they
get from dns.)

i've been flogging dnssec all these years not because of problems that a
larger TID or universal deployment of BCP38 would have solved, but because
i want to enable to creation of new dnssec-aware applications which behave
differently in the presence of signed data.  there is no way to justify
dnssec's costs (to date or as projected) on the basis of kaminsky alone.

--paul

re:

> Date: Thu, 16 Apr 2009 05:24:38 -0500
> From: Michael Graff <[email-masked]>
> User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
> To: "Jeffrey A. Williams" <[email-masked]>
> CC: Ond?ej Surý <[email-masked]>, 
>  Dan Simon <[email-masked]>,
>  "[email-masked]" <[email-masked]>, 
>  doc/ntia DNSSEC <[email-masked]>,
>  USTR General contact <[email-masked]>
> Subject: [dnsext] Re: Request for adoption
> Sender: [email-masked]
> 
> From my point of view, I know DNSSEC is happening, and it fixes many DNS
> --Michael

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 16 Apr 2009 16:14:27 +0200

On Thu, Apr 16, 2009 at 3:01 PM, Nicholas Weaver
<[email-masked]> wrote:
> Actually, you are NOT prone to downgrade attacks.

True, if you deploy more forgery resistance techniques like n*queries (which
could be deployed without 128bit ID/EDNS ping). Simple 128bit ID won't help
here. But thanks for clarification.

Ondrej

---

From: Paul Vixie <[email-masked]>
Date: Thu, 16 Apr 2009 15:34:07 +0000

> >> You cannot do that without backwards compatibility. And if you keep
> >> backwards compatibility you are prone to downgrade attacks, ie.:
> >
> True, if you deploy more forgery resistance techniques like n*queries
> (which could be deployed without 128bit ID/EDNS ping). Simple 128bit ID
> won't help here. But thanks for clarification.

adding more queries brings all kinds of questions of its own like which one
to use if the answers aren't all the same.  also, punishing folks who don't
upgrade by increasing their load.  (dns-0x20 does this also, but the size of
the punished population is smaller, being limited only to folks who downcase
or upcase QNAMEs in their responses, which was never prohibited or required.)

i think that any effort beyond dns-0x20 to secure against off-path attackers
is misplaced.  dns must be secured end to end, which will not only enable a
new class of dnssec-aware applications, but obviate the need to secure dns
hop by hop.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 16 Apr 2009 16:41:37 +0000

> ..., it is too bad that we didn't fix the underlying cause of a
> lot of the, the ID being too short.

i think the lack of BCP38 deployment is the prime underlying cause of
far more badness than anything having to do with the size of the TID.

---

From: Michael Graff <[email-masked]>
Date: Thu, 16 Apr 2009 11:37:50 -0500

Paul Vixie wrote:
> "domain owner's intent : rrset content" mapping.

Count my ranting up to a sleep-deprived brain working to hard on a
particular problem last night.  I clearly wasn't able to say what I meant.

What I was TRYING to get at is that while we're all here changing all
this stuff, it is too bad that we didn't fix the underlying cause of a
lot of the, the ID being too short.

Clearly I need to block port 25 on my firewall and use enabling it as a
consciousness test.

- --Michael

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Apr 2009 10:43:55 -0700

> has to be changed to check signatures, or otherwise be DNSSEC aware.

The current state of the art is that DNS is not secure: it's quite  
common to encounter access provider dns caches, for example in hotels,  
that lie when answering DNS requests.   So currently, for secure  
transactions, we rely on the SSL cert authority chain, which is a  
database of, essentially, root keys, which need to be tracked.    
Securely.  Forever.

You're right that this isn't great, but there's no better alternative  
- this is as good as it gets, unless you know something I don't.    
(pun intended)   The good thing about having DNSSEC is that now we  
have two security systems an attacker needs to suborn at the same time  
in order to fully phork your web browser.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 16 Apr 2009 21:45:31 +0200

* Paul Vixie:

> to use if the answers aren't all the same.

If you want to do more queries, use it to contain the amplification
factor of a poisoned cache.  What's attractive about a compromised
cache is that you invest a few thousands (or billions) of packets, and
you affect a large client base.

To deal with that, you can avoid caching fast-changing DNS data.  So
after a cache miss, a fresh RRset is used to answer the first query
only.  If a second query for the same name arrives, a new upstream
query is performed, and if the results match the cached data, it is
used for the next 10 queries (say), and after that, for the next 100
queries, and so on (but traditional, TTL-oriented caching can be
activated after a few iterations).  If there is no match, the new data
is stored in the cache and returned to the client, and a counter for
fluctuating responses is incremented.  This counter is reset to zero
when a matching response is encountered, and the process starts from
the beginning.  If the fluctuation counter is non-zero, queries are
treated as cache misses, until the a certain threshold is reached
(5?), when the RRset is cached TTL-oriented.  Upon TTL expiration,
entries are not removed from the cache, but kept so that the ramp-up
phase can be avoided despite the fresh upstream query.  (I suppose
validators are already doing something like that, to save the
cryptographic operation if the data hasn't actually changed.)

This is somewhat analogous to how ATM cell boundaries are discovered
in a bit stream, IIRC.

For a resolver which is not vulnerable to TTL-agnostic, Kaminsky-style
spoofing attacks, this approach increases the spoofing risk because
there are more upstream queries, but the impact of a spoofed response
will be a very, very few wrong responses to clients (basically just
one, or eleven if you manage to spoof twice in a row).

The main problem with this approach is that it might require caching
referrals and in-zone authoritaty data separately, which will add
considerable overhead to some cache implementation strategies.  It is
also not clear if the parameters (exponential decay and staturation
for the non-fluctuating case, upper limit for the fluctuation counter)
can be tweaked so that the upstream query load increases by just an
acceptable factor.  There is no additional latency for clients if
not-fully-confirmed cached RRsets are used for answers, and the
additonal upstream query is issued in the background.

I can elaborate on this approach if you want (I think I might still
have a writeup of the actual algorithm somewhere).  But in the end,
it's really a "query multiple times" approach, and I think we had
ruled that out.

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Thu, 16 Apr 2009 18:13:02 -0700

Paul and all,

  Paul makes a very good point, but draws less than accurate final
conclusion.  It is not known if the costs associated with DNSSEC
cannot be justified on a large scale, and with various sorts of
miscreant behavior increasing at an alarming rate, I would predict
that DNSSEC will vastly improve holding down those costs of
policing and managing the effects of these miscreants.

  It is true as Paul declares that DNSSEC does not aid much if
at all in man-in-the-middle attacks, which are also quite pervasive
and increasingly so.  But kaminsky-style poisoning can at least be
easily identified and than a method of dealing with such can than
be effected and done so in any number of ways.

Regards,

---

From: Jim Reid <[email-masked]>
Date: Fri, 17 Apr 2009 14:34:58 +0100

On Apr 16, 2009, at 11:24, Michael Graff wrote:

> be 128 bits long?

Although this would of course make QueryID prediction harder, how will  
this provide a defence against tampering with the DNS data as  
responses traverse the network or even detect that one of those  
attacks has happened?

---

From: Jim Reid <[email-masked]>
Date: Fri, 17 Apr 2009 14:35:15 +0100

On Apr 16, 2009, at 12:27, Michael Graff wrote:

> Why not have a handshake?

Because there's no way of knowing for sure who's hand you're shaking.  
Or have I missed something?

> I know DNS is stateless, and needs to remain so.

How would this statelessness be preserved if a handshake was added?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 17 Apr 2009 16:07:49 +0200

On Thu, Apr 16, 2009 at 05:24:38AM -0500,
 Michael Graff <[email-masked]> wrote 

> Since many bits of software are changing, why not just make the ID field

Good idea, IMHO, and already presented:

http://tools.ietf.org/html/draft-eastlake-dnsext-cookies

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 17 Apr 2009 07:13:01 -0700

On Apr 17, 2009, at 6:34 AM, Jim Reid wrote:

> Although this would of course make QueryID prediction harder, how  
> will this provide a defence against tampering with the DNS data as  

That is describing an in-path adversary.

In path adversaries blow away anything in the absence of cryptography.

The problem is, in-path adversaries DON'T REALLY MATTER for DNS.  DNS  
is not the application.  The final application is the application.

If the final application is vulnerable to an in-path adversary, the  
adversary can attack the application directly, and doesn't need to  
bother attacking DNS.

If the final application is resistant to an in-path adversary, the  
application doesn't (and can't) trust DNS.

DNSSEC's resistance to in-path attackers doesn't matter for the  
purposes of looking up names.  It only matters if you want a cheaper  
PKI.

---

From: Jim Reid <[email-masked]>
Date: Fri, 17 Apr 2009 15:26:07 +0100

On Apr 17, 2009, at 15:13, Nicholas Weaver wrote:

> The problem is, in-path adversaries DON'T REALLY MATTER for DNS.

I disagree. Let's meet in a bar to argue this.

> DNS is not the application.

That might be the case for 99% of the time today but it might not  
always be so if/when the DNS gets used for stuff like identity  
management or ubiquitous RFID tags and so on.

---

From: Alex Bligh <[email-masked]>
Date: Fri, 17 Apr 2009 15:46:13 +0100

--On 17 April 2009 15:26:07 +0100 Jim Reid <[email-masked]> wrote:

> That might be the case for 99% of the time today but it might not always
> be so if/when the DNS gets used for stuff like identity management or
> ubiquitous RFID tags and so on.

Putting aside Jim's point, and the question of whether or not having
multiple layers of protection is valuable, from an operational point
of view, even if https://www.example.com/ shows a bad cert,
having (e.g.) "traceroute www.example.com" capable of interception is less
than helpful.

Alex

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 17 Apr 2009 08:29:06 -0700

On Apr 17, 2009, at 7:46 AM, Alex Bligh wrote:

>> always

And if DNSSEC was free, I'd agree with you.

However, there are tons of applications which are not secure against a  
MitM, and DNSSEC, improperly deployed, will cause all of those to stop  
working because most DNSSEC failures are not going to be attacks, but  
screwups.

This is why I actually advocate the following policy for DNSSEC for  
stub resolvers:

If, for any reason, the DNSSEC signature validation fails (out of  
date, wrong signature, no trust anchor, no DNSSEC information at all)  
on a normal application lookup, the stub resolver conducts its own  
recursive lookup, bypassing its recursive server, and accepts that.

Any true DNSSEC-aware application will obviously be unable to get the  
key data it needs (so that all works "secure" and fails), but all the  
non-DNSSEC-aware applications will still get the name information, and  
it counters the one adversary which is in-path on DNS but out-of-path  
on the application traffic: the ISP's recursive resolver.

However, unless an application is specifically DNSSEC-aware (not just  
doing normal lookup, but asking for keying material out of DNS and  
validating it with DNSSEC), turning on DNSSEC in this model provides  
almost no increase in real-world security, it just makes sure that it  
doesn't provide a huge decrease in real-world availability.

And as for your specific example, traceroute itself isn't secure  
against an in-path adversary.  So who cares if traceroute gets "www.example.com 
"'s IP correct?

---

From: Alex Bligh <[email-masked]>
Date: Fri, 17 Apr 2009 17:10:17 +0100

--On 17 April 2009 08:29:06 -0700 Nicholas Weaver 
<[email-masked]> wrote:

> And as for your specific example, traceroute itself isn't secure against
> an in-path adversary.  So who cares if traceroute gets
> "www.example.com"'s IP correct?

I was being slightly elliptic. My point was that it even tools you
would not think of as needing any form of MtiM protection etc. benefit.
After all, traceroute is a useful diagnostic tool today. At the minimum
it tells you that either X is the route taken to a specific host, OR
someone along the route is faking / disguising that route by producing
the relevant ICMP responses. Whilst we all know BGP route injection
attacks are possible, they are (currently) rare. Heuristically, traceroute
is useful.

If you build in protection /only/ at the app-to-app layer, then I
can see two probably results, assuming prevalence of DNS attacks.

1. When you see a cert that doesn't match or whatever, you have no
   or fewer ways of debugging it, as you trust the underlying infrastructure
   less.

2. Whilst the app-to-app protection will, if successfully deployed (*)
   make impersonation attacks harder, DNS poisoning etc. can be used
   for an easy DoS vector or vector for attacks on unsuccessful
   deployments.

(*) = recent activity has shown that (e.g.) SSL certificates provide
poor protection when CAs are prepared to hand out certs to all and
sundry. SSL also comes at a cost. So your argument that DNSSEC
can be badly deployed, and comes at a cost applies elsewhere in
the stack too. Of course there are questions of degree here.

Alex

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Apr 2009 11:09:20 -0700

> is not the application.  The final application is the application.

You've repeated this over and over again, but I don't think it's any  
more true than it was the first time you said it.   It's been  
demonstrated that the most commonly-used security technology out  
there, SSL, is vulnerable if the DNS is vulnerable, and is less  
vulnerable if it is not.

So the question is not whether securing DNS against in-path  
adversaries makes anything more secure, but rather whether the degree  
of security it adds justifies the cost of implementation.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 17 Apr 2009 14:33:20 -0400

At 11:09 -0700 4/17/09, Ted Lemon wrote:
>more true than it was the first time you said it.

I agree with Ted, both about the fallacy and the repetition of it. 
I've not responded before because I didn't want to take time to 
explain the reasons myself, but just for the record, forged (etc.) 
records sent by elements "in-path" matter as much as forged records 
from any other source.

If the application relies on an environmental element that is not 
safe, the application is not safe.  An application can take many 
steps to make itself safe but if the environment is malicious, the 
application won't succeed.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Fri, 17 Apr 2009 18:11:02 -0700

Nicholas and all,

  Good points!  Application security obviously is important,
and using secure coding techniques is very advisable.  Developing
means of detecting less than secure applications is also advisable
if not paramount if global financial trade is to become far more
safe than it is today.  Unfortunately this will require very carefully
crafted regulation, which I don't like but recognize that the private
sector via self regulation is unwilling to do our/themselves to the
extent necessary.

  This said, I am not yet confident that government(s) are truly
up to the task or have the political will as such regulations will be
strongly opposed from many business sectors.

 Regards,

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Fri, 17 Apr 2009 18:17:46 -0700

Jim and all,

  Also a goo point, but at present a weak one.  Yet what you
seem to be suggesting might be a means by which good and
effective regulation could be crafted around.  Still if so, opposition
would be significant and with a number of very good arguments
in support.

Regards,

---

From: "George Barwood" <[email-masked]>
Date: Mon, 20 Apr 2009 13:08:05 +0100

----- Original Message ----- 
From: "Paul Vixie" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, April 16, 2009 4:34 PM
Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption )

> or upcase QNAMEs in their responses, which was never prohibited or 

There is a trade-off, better security versus more DNS packets.

The question of what to do if answers aren't all the same is addressed in my 
draft
https://datatracker.ietf.org/drafts/draft-barwood-dnsext-fr-resolver-mitigations/

> is misplaced.

Can you give reasons? I can think of a few, although I don't think they are 
valid, there may be more:

(i) The actual situation ( provided ISPs use port randomization ), is not 
too bad.

Answer: as an IT manager, I would wish to install software that is as secure 
as possible, not relying on unknown third parties to operate as securely as 
possible.

(ii) The increased load on DNS servers/networks is unacceptable.

Answer: I don't believe this is true. But please state this explicitly if 
you think this is the case.

(iii) FUD : any change carries some risk.

Answer: it's true that implementing repetition in a resolver is quite 
complex. But I think it is doable.

(iv) It's better to solve the problem with BGP.

Answer: I'm afraid this is somewhat outside my knowledge, but answer is same 
as for (i).

> dns must be secured end to end, which will not only enable a

The case for DNSSEC, as has been observed by Nicholas Weaver on many 
occasions, is quite weak/unclear.

It is the application that must be secured end to end, and this is a 
cost/performance trade off.

Can you give an example of such a dnssec-aware application?

---

From: bert hubert <[email-masked]>
Date: Mon, 20 Apr 2009 16:47:55 +0200

> new class of dnssec-aware applications, but obviate the need to secure dns

Well.. Be that as it may, EDNS-PING is an easy upgrade. In fact, it is
out there today. In addition, as far as I understand it, DNSSEC can
still be disrupted easily enough at the delegation point if DNS
responses can be spoofed. This might lead to prolonged (perceived)
downtime.

This in turn leads to people asking the question what good DNSSEC is
if it can be
spoofed into downtime this easily (either in-path or out-of-path).

So even if you think DNSSEC is the answer to all your questions, it
may turn out that it isn't in practice.

   Bert

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 20 Apr 2009 08:13:15 -0700

> Can you give an example of such a dnssec-aware application?

A good example would be an extension to SSH.

On "leap of faith" (first time encountering a new key), an DNSSEC- 
aware ssh client could fetch the key through DNS and validate the  
DNSSEC signature, rather than just trusting the key the first time.

DNSSEC is really a PKI infrastructure with one huge important  
difference compared with all the other PKI schemes out there:

Rather than the authority signing for you a specific certificate, the  
authority is signing a full signing certificate (making you an  
authority as well), but with your authority limited to within the  
domain name you control, automatically matching your key-signing  
authority with your existing name-creation authority.

This provides several advantages in usability over the certificate  
schemes used in, say, HTTPS:

a)  It reduces the proliferation of trust anchors.  Look at firefox:   
There an an absolute truckload of certificate authorities listed in a  
default install.  If any one of these certificate authorities have a  
problem, HTTPS has a problem.  Yet it still doesn't include important  
ones (like the DOD CAs!).

Compare this with DNSSEC where, once the right political problems are  
solved, there becomes one trust anchor with the root.

b)  It aligns trust in signatures with existing relationships/trust in  
names.

c)  It is vastly cheaper than other PKI schemes.  Because you are  
given a signing certificate, you no longer need to go back to verisign  
or thawte or any of the other companies when you want to change a  
certificate on an end host, add a new subname or subdomain, use a  
different type of certificate (code signing vs mail signing vs TLS),  
etc.

There are TONS of things I could do with such a cheap PKI.  EG, just  
opportunistically encrypt ALL traffic between end-hosts by using IPSec  
ubiquitously, with DNSSEC to get the keys.  Or have the web browser  
accept self-signed certificates on port 80, IFF it can validate the  
certificate through DNSSEC.

But it requires understanding that DNSSEC's primary value is providing  
this PKI to secure Name->Key mappings, not securing Name->Address  
mappings.

It also means that providing a good API for doing these lookups,  
regardless of the state of the stub resolver and recursive resolver,  
with useful error reporting when failures happen, is probably the best  
next step in getting DNSSEC adopted, because thats whats needed for  
applications to really take advantage of DNSSEC.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Apr 2009 16:43:28 +0000

> From: "George Barwood" <[email-masked]>
> Date: Mon, 20 Apr 2009 13:08:05 +0100
> 

nope, that's not the tradeoff we'd be making.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Apr 2009 16:45:06 +0000

> From: bert hubert <[email-masked]>
> Date: Mon, 20 Apr 2009 15:58:03 +0200
> 
> out there today. ...

this is an easy upgrade for an implementor, or for a single operator.  it
is NOT an easy upgrade for the industry, nor will it be if it happens to
try to occur unplanned/organically.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Apr 2009 17:07:01 +0000

> So I am unsure where you base your claims on that it is not an easy
> upgrade - almost nobody noticed.

the industry is much larger, in extent and in time, than you're measuring.

---

From: Tony Finch <[email-masked]>
Date: Mon, 20 Apr 2009 18:25:14 +0100

> using a different 16-bit query ID, and compare the results.

You can't compare latency and bandwidth like that.

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: bert hubert <[email-masked]>
Date: Mon, 20 Apr 2009 19:04:54 +0200

> try to occur unplanned/organically.

It is out there already on some of the largest nameservers on the
planet in terms of zones. In fact, the resolver component has briefly
been trialled by a huge incumbent telco. This discovered a small
number of interoperability errors, but also discovered that between 1
and 5% of all queries could already be protected by EDNS PING. For my
own household, this number is >25%.

We even have the BIND patches ready.

So far it appears there is a very small number of servers that
misbehave on receiving an EDNS-PING adorned query - mostly F5 load
balancers. F5 is already aware of the issue.

      Bert

---

From: [email-masked] (Andreas Gustafsson)
Date: Mon, 20 Apr 2009 20:38:18 +0300

bert hubert wrote in regard to EDNS PING:
> planet in terms of zones.

Could you please point us to a working URL for a public specification
of the EDNS PING protocol as implemented by these servers?
-- 
Andreas Gustafsson, [email-masked]

---

From: bert hubert <[email-masked]>
Date: Mon, 20 Apr 2009 19:58:39 +0200

> of the EDNS PING protocol as implemented by these servers?

Andreas - of course. The EDNS PING draft only specifies *how* to send
an EDNS PING request, and also how to respond to one if you are so
inclined.

It does not specify when or how one should use such a request.

All relevant information is on http://edns-ping.org and specifically
http://edns-ping.org/draft

The copy of the draft on the IETF servers has sadly expired, I'll
upload a new one later today or this week.

Kind regards,

Bert Hubert

---

From: Edward Lewis <[email-masked]>
Date: Mon, 20 Apr 2009 15:00:41 -0400

A few comments.

(Looking at the subj: line) - this isn't a request for adoption of EDNS PING?

(Quibble and not the reason I am replying, but) I think the web page 
is misleading when it says "EDNS-PING is currently specified by an 
IETF draft" because the IETF has not vetted this at all.  I would 
accept that it is "documented" but claiming it's specified - well, 
okay, this is a quibble, but "specified" makes it sound like this is 
a vetted concept.

My issue with EDNS-PING (section 3.3) is that the "opaque payload" 
has to be unpredictable (random) or it's like carrying cement blocks 
in the back of your car for more traction in summer.  (I.e., if the 
payload is always "DNS Rulz" then the attacker doesn't even have to 
off-net to forge it.)

If the payload then requires (some sort of) 
unpredictability/randomness then there's all that state to maintain 
(per query), as well as having to generate the payload.  This might 
lead to a notice in the security section that a heavy baseless query 
load might be there to DoS the recursive service.  I'd say all this 
if the document came into the WG, probably in more detail and 
certainly more discussion in the event I missed something.

Besides the exposed workload on the cache, this just gets you 
assurance the intended remote end answered your query.  You can't 
tell if the remote end diddled the bits, etc.  (Perhaps that's good 
enough though.)

Comparing this to DNSSEC, I don't see a big win.  Sure you save the 
authority side coordination but you lose source authenticity. 
EDNS-PING does less work for less cost.  And I presume that DNSSEC is 
assumed to be a lot of work in operations (I'm not so sure of that 
once it gets past the deployment phase).

It is cool that this is work which puts the onus on the end points to 
carry this out, taking the middle boxes of DNS production out of the 
game.  But without the middle boxes (here the registries and 
authoritative servers) participating, there's no proof that the 
received data started from the proper location.

---

From: [email-masked]
Date: Mon, 20 Apr 2009 19:03:42 +0000

> try to occur unplanned/organically.

	are you advocating centralized planning, a flag day, or
	are you indicaating that EDNS-PING is doomed?

--bill

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Apr 2009 19:22:06 +0000

> 	are you indicaating that EDNS-PING is doomed?

neither.

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 20 Apr 2009 12:37:37 -0700

On Apr 20, 2009, at 12:00 PM, Edward Lewis wrote:
> If the payload then requires (some sort of) unpredictability/ 
> randomness then there's all that state to maintain (per query), as  
> well as having to generate the payload.  This might lead to a notice  
> in the security section that a heavy baseless query load might be  
> there to DoS the recursive service.  I'd say all this if the  
> document came into the WG, probably in more detail and certainly  
> more discussion in the event I missed something.

The amount of stateholding you are talking about is trivial.  Lets  
assume a truly MASSIVE resolver, handling 1M outstanding queries, and  
it needs to hold an additional 32B of state per outstanding query.   
Thats a whopping 32 MB of state.  Or, at current market prices, less  
than $.25 of DRAM.

Any recursive resolver which could be DOSed by the stateholding  
requirements of an EDNS-Ping is broken.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 20 Apr 2009 16:26:57 -0400

At 12:37 -0700 4/20/09, Nicholas Weaver wrote:

>The amount of stateholding you are talking about is trivial.

Memory usage is trivial in context.  The bigger issue is that this is 
just another hop-by-hop security mechanism.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 20 Apr 2009 19:57:34 -0400 (EDT)

On Mon, 13 Apr 2009, Andrew Sullivan wrote:

> This is a request that WG members to express their opinion as to 
> whether draft-dolmatov-dnsext-gost-dnssec-00.txt should be adopted 
> as a WG item.

I am happy to have this document become a WG item, though I hope we 
will hold off on making the assignments (=publishing) until we have 
seen at least two implementations, thus demonstrating that the spec is 
reasonably complete and the licensing terms reasonable.  That us 
normally the metric for Draft Standard, not Proposed Standard, but 
this is a pretty small change.  We had similar implementation 
experience when we defined SHA2 DS records (RFC4509), and we will have 
it for the rsasha256 draft.

I strongly support asking the IRTF's CFRG for a review of this work.

Like Paul Hoffman, I disagree with Dan Simon's argument that we need a 
general policy about adding new algorithms.

Further comments on the document:

First, this is a delightfully complete -00 draft.  Good job.  I 
particularly like already having a DNSKEY example.  I hope you will 
add RRSIG and DS examples, too.  Because of the strong use of outside 
references, I am not sure that the wire and presentation format 
details are adequately specified, but I suspect implementation 
experience will clear that up.

I specifically support the inclusion of the new DS digest algorithm. 
Perhaps I don't fully understand Olafur's objection to that or why DS 
digest algorithms should have a higher bar than public key algorithms. 
I'm happy to be enlightened.

There was some complaint about mixing implementation and operational 
considerations.  Section 7.2, at least, is entirely necessary (that's 
the "NSEC3 is allowed for this algorithm" statement).  The 
recommendation in section 7.1 ("...SHOULD be able to 
support...GOST...") may be too strong, but I would like to reserve 
judgement.  Please leave it marked as an open issue.

The document assigns a new hash algorithm for NSEC3 (for hashing 
names).  This is the first new NSEC3 hash algorithm, so something more 
is required.  Quoting RFC5155:

    Although the NSEC3 and NSEC3PARAM RR formats include a hash
    algorithm parameter, this document does not define a particular
    mechanism for safely transitioning from one NSEC3 hash algorithm to
    another.  When specifying a new hash algorithm for use with NSEC3,
    a transition mechanism MUST also be defined.

Rather than trying to define a transition mechanism, I suggest that 
the NSEC3 hash algorithm assignment be dropped entirely.  Your choice. 
If you do keep this assignment, it needs to be mentioned in the intro 
and abstract, which is not currently done.

Lastly, edit Section 7.2 to insert "may".  Old:

    RFC5155 [RFC5155] defines new algorithm identifiers for existing
    signing algorithms, to indicate that zones signed with these
    algorithm identifiers use NSEC3 instead of NSEC records to provide
    denial of existence.

New:

    RFC5155 [RFC5155] defines new algorithm identifiers for existing
    signing algorithms, to indicate that zones signed with these
    algorithm identifiers may use either NSEC3 or NSEC records to
    provide denial of existence.

-- Samuel Weiler

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 21 Apr 2009 09:40:08 +0200

On Mon, Apr 20, 2009 at 05:07:01PM +0000,
 Paul Vixie <[email-masked]> wrote 

> the industry is much larger, in extent and in time, than you're measuring.

With this reasoning, DNSSEC is doomed as well, because many
middleboxes, firewalls, load balancers, etc, have problems with
DNSSEC, too.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 21 Apr 2009 09:46:55 +0200

On Mon, Apr 20, 2009 at 03:00:41PM -0400,
 Edward Lewis <[email-masked]> wrote 

> tell if the remote end diddled the bits, etc.  (Perhaps that's good

Well, EDNS-ping protects the channel, not the data. It is not a direct
competitor of DNSSEC, rather an extension to RFC 5452. 

Now, we could discuss for years wether channel protection is better
than data protection or vice-versa. I would say we need both:
ultimately, DNSSEC rulz and replaces everything but security often
requires several defenses combined.

---

From: Shane Kerr <[email-masked]>
Date: Tue, 21 Apr 2009 11:20:57 +0200

Paul,

> new class of dnssec-aware applications, but obviate the need to secure dns

I agree somewhat, although there is some room for hop-by-hop work:

1. opening the field up for encrypted DNS queries
2. securing the *last* hop

I know #1 was declared out of scope 15 years ago, but that does not mean
this cannot be re-visited.

There may be some text that gives recommendations on #2, but I'm not
familiar with it.

Finally, I do think there is room for adopting clever techniques like
DNSCurve, even if they "only" secure hop-by-hop.

--
Shane

---

From: "Aki Tuomi" <[email-masked]>
Date: Tue, 21 Apr 2009 12:50:52 +0300

> From: [email-masked] [mailto:owner-
> [email-masked]] On Behalf Of Shane Kerr
> Sent: Tuesday, April 21, 2009 12:21 PM
> To: Paul Vixie
> Cc: [email-masked]
> Subject: Securing hop by hop (was Re: EDNS ping mechanisms (was [dnsext]
> Re: Request for adoption))
> 
> Paul,
> 
> Paul Vixie wrote:

Isn't it sufficient security if you can secure each hop in the path? I know security isn't transitive relation, but if you secure the hop a->b->...->end you can be quite confident. The path a->end isn't secure by definition, but I think it is in practice. 

---
Aki Tuomi
TDC Oy

������r��zǧu���Ơz�'jg���iz�+z����)�'�~���+a����n�˛���m�jȧ�W��w���^��,j�{[�ܚ��b��m�����"z����l�v�y�覗��

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 21 Apr 2009 12:12:10 +0200

On Tue, Apr 21, 2009 at 12:50:52PM +0300,
 Aki Tuomi <[email-masked]> wrote 
 a message of 47 lines which said:

> Isn't it sufficient security if you can secure each hop in the path? 

No. Counter-example: a recursive name server has been oWn4ed by a
cracker. It puts on it a rogue DNS program which modifies responses
(for instance, replaces NXDOMAIN by the IP address of an advertisment
server). In that case, only end-to-end security protects you.

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 21 Apr 2009 03:39:27 -0700

> server). In that case, only end-to-end security protects you.

How does DNSSEC protect you against this scenario?  If the rogue DNS
program also strips all DNSSEC records, how does the client know
anything is wrong?

---

From: Basil Dolmatov <[email-masked]>
Date: Tue, 21 Apr 2009 15:07:51 +0400

> server). In that case, only end-to-end security protects you.
Yes. That depends on the fact whether you trust to _all_ intermediate 
nodes or not.

Hop-by-hop security secures _transport_ between nodes _only_.
It does not secure from any erroneous or malicious operation on any 
intermediate node.

dol@

---

From: Basil Dolmatov <[email-masked]>
Date: Tue, 21 Apr 2009 15:10:07 +0400

Matthew Dempsky пишет:
> How does DNSSEC protect you against this scenario? 
It does not.
If non-DNSSec records are allowed to coexist with DNSSec ones.
> If the rogue DNS
By the absence of DNSSec information which was expected to arrive.

dol@

---

From: Florian Weimer <[email-masked]>
Date: Tue, 21 Apr 2009 13:12:13 +0200

> program also strips all DNSSEC records, how does the client know

If it's validating, it will notice the lack of DNSSEC RRs for the
zones for which trust anchors are available.  If you strip DNSSEC RRs
further down the tree, the validator will see an invalid (BAD/Bogus)
signed delegation at some point.

(If it's not validating, it will process whatever it receives, of
course.)

-- 
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: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 21 Apr 2009 13:17:58 +0200

On Tue, Apr 21, 2009 at 03:39:27AM -0700,
 Matthew Dempsky <[email-masked]> wrote 
 a message of 9 lines which said:

> > cracker. It puts on it a rogue DNS program which modifies
> > responses (for instance, replaces NXDOMAIN by the IP address of an
> > advertisment server). In that case, only end-to-end security
> > protects you.
> 

You note I was careful not to mention DNSSEC...

> If the rogue DNS program also strips all DNSSEC records, how does
> the client know anything is wrong?

DNSSEC will protect you in that case if the rogue server is not the
validating one. So, DNSSEC will detect the cheating in cases like:

* the cheater is a rogue secondary authoritative name server for the
  domain,

* there is a validating nameserver on the user's machine,

* and in other, more complicated cases (such as several recursors
chained).

---

From: Shane Kerr <[email-masked]>
Date: Tue, 21 Apr 2009 13:25:28 +0200

Aki,

Aki Tuomi wrote:
> The path a->end isn't secure by definition, but I think it is in practice. 

Is it? :)

If a compromised computer is sitting in the same network as a stub
resolver, then it can easily send bogus spoofed DNS answers.

This may be outside the scope of dnsext and sit in the problem space of
securely getting network configuration information to a computer....

--
Shane

---

From: Tony Finch <[email-masked]>
Date: Tue, 21 Apr 2009 13:07:45 +0100

On Mon, 20 Apr 2009, Edward Lewis wrote:
>
> If the payload then requires (some sort of) unpredictability/randomness
> then there's all that state to maintain (per query), as well as having
> to generate the payload.

Can't you create an unpredictable payload using a hash of other
query-related data and a secret? I.e. no need for more randomness
and no extra state?

Tony.

---

From: bert hubert <[email-masked]>
Date: Tue, 21 Apr 2009 14:16:48 +0200

> (If it's not validating, it will process whatever it receives, of

I'm straying outside my field of expertise, but if I understand things
correctly, most high query load resolvers will not be in a position to
validate everything in realtime (think 20kqps query rates here). This
means that any non-validating resolver that wishes to provide robust
DNSSEC service had better come with good hop-by-hop protection.

Otherwise once the data does hit a validating server, it may well
prove bad, with little recourse except to wait for the bogus data to
time out from the non-validating resolver.

But it is possible that I miss a vital bit of how DNSSEC is supposed to operate.

I've trusted the output of 'openssl speed rsa' as an indication how
many records sets a validating server might verify per second (around
10000 per cpu).

       Bert

---

From: Tony Finch <[email-masked]>
Date: Tue, 21 Apr 2009 13:18:17 +0100

> There may be some text that gives recommendations on #2, but I'm not

TSIG?

Tony.

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 21 Apr 2009 05:19:43 -0700

> server). In that case, only end-to-end security protects you.

"oWn3ed by your ISP...".

The Recursive resolver is the one out-of-path adversary for data  
traffic that is in-path for DNS traffic.

And the only way to handle it is as follows:

Do the validation on the stub resolver.  ANY validation failures, no  
matter the cause, including lack of signatures altogether, should  
instead be fetched directly from the network by the stub resolver,  
bypassing the recursive resolver completely.

But then you have ISPs which block outgoing DNS packets that aren't  
going to their recursive resolvers!  After all, they want to be the  
ones to sell you the advertisements.

And, of course, this means that turning on DNSSEC properly for the end  
hosts will grossly (and I mean GROSSLY) increase the load on the DNS  
system for everyone who is not signing their data.  (Of course, you  
can call that a feature...)

---

From: Edward Lewis <[email-masked]>
Date: Tue, 21 Apr 2009 10:00:26 -0400

>query-related data and a secret? I.e. no need for more randomness

Probably (I am not an expert in [mathematical] "randomness.")  One of 
the things that needs to discussed if the document is adopted as a 
work item.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Florian Weimer <[email-masked]>
Date: Tue, 21 Apr 2009 16:07:52 +0200

> balancers. F5 is already aware of the issue.

Is this with BIND enabled on the box, or with BIND disabled?

---

From: Edward Lewis <[email-masked]>
Date: Tue, 21 Apr 2009 10:09:18 -0400

>DNSSEC service had better come with good hop-by-hop protection.

We should be able to get empirical evidence from ISPs in Sweden on this by now.

In theory, a validating server doesn't have to evaluate the entire 
chain each time new data is received - if the parent keys are already 
validated (in cache) there may be just one verification to do.  This 
thought might address the concern here but is no match for empirical 
data.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 21 Apr 2009 18:22:47 +0000

> With this reasoning, DNSSEC is doomed as well, because many middleboxes,
> firewalls, load balancers, etc, have problems with DNSSEC, too.

i'm not predicting doom.  i'm saying that "boots in lab" or even "deployed
it on my nameserver and nobody noticed" are not predictors of success.  to
really make something like EDNS-PING work we'd have to come up with OPT2 or
some super-EDNS signalling that did not have normal DNS as its fallback.

i am also *quite* concerned about the extra requests that will be received
by nonconforming servers.  i defined dns-0x20 this way, but i claimed it was
safe since almost all name servers happen to preserve the 0x20 bits today,
and the number of duplicated requests is expected to start out very low.  in
PING, that number is expected to start out very high, and may never approach
low.  we're talking about hundreds of millions of DNS endpoints, many of whom
are never upgraded, only replaced after long lives, or existing perpetually.

to the extent that additional hop-by-hop security is needed, dns-0x20 is a
better model for it than PING.  but i'm not convinced that more hop-by-hop
is needed, since the real problems in DNS security include on-path attacks,
and there will be a continuing real need for end-to-end no matter what we
do hop-by-hop.  (that's why i havn't pushed very hard on dns-0x20, btw.)

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 21 Apr 2009 11:55:31 -0700

> are never upgraded, only replaced after long lives, or existing  

But how many such endpoints are ALSO running at at least 33% of total  
maximum load?  Or return highly volatile results?

Thats the thing with extra requests which come from the recursive  
resolvers:  For non-volatile names, its a bounded 3x overhead, which  
is only a concern if the authority is running at significant load.

I think there is too much care given for "load on installed base that  
won't/can't upgrade".

---

From: bert hubert <[email-masked]>
Date: Tue, 21 Apr 2009 21:59:06 +0200

> it on my nameserver and nobody noticed" are not predictors of success.  to

So what is? Also - "deployed it on my nameserver and nobody noticed"
has a far different ring to it than "some of the largest nameservers
in operation already offer it". Or that millions of people have
happily been served by EDNS PING and that only a limited number of
problems have been reported, many of which are already in the process
of being addressed.

The beauty of EDNS PING is that it is so limited, and puts so little
demand on anybody.

> some super-EDNS signalling that did not have normal DNS as its fallback.

There are lots of other ways to prevent downgrade attacks than to
invent whole new protocols.

> by nonconforming servers.  i defined dns-0x20 this way, but i claimed it was

What extra requests? You might get one extra request per hour or so to
determine if your support for EDNS options has changed. Also, EDNS
PING only defines a tool which can be used to enhance forgery
resilience. The draft does not tell you to send three extra queries or
whatever.

EDNS has been out there for ages, as has your fine RFC describing it.
If people haven't learned to support it by now, they'll never will.
The EDNS RFC is quite clear that implementations must ignore unknown
EDNS options.

> better model for it than PING.  but i'm not convinced that more hop-by-hop

Sure you've been paying attention? dns-0x20 does nothing for .
queries, nor does it do very much for TLD queries..

     Bert

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Tue, 21 Apr 2009 18:52:50 -0700

Shane and all,

  Yes what you suggest is of course true and accurate.  I have noticed
and documented such activity from Afilias and Nuestar/Nuelevel on
too many occasions I care to elaborate on.  Spoofing valid keys for
DNSSEC is also not all that difficult to accomplish using this sort
of approach either, and should be expected and security folks need
to be prepared to deal with effectively, appropriately and immediately.
Some governments will be hi value targets for such occurrences...

  I suppose we all will find out early on how successful public service
groups within various governments and the private sector that are
third parties to such government organizations, their ability to deal
effectively, appropriately, and immediately with such eventual
breaches and/or compromises of private data.

Regards,

---

From: Danny Mayer <[email-masked]>
Date: Wed, 22 Apr 2009 17:17:50 -0400

> dnssec's costs (to date or as projected) on the basis of kaminsky alone.

Talking of DNSSEC-aware applications, how is this going to happen?
Currently all there is for an application is to use getaddrinfo() which
returns a result. The application cannot tell getaddrinfo() that it only
wants secure answers, getaddrinfo() cannot tell you whether the answer
was secure, how long it is valid (TTL) or any other information that
would allow to make a determination on the validity or value of the data
returned. Usually you get the list of DNS servers to use to do lookups
from DHCP and you have no way of telling DHCP that you want only
DNSSEC-aware servers. You cannot even tell whether or not those DNS
servers are DNSSEC-aware without some sample queries (assuming it
doesn't lie to you). This gets really bad when you travel or just go to
your nearest coffee shop with a wireless access point.

Let's say you want to check your bank balance at the Gigantic Bank of
Money using a browser like firefox or ie. You want a secure connection
so you want to use https and you want to make sure that the IP addresses
returned by DNS actually is the Bank's web site. So you want to require
DNSSEC to be used for the lookup but when you go off to request that web
page but you also want to ensure that any additional data included in
that page references DNSSEC-secured addresses required to load those
pages. Then of course you want to tell your browser which domains
*require* DNSSEC-secured address and there's no way to tell it that either.

We want DNSSEC-aware applications but we also need additional
infrastructure in place to do it.

Danny

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 28 Apr 2009 21:51:43 +0200

In your previous mail you wrote:

=> these problems are with EDNS, not DNSSEC, so unfortunately
are shared at least with EDNS-PING...

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Tue, 28 Apr 2009 21:59:43 +0200

=> it is channel (aka hop-by-hop) protection against off path attackers,
so I agree it doesn't provide something different than RFC 5452

   Now, we could discuss for years whether channel protection is better
   than data protection or vice-versa.

=> I disagree: the current DNS model is based on the use of recursive/
caching servers so either we change the model (*) or we adopt data
(aka end-to-end) protection.

Regards

PS: (*) caching/recursive servers are needed to solve transport issues,
with the future deployment of IPv6 it could be a very bad idea to ban
them by changing the DNS model.