Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ?

From: Peter Koch <[email-masked]>
Date: Tue, 12 May 2009 15:12:51 +0200

On Wed, Apr 22, 2009 at 11:07:09AM -0400, Ólafur Guðmundsson /DNSEXT chair wrote:
> The WG has received a request to adopt this as a work item.
> See draft:
> http://www.ietf.org/internet-drafts/draft-hubert-ulevitch-edns-ping-01.txt
> 
> The current document falls under the "further Forgery Resilience" clause in
> our charter.
> 
> If we are going to debate the merits of this proposal, the chairs think
> it is going to beneficial to all that we have a common understanding of
> what the  proposal is about and its implications.

agreed.  However, the draft asking for adoption does not enable the wg to make an
informed decision because it is essentially free of any content.  All important
parts (judging from subsequent mailing list discussions) have been "intentionally
left blank", where the only issue that should have been left open, is actually
jumping ahead: the code point assignment.  For this lack of base of discussion,
I object to the adoption of this document as a working group item.

In addition to many of the points Wouter has raised, I'd like to share my
observation that I feel there is a recent trend that could be read as an end run
to process by submitting as little information as theoretically possible for
a code point assignment and leaving everything else to implementors.
This worries me a lot, because the DNS is not only about packets going back and
forth on Port 53, but also a large deployed infrastructure that deserves some
extra thought.  These operational considerations need to be an integral part
of the specification as well as good guidance for the resolver implementor to
avoid undesired changes to the swarm behaviour of today's resolver population.

> Q1: Is ENDS0 Ping more expensive [1] than other EDNS0 options ?

"Ping" is a misnomer since what seems to be tried here is the extension of the QID
range.

-Peter

--
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: Paul Vixie <[email-masked]>
Date: Tue, 12 May 2009 15:13:18 +0000

> Date: Tue, 12 May 2009 15:12:51 +0200
> From: Peter Koch <[email-masked]>
> ...
> ... I object to the adoption of this document as a working group item.

me too.

> observation that I feel there is a recent trend that could be read as an
> end run to process by submitting as little information as theoretically
> possible for a code point assignment and leaving everything else to
> implementors.  This worries me a lot, because the DNS is not only about
> packets going back and forth on Port 53, but also a large deployed
> infrastructure that deserves some extra thought.  These operational
> considerations need to be an integral part of the specification as well
> as good guidance for the resolver implementor to avoid undesired changes
> to the swarm behaviour of today's resolver population.

this is what we (ISC) did for DLV.  we defined the RDATA because we didn't
want to use a private type code, but we did not define the method of use,
because i knew pretty well in advance that the DLV model wasn't going to be
adopted by the WG.  so i'm sympathetic to bert's position, even though i
think PING is a bad idea for reasons i've stated several times.  this WG
seems to be a gatekeeper to prevent many things from getting into the DNS.
someone who wants to give something a try is somewhat discouraged both at
the outset and throughout.  i think a heavier use of, and encouragement of,
experimental track RFC's with an expectation that they may be upgraded to
proposed standard later, would stop the "end runs" from happening around
here.  (SRV started on the experimental track if i recall correctly.)

formal standards status no longer has any bearing on whether the whole
internet ends up using some new protocol feature.  RFC's are often written
well after the fact.  bert for example has said that he already has a small
installed base for PING, and i know there's a small installed base for 0x20,
and i know there's a moderate sized and growing installed base for DLV.  do
we want this WG to be in the position of preventing standards status for
things that the crowd doesn't like, thus making the WG irrelevant?  or would
we rather be in the business of helping get new technologies developed and
deployed?  if the latter, then we're going to need an attitude adjustment.

(note that my reasons for opposing PING are technical, not administrative;
i'm against it because it has necessarily undefinable elements -- that is,
because it is not correct and cannot be made correct by incremental protocol
work or standards action -- and not because the internet draft doesn't say
enough about how PING is to be used.)

---

From: "George Barwood" <[email-masked]>
Date: Tue, 12 May 2009 19:29:46 +0100

I don't see PING as incorrect. 

It may be more honest to call it "Extended Query Id".

The situation is this:

                                          In-Path  Attack               Out-of-path Attack
Plain DNS 16-bit ID         Trivial                            Easy                         
Plain DNS 32-bit ID         Trivial                            Hard
Plain DNS 128-bit ID       Trivial                            Very Hard

DNSSEC 16-bit ID           DOS Trivial                  DOS Easy
DNSSEC 32-bit ID           DOS Trivial                  DOS Hard
DNSSEC 128-bit ID         DOS Trivial                  DOS Very Hard

