Subject: Fwd: New Version Notification for draft-reid-dnsext-aleatoric-00

From: Jim Reid <[email-masked]>
Date: Wed, 6 Aug 2008 17:13:00 +0100

This idea is probably even uglier than the 0x20 draft. :-)

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: August 6, 2008 15:46:00 BST
> To: [email-masked]
> Subject: New Version Notification for draft-reid-dnsext-aleatoric-00
>
>
> A new version of I-D, draft-reid-dnsext-aleatoric-00.txt has been  
> successfuly submitted by Jim Reid and posted to the IETF repository.
>
> Filename:	 draft-reid-dnsext-aleatoric
> Revision:	 00
> Title:		 A DNS Resource Record for Additional Entropy
> Creation_date:	 2008-08-06
> WG ID:		 Independent Submission
> Number_of_pages: 14
>
> Abstract:
> A scheme to defend against cache poisoning attacks against the Domain
> Name System (DNS) by predicting the ID and source port number of
> outgoing queries is described in this draft.  It proposes a new
> resource record to provide a mechanism to introduce additional
> entropy into DNS queries.
>
>
>
> The IETF Secretariat.
>
>

--
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: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 28 Aug 2008 17:27:51 +0200

On Wed, Aug 06, 2008 at 05:13:00PM +0100,
 Jim Reid <[email-masked]> wrote 

> This idea is probably even uglier than the 0x20 draft. :-)

I like it although I'm not sure it is better than cookies: after all,
a name server software has to be changed in one way or the other. If
we are going to add AL support, why not directly adding cookies? AL
seems interesting only if EDNS support is unrealistic (too complicated
for the name server software or blocked by a stupid firewall). Is it a
sufficient motivation?

Also, you do not address downgrade attacks, apparently? How to know if
a response without AL comes from an old server, not upgraded, or from
an attacker?

---

From: Jim Reid <[email-masked]>
Date: Thu, 28 Aug 2008 16:54:39 +0100

On 28 Aug 2008, at 16:27, Stephane Bortzmeyer wrote:

