Subject: [dnsext] Support for EDSN0 PING

From: "Bart Smit" <[email-masked]>
Date: Fri, 15 May 2009 12:16:57 +0200 (CEST)

Dear workgroup,

As a relative outsider, but with experience in DNS operations and
security, I've been following the discussions in this wg since around 2005
and I wonder why the renewed interest in forgery resilience work in the
wake of Kaminsky has subsided so fast. I really had expected that last
year's experience of having to rush out a solution would serve as a sort
of reality check to parties involved, but this effect is markedly absent.
In fact, I now even sense the opposite. A prominent wg member recently
suggested that all such (non-dnssec) work should be swept into the rubbish
bin. I find this incomprehensible and somewhat disturbing.

For this reason, although I hardly feel qualified (in wg context that is)
to do review, I would like to express my support for adopting
draft-hubert-ulevitch-edns-ping.txt as a working group document. And yes,
I'll gladly do review.

There is an interest in being able to use the ping option (it's already
being done), so there's a clear need to formalize the option code.
Moreover, suggested use of this option strongly works for meeting forgery
resilience demands, so I don't see why the document should not be adopted,
or why it should be worth all the heated debate. It describes an option,
support for which is entirely optional. This really ought to be
uncontroversial.

Bart Smit

Network Engineer at BKWI, The Netherlands
(on personal title)

--
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: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 15 May 2009 14:06:36 +0200

Hi Bart,

> bin. I find this incomprehensible and somewhat disturbing.

There is a fair number of submissions for forgery resilience, with
different trade offs.  The statement (IMHO) reflects an opinion on the
tradeoffs: deploying a cryptographic measure may be less work than
debating and deploying one after the other weak and temporary measure,
with cryptography (DNSSEC) providing much better data protection too.

> draft-hubert-ulevitch-edns-ping.txt as a working group document. And yes,

You note one of the proposals.  But this proposal is badly
underspecified, and as it currently stands, does not seem to really
work.  Is there a reason why you support this proposal?

> being done), so there's a clear need to formalize the option code.

EDNS is stripped off easily.  So the current EDNS PING implementation(s)
are likely unsafe.  How to protect the PING option is not easy or
obvious (for normal mortals).

This is the basis of the dialogue you quote, one is saying EDNS is
stripped easily, the other is saying it works - but without providing
details that could prove the case.

Based on the information I have so far, I think EDNS PING is not safe,
and therefore I agree with Paul.

> support for which is entirely optional. This really ought to be

Examination of forgery resilience proposals is fine with me, and if they
actually add security, I would gladly adopt and implement (if the costs
associated with it are not excessive or antisocial, of course).  I want
to point out that I was one of the first implementors of 0x20; a
proposal that protects only some queries, but is very light weight, and
which had already 99.99% support from authority servers.

However, I fail to see why you want a proposal that does not work?
If it does work, I would appreciate documentation.

Best regards,
   Wouter

---

From: "Griffiths, Chris" <[email-masked]>
Date: Fri, 15 May 2009 08:56:29 -0400

I have read through the EDNS0 ping draft and while it is an interesting
proposal, I do not see how this could be easily implemented and in most
cases it would probably be ignored and not have a large adoption rate.  I am
concentrating my time these days examining deployment and operational
scenarios for DNSSEC since this seems like the best long term approach for
DNS security.   I am open to other proposals that are light weight and make
sense and can be easily implemented and stand a chance for adoption in the
real world. 

I do not support this draft in its current form and agree with Wouter and
Paul on their comments, I think we should look at other proposal and would
be happy to review ones that come up.

---

From: niels=[email-masked]
Date: Fri, 15 May 2009 15:20:52 +0200

>obvious (for normal mortals).

Stephane Bortzmeyer wrote in 
http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg00551.html 
that resolvers can detect downgrade attacks.  With e.g. a fallback to 
TCP it becomes very hard to race such a resolver.

>details that could prove the case.

Bart Smit (whom you quoted) did not quote anybody or anything in his 
email.  What are you talking about?

	-- Niels.

---

From: Joe Abley <[email-masked]>
Date: Fri, 15 May 2009 16:29:50 +0300

> obvious (for normal mortals).

To avoid a spoofed UDP fallback form ENDS0, perhaps a client could  
encode its request with an EDNS0 ping payload, and ignore any apparent  
attempt to fall back to UDP without EDNS0 (or a reply without the  
additional matching EDNS0 ping bits present), falling back instead to  
TCP if necessary.

It might be necessary to "reject" rather than "ignore" above in order  
for transactions to complete promptly.