Without some kind of Query Id, DNSSEC has no protection against Out-of-path DOS attacks, and would be useless.

An Extended Query ID gives full protection, and in a cleaner, stronger, and more reliable way than source port randomization. It fixes the original cryptographic weakness in the protocol, namely that the Query Id is not long enough.

This strengthens both Plain DNS and DNSSEC, and in the long term allows both protocols to be implemented in a straight-forward manner, especially for recursors situated behind NAT devices.

George Barwood

----- Original Message ----- 
From: "Paul Vixie" <[email-masked]>
To: "IETF DNSEXT WG" <[email-masked]>
Sent: Tuesday, May 12, 2009 4:13 PM
Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? 

>hº{.nÇ+‰·¬zwZ™ë,j¢v¦yÚè¦—«²·ª¹ë-¢›"z×è®"¶a{
+véì¹»®&ÞŠv¬Šx%zX§y«-…éž²Æ z×±µºÉªÜ†+Þ†Ûiÿú)²'~ŠàþX¬¶Ïçjg®Šiz»?

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 May 2009 14:34:33 -0400

On Tue, May 12, 2009 at 03:13:18PM +0000, Paul Vixie wrote:

>  this WG seems to be a gatekeeper to prevent many things from
> getting into the DNS.

My reading of our charter is that this is exactly what we're supposed
to be doing:

> The WG will limit itself to review of proposals for new extensions,
> clarification to the DNS protocol, including DNSSEC, and review of
> DNS protocol related work which may originate elsewhere in the IETF,
> including AD-sponsored submissions or drafts in other working
> groups.

In other words, we're supposed to get new proposals _from elsewhere_,
and then review them (which practically means "poke holes in").  This
is an assumption on which I've been operating as a co-chair.  I'm
aware that this reading is not exactly welcoming or encouraging to
people who want to put new things in the DNS.  If we think that's a
problem, we either need to change the WG charter or I have to revise
my interpretation.  I think my understanding is supported by that
text, however, and it's sure consistent with what I remember from the
Prague meeting where we put the WG "to sleep". 

A

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

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 12 May 2009 12:05:18 -0700

On May 12, 2009, at 11:29 AM, George Barwood wrote:

> Without some kind of Query Id, DNSSEC has no protection against Out- 
> of-path DOS attacks, and would be useless.
>
> An Extended Query ID gives full protection, and in a cleaner,  
> stronger, and more reliable way than source port randomization. It  
> fixes the original cryptographic weakness in the protocol, namely  
> that the Query Id is not long enough.
>
> This strengthens both Plain DNS and DNSSEC, and in the long term  
> allows both protocols to be implemented in a straight-forward  
> manner, especially for recursors situated behind NAT devices.

I disagree.  If out-of-path DOS becomes significant on DNSSEC,  
requerying mechanisms can be used.  And requerying mechanisms are  
probably advisable anyway, if only to act as implicit notification to  
the authorities that something is wrong with their DNSSEC deployment.

And 2^30 packets to DOS a name, even without requerying is, bah, a  
waste of packets.  There are far, FAR better things to do.

---

From: "George Barwood" <[email-masked]>
Date: Tue, 12 May 2009 22:42:04 +0100

I don't dispute that by writing sufficiently complex resolver-side software, it's possible to work around the deficiencies of the 16-bit ID.

However such complexity has it's own risks, and it goes against good engineering practice to continue indefinitely with a flawed design if a simple remedy is available.

My point was that an extended ID should not be seen as "incorrect".

Besides, we are talking about 2^15 packets in the case I referred to, which is a non-DNSSEC aware cache behind a NAT firewall, serving a DNSSEC-validating resolver, so there are practical issues as well.

Requerying is quite complex, you basically have to stop using the cache completely, because you cannot know at what point the delegation has been hijacked. That means that writing a DNSSEC-validating resolver becomes significantly more complex, and the requerying behavior could become the basis for other attacks.

That may be the world we are forced to endure for the moment, but surely it's best to plan for a better future.

----- Original Message ----- 
From: "Nicholas Weaver" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "Nicholas Weaver" <[email-masked]>; "Paul Vixie" <[email-masked]>; "IETF DNSEXT WG" <[email-masked]>
Sent: Tuesday, May 12, 2009 8:05 PM
Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? 

>¶‹§²æìr¸›zÇ§u©ž²Æ zÚ'jg®Šiz»+z«ž²Ú)²'~ŠàÂ+a¶°¢·nžË›±Êâmè§jÈ§‚W¥Šwš²Ø^™ë,j{[¡ÜšÈb½èm¶Ÿÿ¢›"z×è®åŠËlþv¦yÚè¦—«³

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 May 2009 21:45:56 +0000

> From: "George Barwood" <[email-masked]>
> Date: Tue, 12 May 2009 22:42:04 +0100
> 

it is, because of the nature of EDNS0 itself, which cannot be used this way.
i'm sure that a lot of wish that EDNS0 could be used this way, but wishing
won't make it so, nor will repeated assertions to the contrary, nor faith,
nor hope, nor charity.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 13 May 2009 09:25:30 +0200

On Tue, May 12, 2009 at 03:12:51PM +0200,
 Peter Koch <[email-masked]> wrote 
 a message of 40 lines which said:

> In addition to many of the points Wouter has raised, I'd like to
> share my observation that I feel there is a recent trend that could
> be read as an end run to process by submitting as little information
> as theoretically possible for a code point assignment and leaving
> everything else to implementors.

Hold on, there is a strong need here for a message by the chairs of
the WG. Because another proposal for an extended Query ID space, DNS
cookies, draft-eastlake-dnsext-cookies, was put down for precisely the
opposite reason, because it was too detailed on practical use and
operational issues. Unlike cookies, the EDNS0-ping proposal,
draft-hubert-ulevitch-edns-ping, ON PURPOSE, tried to stay away from
these issues (see also Paul Vixie's excellent comparison with DLV).

So, we need a clear guidance to the people who try to bring new work
to this WG: are they welcome to provide "as little information as
theoretically possible" or should they go in great details about the
USE of the new technique? In the last case, I ask for the adoption of
draft-eastlake-dnsext-cookies by this WG as a work item.

---

From: bert hubert <[email-masked]>
Date: Wed, 13 May 2009 09:28:39 +0200

> won't make it so, nor will repeated assertions to the contrary, nor faith,

Saying that it ain't so also does not make it not so.

Please clarify why it does not help. As stated before, repeatedly,
significant percentages of queries can already benefit from EDNS ping.
The goal is not 'complete and total security for everyone', but a
significant boost for every server that participates.

      Bert

---

From: bert hubert <[email-masked]>
Date: Wed, 13 May 2009 09:57:39 +0200

> draft-eastlake-dnsext-cookies by this WG as a work item.

If one major DNS vendor ('ISC' for example) were to commit to
implementing Donald's cookies, and if with another (PowerDNS, say) we
can work out the kinks while it is in the draft stage, it would be
superior to anything currently on the table.

My main objection to draft-eastlake-dnsext-cookies is that it is
eminently 'sinkable' by going into detail.

So this is more of an objection to the current WG climate than to the content.

But by themselves, the dns cookies are in my view almost optimal for
DNS security in the coming few years.

EDNS-PING was written simply because I think it is the optimum between
raising DNS security AND standing a chance to be adopted.

    Bert

---

From: Paul Vixie <[email-masked]>
Date: Wed, 13 May 2009 13:51:03 +0000

> From: bert hubert <[email-masked]>
> Date: Wed, 13 May 2009 09:28:39 +0200
> 

i've explained the reasons.  shall i keep repeating those even though
neither you nor george barwood has shown any interest in the details?

> significant boost for every server that participates.

my objection is to the impedence mismatch between extended QID and EDNS,
which precludes usefulness.  i wanted extended QID inside EDNS itself --
my original planned use for the OPT TTL was to make it the high order
bits of a 48-bit QID.  it won't work, for reasons you and george barwood
have been told repeatedly.  extended QID in EDNS is a layering violation.

"works in lab" is a very different thing than "works in whole internet".

---

From: Paul Vixie <[email-masked]>
Date: Wed, 13 May 2009 14:10:05 +0000

> Date: Wed, 13 May 2009 09:57:39 +0200
> 
> implementing Donald's cookies, and if with another (PowerDNS, say) we can
> work out the kinks while it is in the draft stage, it would be superior
> to anything currently on the table.

we already have a protocol (also writ by donald eastlake) that can do this,
if we're willing to keep state between recursives and authorities: RFC 2930
(TKEY) section 4.1 (Query for Diffie-Hellman Exchanged Keying), followed by
TSIG.  RFC 2930 seems to prohibit this use profile in section 3 which reads:

   Except for GSS-API mode, TKEY responses MUST always have DNS
   transaction authentication to protect the integrity of any keying
   data, error codes, etc.  This authentication MUST use a previously
   established secret (TSIG) or public (SIG(0) [RFC 2931]) key and MUST
   NOT use any key that the response to be verified is itself providing.

   TKEY queries MUST be authenticated for all modes except GSS-API and,
   under some circumstances, server assignment mode.  In particular, if
   the query for a server assigned key is for a key to assert some
   privilege, such as update authority, then the query must be
   authenticated to avoid spoofing.  [However, if the key is just to be
   used for transaction security, then spoofing will lead at worst to
   denial of service.]  Query authentication SHOULD use an established
   secret (TSIG) key authenticator if available.  Otherwise, it must use
   a public (SIG(0)) key signature.  It MUST NOT use any key that the
   query is itself providing.

i have highlighted the statement which i think governs our situation:

                                      However, if the key is just to be
   used for transaction security, then spoofing will lead at worst to
   denial of service.

i am comfortable with a DoS vector in TKEY-DH since these will be rare
and they are not repeatably/remotely triggerable (so, there's no race
until win a la kaminsky.)

and most important compared to any extended QID proposal is that the
downgrade impedence matches EDNS's downgrade impedence.  if TKEY-DH
fails, which can be because EDNS fails, then this recursive<->authority
relationship simply won't be secured by TKEY-DH and TSIG.

in terms of WG action a short two-page use profile explaining how to use
TKEY-DH and TSIG to achieve greated hop-by-hop security is all we'd need.
(this document could also explicitly relax the spoofing concerns quoted
above from RFC 2930 when TKEY-DH is to be used only for QUERY TSIG.)

this is the least controversial and most workable proposal on the table,
and i request that the WG chairs please sweep all other alternatives
including the dagon/vixie dns-0x20 one into the rubbish bin so that we
can get focused.

and note that for secure delegations to unsecure zones, RFC 2931 applies.

---

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Wed, 13 May 2009 11:14:34 -0400

>draft-eastlake-dnsext-cookies by this WG as a work item.

We (Chairs) never formally asked the WG if the cookies document 
should be adopted.
The feeling the chairs got from the DNSEXT meetings and mailing list was that
number of people did not like the fact the proposal required a state on
servers and the draft did not address how to share state on anycast clusters.

ENDS0 Ping avoids the state on servers thus it works "better" with 
anycast clusters,
with weaker security association.
Bert will the first to report that I have hammered him hard, in private,
for the "loose writing style" of the draft.
The draft as it stands now expresses an idea with details to be worked out.

The WG can decide to accept an rough idea for a document, but make
it conditional on certain changes before gaining WG status.
Once a document becomes a WG document the editors serve at the pleasure
of the chairs, who monitor that the document reflects suggestions and 
consensus.

Below is our standard blurb to prospective editors for DNSEXT documents:
----------
Editors send preview copy of new drafts to chair(s),
chair(s) either send pre approval message to drafts-administrator or
editorial comments to editor.
Editors are responsible for keeping track of discussions and changes 
suggested/requested.
Editors serve at the pleasure of the chair and can be removed for non 
performance
or counter-productive behavior.
Chair(s) serve as final arbitrators of WG consensus.
-----------

         Olafur

---

From: bert hubert <[email-masked]>
Date: Thu, 14 May 2009 09:51:58 +0200

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

> neither you nor george barwood has shown any interest in the details?

You may have explained why it is not perfection. You have not
explained why it would not help in practice, which it does.

> have been told repeatedly.  extended QID in EDNS is a layering violation.

Furious handwaving..

> "works in lab" is a very different thing than "works in whole internet".

Have you lost the ability to *read*? Silly statements like "the
internet is far bigger than you imagine" are not convincing, even if
they do come from Paul Vixie, president ISC.

The fact of the matter is that the number of servers out there
supporting EDNS-PING is already non-trivial, and a few percent of ALL
domain names already respond to EDNS-PING. I'm not sure how that
qualifies as 'works in the lab'.

   Bert

---

From: niels=[email-masked] (Niels Bakker)
Date: Fri, 15 May 2009 01:10:53 +0200

* [email-masked] (Paul Vixie) [Wed 13 May 2009, 16:20 CEST]:
[quoting bert hubert <[email-masked]>:]
>neither you nor george barwood has shown any interest in the details?

Can you give me a pointer in the archives instead?  Possibly you are 
referring to the string of single liners you sent on April 20th?  Or the 
next day, when you said implementing EDNS-PING would only distract people 
from implementing DNSSEC?

[..]
>"works in lab" is a very different thing than "works in whole internet".

QFT

	-- Niels.

--