> AL seems interesting only if EDNS support is unrealistic (too  
> complicated

AL works (for some definition of work) regardless of EDNS support. So  
I suppose that is some sort of motiovation. Whether it's sufficient  
motivation is up to this WG to decide.

> a response without AL comes from an old server, not upgraded, or from

It doesn't handle downgrade attacks. So AL in its current incantation  
is flawed. OTOH, it does raise the barrier for cache poisoners.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 28 Aug 2008 09:51:16 -0700

The problem I have with this proposal, and any proposal that requires  
both resolver and authority changes is as follows:

DNSSEC's major deployment problem is that it requires double-sided  
deployment: changes to both the resolver and authority to have an  
effect, thus in the case of partial deployment, only the intersection  
of changed-resolvers & changed-authorities sees a benefit.

Thus if a proposed mitigation for blind injection requires double- 
sided changes, why not just do DNSSEC, especially if you make it easy  
to DO DNSSEC?  Perhaps, by following the lead of some of SSH's  
usability hacks, just make it easy to do in a manner which is insecure  
to authority compromise.

This contrasts greatly with other methods of increasing entropy of  
cached entries: Port, address, and 0x20 randomization take advantage  
of how existing authorities work, so it requires only changes to the  
resolver.

Likewise, "duplicate and cache-on-agreement" will result in entropy  
increases to arbitrary values and the only cases where you fail to  
cache are ones where you get multiple return values for the same  
query, and as others have pointed out on the list, you could recurse  
until you get a converged entry appearing in multiple responses, so  
again, its a way of increasing entropy (to arbitrary limits, too!)  
that does not

The minor problem I have is there seems to be a discomfort with  
entropy: if you can get the query entropy to be over 40b for the  
purposes of caching, you can make blind attacks on the cache  
completely infeasible with just a single counter of bad responses: 10M  
packets to have a .001% chance of poisoning a single entry, and if you  
wipe the cache at that point, well, 10M packets to cause the cache to  
void 1M entries?  Hardly seems a DOS to me.

Especially if combined with cache policies on the resolver which  
eliminate all "Race until win" conditions.

And also "void on changed double-response" detection if you are  
willing to manage the outstanding state.

After all, blind attacks on TCP can be done as well:  Observe that  
these days, most systems don't actually respond to unsolicited packets  
with RSTs, so if the legit packets are received by the destination but  
the destination doesn't see the sequencing right, they will be  
ignored.  And even if not, if the attacker is closer than the legit  
destination, the legit RSTs will never be received.

Guess the sender's source port (predictible) and sequence number and  
respond with an appropriate SYN/ACK.  Then guess that they will do the  
DNS request, and send the response with the next in sequence + a FIN.

Thus instead of blindly sending individual packets with a random ID,  
you're sending a blind string of 3 packets (SYN/ACK, data, FIN) where  
you use random SEQ # and random TXID, with a tiny gap between the SYN/ 
ACK and the data to give the host time to process.

This is 16b entropy for the transaction ID, but 32b of entropy for  
initial sequence #, making it a 48b of entropy problem.  TCP, the  
"Ultimate fallback" is really just an easy way of adding 32b of  
entropy to a query: getting the query entropy to 48b.

Why isn't this done to attack other protocols?  Because attackers have  
better things to do than bang against the network on a 48b entropy  
problem.

---

From: Jim Reid <[email-masked]>
Date: Thu, 28 Aug 2008 18:19:04 +0100

On 28 Aug 2008, at 17:51, Nicholas Weaver wrote:

> sided changes, why not just do DNSSEC, especially if you make it  
> easy to DO DNSSEC?

This is like saying let's solve world hunger by just giving everyone  
enough food: naive and not particularly helpful.

Deployment of DNSSEC is going to take a Long, Long Time, even with  
much improved tools. So what does the world do until then?

Ugly kludges like AL or 0x20 are relatively painless to deploy, so  
they can buy some breathing space until the root's signed, everyone's  
got DNSSEC-aware resolvers and there are plenty of decent tools to  
sign zones, manage keys and debug validation failures. In this  
context, "deploy" means nothing more than update your DNS software.  
Even when this isn't straightforward, it's still far easier than all  
the goop that has to go alongside updating DNS software to accommodate  
DNSSEC deployment: eg configure and maintain trust anchors, generate  
keys, change zone management tools/processes to incorporate signing,  
handle key rollover, etc, etc. It would be wonderful if these things  
could be reduced to close-to-zero effort.  But DNSSEC isn't like that.  
Sigh.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 28 Aug 2008 21:16:59 +0000

> Ugly kludges like AL or 0x20 are relatively painless to deploy, ...

don't mention these together, please.  0x20 is a one-side upgrade (RDNS only).

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 29 Aug 2008 09:42:09 +0200

On Thu, Aug 28, 2008 at 09:16:59PM +0000,
 Paul Vixie <[email-masked]> wrote 
 a message of 8 lines which said:

> 0x20 is a one-side upgrade (RDNS only).

Only if the aDNS preserves case which is currently NOT mandatory.

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 29 Aug 2008 05:13:55 -0700

> Only if the aDNS preserves case which is currently NOT mandatory.

This is why 0x20, IIRC, has "Duplicate on failure".

the aDNS in practice almost always preserves case, and duplication  
gives you a fallback position when you have insufficient entropy.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 29 Aug 2008 15:50:59 +0000

> Only if the aDNS preserves case which is currently NOT mandatory.

since the draft allows for this situation and explains what to do about it,
and since i've implemented it and have run it successfully for six months,
and since unbound has implemented it and noone has reported trouble there,
i think it's safe to categorize this as "RDNS only".  i know there is text
in the draft asking that the standard for ADNS be changed to optimize for
dns-0x20, but the current proposal is to add "SHOULD preserve qname case"
not "MUST preserve qname case."

contrast this with PING, XQID, AL, or things which don't work at all until
changes are made to the ADNS side.

so, i'd like dns-0x20 and AL not to be mentioned in the same breath, please.

---

From: Florian Weimer <[email-masked]>
Date: Fri, 29 Aug 2008 18:45:09 +0200

> and since i've implemented it and have run it successfully for six months,

Your setup is probably not representative (is it mail only?) because
it failed to detect initial breakage which other parties have observed
subsequently.

> and since unbound has implemented it and noone has reported trouble there,

<https://lists.dns-oarc.net/pipermail/dns-operations/2008-August/003183.html>

> i think it's safe to categorize this as "RDNS only".

I suppose that, as far as DNS changes go, 0x20 is relatively
risk-free.  But it's still a protocol change that affects responders
as well.

(I would prefer if the authors answered my previous question about
potential BCP 79 disclosures, though.)

-- 
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: Paul Vixie <[email-masked]>
Date: Fri, 29 Aug 2008 17:03:34 +0000

> it failed to detect initial breakage which other parties have observed

it failed because i had a bug in my syslog() library call arguments and i
literally didn't know that it wasn't universally working.  i quickly fixed
that and found l.google.com and other nameservers, and the second 0x20 draft 
explained how to get confidence in the presence of a non-copying ADNS.  all
of this is in the record, and it does not invalidate the dns-0x20 approach.

and for the record my setup is far from mail-only.

> I suppose that, as far as DNS changes go, 0x20 is relatively risk-free.
> But it's still a protocol change that affects responders as well.

if it works today and will work whether or not any given ADNS is changed,
and if the proposed protocol change is a new SHOULD rather than a new MUST,
then i really think it's fair to categorize it as "RDNS only" when being
compared to other approaches that don't work at all until some/most/all
ADNS are changed.

> potential BCP 79 disclosures, though.)