The attack on the client in this case would be to force the fallback  
to TCP, and cause the client to suffer from the increased transport- 
layer state.

If the above handwaving could be made to look like it was  
incrementally deployable, given the relatively small number of  
codebases involved on real-world recursive and authoritative servers,  
it's not obvious that this is undeployable. Quite possibly that's a  
big "if", though.

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 15 May 2009 09:54:12 -0400

Dear colleagues,

> Dear workgroup,

[&c.]

Given that some of the recent debate on the forgery resilience topic
has become somewhat heated, I want to hold up the first few messages
in the thread started by Bart Smit as an excellent example of how we
might come to some agreement on the topic.  In this thread, there are
people in apparently strong disagreement over what exactly the WG
ought to do.  But we are getting detailed arguments that specifically
address previous comments on the topic, and refreshingly few side
remarks about the individuals involved.  

Please keep it up!  If we can maintain this quality of respectful
debate, I predict that we will be able to come to a conclusion that
everyone can at least accept in a cold intellectual sense, even if
some of us come away unhappy that our preferred mechanisms were not
adopted.  I know it is sometimes painful to go over the same ground
again.  But remember, the point is not merely to win the debate, but
to expose to technical judgement every issue, flaw, and strength of
each proposal that we can.

Thanks!

A

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

---

From: "Bart Smit" <[email-masked]>
Date: Fri, 15 May 2009 16:21:00 +0200 (CEST)

> work.  Is there a reason why you support this proposal?

Given that the urgent desireability of adding sufficient entropy to
queries has been established, I see both 0x20 and ping as appropriate
measures. 0x20 is the quick but beautiful hack that piggybacks some bits
onto a query and happens to mostly work (but adds a suboptimal amount of
entropy), whereas -ping aims to fill the entropy gap by using a separate
field through an existing extension mechanism. Implementation
(server-side) seems easy enough. All complexity, however limited, resides
in the client.

I would support both ping and 0x20, but as you may sense from the above, I
see ping as more final. I expect that for both mechanisms, the client
strategies for detecting support and fallback are somewhat similar, and
would argue that they are largely up to the client. Possible strategies
and the reasons for leaving them out of the original draft have been
discussed recently. These discussions have convinced me that it is quite
doable to get this right. Even more important: failure to get the client
right mostly impacts the client itself. The incentives are placed just
right, so I don't see a too stringent need to specify this in detail.
Worries about huge amounts of re-querying traffic have not convinced me at
all.

> obvious (for normal mortals).

I'm not sure I understand you. We're talking forgery resilience. If your
adversary is in a position to strip off EDNS from existing packets, you
have much bigger worries than forgery. If you mean downgrade attacks, then
see above.

> which had already 99.99% support from authority servers.

Good. But then I still don't understand your reasons for not supporting
the draft. Is it that I misunderstood your point about EDNS being unsafe?

regards,

Bart

---

From: Paul Vixie <[email-masked]>
Date: Fri, 15 May 2009 14:38:22 +0000

> Date: Fri, 15 May 2009 12:16:57 +0200 (CEST)
> From: "Bart Smit" <[email-masked]>
> 
> security, I've been following the discussions in this wg since around
> 2005 and I wonder why the renewed interest in forgery resilience work in
> the wake of Kaminsky has subsided so fast. I really had expected that
> last year's experience of having to rush out a solution would serve as a
> sort of reality check to parties involved, but this effect is markedly
> absent.  In fact, I now even sense the opposite. A prominent wg member
> recently suggested that all such (non-dnssec) work should be swept into
> the rubbish bin. I find this incomprehensible and somewhat disturbing.

since i mentioned a rubbish bin recently but the above is not a fair summary
let me say that TKEY-DH plus TSIG is an existing (already specified but not
widely implemented) method of holding session state between pairwise UDP/53
speakers that would absolutely and totally protect hop by hop communications
between cooperating initiator/responder pairs.

the stuff that i directed toward the rubbish bin was every other current
proposal, including my own (dns-0x20).

> draft-hubert-ulevitch-edns-ping.txt as a working group document. And yes,

PING is a layering violation for EDNS and does not add any real security.
(as the author of EDNS [RFC2671] i already tried to add an extended QID and
found that it could not be done; nothing as changed since RFC2671 came out.)

> support for which is entirely optional. This really ought to be

it's controversial because it only works when it works, and when it fails,
there's no distinction between an attack and a failure.  we were not idiots
back in the old days when EDNS was being crafted.  we knew we needed a
larger QID.  we tried hard to include it.  there's no way to do it and
still properly negotiate EDNS.