ISC holds no patents today and has never applied for a patent.  if we were
to apply for a patent some day and if it was granted, then our corporate
bylaws would mandate that the patent be universally available on an
unrestricted royalty free basis with no attribution requirements, similar
to the BSD license on our software.

david dagon was acting as an ISC no-fee consultant when he came up with the
idea of dns-0x20, and i was acting as an ISC employee when i wrote up the
draft and did the initial pilot implementation.

i hope this clarifies the BCP 79 status of dns-0x20.

---

From: Florian Weimer <[email-masked]>
Date: Fri, 29 Aug 2008 20:03:42 +0200

* Paul Vixie:

> that and found l.google.com and other nameservers,

Ah, okay.  Thanks.

> if it works today and will work whether or not any given ADNS is changed,

I don't think your detection logic handles the
NXDOMAIN-for-upper-case-but-echo-with-correct-echo case, but this one
is violating the RFC and is terminally broken anyway (potential DoS
through client query) and it should not be held against 0x20.

If we can't label 0x20 as a protocol change for procedural reasons,
I'm fine with that.

> i hope this clarifies the BCP 79 status of dns-0x20.

Yes, thank you very much.

---

From: David Dagon <[email-masked]>
Date: Sun, 31 Aug 2008 08:54:11 -0400

On Fri, Aug 29, 2008 at 08:03:42PM +0200, Florian Weimer wrote:
<quoting answer>
> Yes, thank you very much.

Sorry, I overlooked your previous inquiry.  

I have no intention of patenting or copyrighting DNS-0x20.  

I have taken numerous steps to resist such efforts.  I have written
(and will shortly present) a paper on DNS-0x20, which destroys any
hopes of international or US-based intellectual property rights.  And
public talks I give on the topic all note that DNS-0x20 is
patent-free.

Thus, none of the organizations I work for could make a colorable
claim otherwise.  I believe I've made it impossible for one to claim
patents of copyrights on DNS-0x20.

-- 
David Dagon              /"\                          "When cryptography
[email-masked]      \ /  ASCII RIBBON CAMPAIGN    is outlawed, bayl
Ph.D. Student             X     AGAINST HTML MAIL      bhgynjf jvyy unir
Georgia Inst. of Tech.   / \                           cevinpl."