secure protocol engineering is apparently not as easy as it looks.

> Network Engineer at BKWI, The Netherlands

paul vixie
author, RFC 2671, http://www.ietf.org/rfc/rfc2671.txt
co-author, DNS-0x20, http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00

---

From: Paul Vixie <[email-masked]>
Date: Fri, 15 May 2009 14:58:23 +0000

> Date: Fri, 15 May 2009 15:20:52 +0200
> From: niels=[email-masked]
> 
> that resolvers can detect downgrade attacks.  With e.g. a fallback to TCP
> it becomes very hard to race such a resolver.

in http://www.ietf.org/rfc/rfc1035.txt we see the following text:

+---
| 4.2.2. TCP usage
| 
| Messages sent over TCP connections use server port 53 (decimal).  The
| message is prefixed with a two byte length field which gives the message
| length, excluding the two byte length field.  This length field allows
| the low-level processing to assemble a complete message before beginning
| to parse it.
| 
| Several connection management policies are recommended:
| 
|    - The server should not block other activities waiting for TCP
|      data.
| 
|    - The server should support multiple connections.
| 
|    - The server should assume that the client will initiate
|      connection closing, and should delay closing its end of the
|      connection until all outstanding client requests have been
|      satisfied.
| 
|    - If the server needs to close a dormant connection to reclaim
|      resources, it should wait until the connection has been idle
|      for a period on the order of two minutes.  In particular, the
|      server should allow the SOA and AXFR request sequence (which
|      begins a refresh operation) to be made on a single connection.
|      Since the server would be unable to answer queries anyway, a
|      unilateral close or reset may be used instead of a graceful
|      close.
+---

this is utterly damning of any proposal involving "use TCP to aid security",
whether in fallback, primary use, parallel use.  a close reading of 4.2.2 and
some experience implementing and operating name servers makes it obvious that
TCP only works when nobody benefits from breaking it.  the DDoS vector opened
by the above text can be implemented in a one line perl script.

TCP is usable for AXFR/IXFR, but for QUERY, it's a simple recipe for disaster.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 15 May 2009 17:27:15 +0200

Hi Bert,

bert hubert wrote:
> Weird - a wise man read my thoughts on how EDNS PING could work..
> http://article.gmane.org/gmane.ietf.dnsext/13806
> But it appears you've changed your mind?

No, I still believe EDNS PING to be very, very much in danger of
downgrade.  But, I was happy, in the above reference, that we were
moving into more secure territory.  Of course, securing one part is I
think a good step, but opponents always choose the weakest part...

> How is it easy? - as outlined in the URL mentioned above, and as
> implemented, it is very hard to downgrade a 'known pinger'.

Actually no, because if the negative reply does not have the long random
number then the downgrade is very easy in fact. And there may be more
cases.  The only sane way to deal with that is to enumerate all of the
trouble spots and deal with them.  Sort of what my forgery resilience
draft attempts for Kaminsky-attack packets.

(if you can protect the probe really well, then maybe we could use the
same method for all queries? ... just a silly idea)

> This is bordering on the ridiculous - we discussed previously what the
> goals of EDNS-PING were, and we had a decent discussion on how to
> achieve those goals. And now 'it does not work'.

I think the message is a good step forwards.  Maybe we can continue that
line of investigation.  There are many questions left unanswered, and
the draft needs much more text.  We need to know the full resolver
algorithm that is proposed for EDNS PING.  Then this needs to be
documented (at some level of abstraction).

Best regards,
   Wouter

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Fri, 15 May 2009 17:58:29 -0700

Andrew and all,

  Thank you Andrew, I could not agree more.  Whatever the
results of such a debate are or perceived to be, my organizations
effective and time proven methods will not likely change much if at all.
Whatever methods or approaches are largely decided upon if proven
to be effective or even if only perceived to be only somewhat effective,
any effort to thwart REAL pirating or forgery is at least a step or several

steps in the right direction.  Certainly the IP lobbyists, poly-wonkers and

well meaning politicians need all the REAL technical help and follow-on
education they can get!
That said, and I hope properly understood, lets get busy!

> each proposal that we can.

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: Florian Weimer <[email-masked]>
Date: Sun, 31 May 2009 10:44:33 +0200

> still properly negotiate EDNS.

But this is not the fault of any extended query ID proposal, it's the
fault of EDNS.

DNSCurve shows a fully backwards-compatible way to signal protocol
version information to recursive resolvers.

I mean, let's look at what elements of EDNS0 actually work:

  * extended RCODEs (but I'm not sure about that)

  * extended query flags (the DO bit seems pretty interoperable, even
    though it's overused, but this is not EDNS0's fault)

What does not work:

  * the official fallback algorithm (section 5.3)

  * large responses (interoperability problems, DoS amplification)

  * extended label types (already officially dead)

  * options (a FORMERR/SERVFAIL does not tell you which option caused
    the error, making fallback impossible; there is also a significant
    non-interoperating server base)

I wonder if there should be an actually working EDNS0 replacement
which could then be used to implement extended query IDs.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 31 May 2009 16:03:29 +0000

> From: Florian Weimer <[email-masked]>
> Date: Sun, 31 May 2009 10:44:33 +0200
> 
> * Paul Vixie:
> 
> > it's controversial because it only works when it works, and when it
> > fails, there's no distinction between an attack and a failure.  we were
> > not idiots back in the old days when EDNS was being crafted.  we knew
> > we needed a larger QID.  we tried hard to include it.  there's no way
> > to do it and still properly negotiate EDNS.
> 

right.

> which could then be used to implement extended query IDs.

you forgot "fragmentation is bad".  (dnscurve avoids this with small crypto.)

TCP/53 is unusable for queries for a variety of reasons of its own.

that's why i'm pounding the table for SCTP/53, on which EDNS wouldn't be
optional, therefore avoiding the fallback problems.  EDNS PING isn't needed
in SCTP due to SCTP's own transport protection, but if needed it would work,
since EDNS would not be optional (no fallback problem.)

---

From: Matthew Dempsky <[email-masked]>
Date: Sun, 31 May 2009 10:38:22 -0700

On Sun, May 31, 2009 at 9:03 AM, Paul Vixie <[email-masked]> wrote:
> optional, therefore avoiding the fallback problems.

During the transition to SCTP/53, how do you avoid the fallback
problem?  Do servers pre-announce SCTP support somehow?  If so,
couldn't you use the same means to announce EDNS support for UDP/53?
If not, couldn't an attacker force a cache to fallback to UDP/53
without EDNS?

---

From: Paul Vixie <[email-masked]>
Date: Sun, 31 May 2009 17:58:38 +0000

> Date: Sun, 31 May 2009 10:38:22 -0700
> From: Matthew Dempsky <[email-masked]>
> 
> During the transition to SCTP/53, how do you avoid the fallback problem?
> Do servers pre-announce SCTP support somehow?  If so, couldn't you use
> the same means to announce EDNS support for UDP/53?  If not, couldn't an
> attacker force a cache to fallback to UDP/53 without EDNS?

i was not considering any kind of advertisement.  years ago we talked about
an "ENS" record that would include some nameserver attributes, but it's not
a good idea for the reasons you provided.

EDNS is subject to trivial downgrade attacks.  SCTP is not.  viva la
difference!

---

From: Matthew Dempsky <[email-masked]>
Date: Sun, 31 May 2009 11:08:34 -0700

> EDNS is subject to trivial downgrade attacks.  SCTP is not.  viva la

I'm not talking about downgrading from SCTP-with-EDNS to
SCTP-without-EDNS.  I'm talking about downgrading from SCTP-with-EDNS
to UDP-without-EDNS.

An attacker can flood a name server with traffic so it cannot handle
DNS queries over SCTP or UDP.  It can then try to send forged
UDP-without-EDNS responses.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 31 May 2009 18:19:34 +0000

> Date: Sun, 31 May 2009 11:08:34 -0700
> SCTP-without-EDNS.  I'm talking about downgrading from SCTP-with-EDNS to
> UDP-without-EDNS.

yes.

> UDP-without-EDNS responses.

i think you should study SCTP harder to find out if it's anywhere near
as fragile as EDNS/UDP/53 or TCP/53 when it comes to forcing a failure
in order to force a downgrade.  my own evaluation says: nowhere near.

---

From: Matthew Dempsky <[email-masked]>
Date: Sun, 31 May 2009 11:26:16 -0700

> in order to force a downgrade.  my own evaluation says: nowhere near.

SCTP can guarantee success even when the server's bandwidth is
saturated by a DoS attack?

---

From: Paul Vixie <[email-masked]>
Date: Sun, 31 May 2009 18:27:25 +0000

> Date: Sun, 31 May 2009 11:26:16 -0700

of course not.  nothing can.  but it doesn't take anywhere near that much
bandwidth to force failures on EDNS/UDP/53 or TCP/53.