Subject: dns-0x20.txt

From: Paul Vixie <[email-masked]>
Date: Tue, 26 Feb 2008 17:43:12 +0000

i think i've missed the cutoff for new -00 drafts, but, this is topical and
i'd like to discuss it anyway, even if it can't be on the philly agenda.

                                    Abstract

      The small (16-bit) size of the DNS transaction ID has made it a
      frequent target for forgery, with the unhappy result of many cache
      pollution events throughout Internet history.  Even with perfectly
      and unpredictably random transaction ID's, random and birthday
      attacks are still theoretically feasible.  This document describes a
      method by which an initiator can improve transaction identity using
      the 0x20 bit in DNS labels.  The method described here has already
      been implemented, and is running in production.

for more, go to <http://sa.vix.com/~vixie/dns-0x20.txt>.

--
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, 26 Feb 2008 18:50:01 +0000

someone asked, why didn't we make this more general, and include the 
relationship between stub (libc) resolvers and full (caching) resolvers.
the reason is, that relationship more often than not has a hotel middlebox,
and we have no expectation that the question section in the response will
be a copy of the one in the request, and any attempt to use the 0x20 bits
in the question section as a covert channel from the stub resolver to itself
via the full resolver, would have to have a fallback plan.  the fallback
plan would be subject to downgrade attacks (similar to the cookie approach
that's been elsewhere proposed) and is thus not worth pursuing.

we are however at a shining moment in history with there are no authority
servers within range of my dns requests who do other than a bit for bit copy
of the question section, and thus, the proposal focuses on the relationship
between full (caching) resolvers and authority servers, where deployment is
safe and sane and can begin immediately, in parallel with the spec updates.

---

From: Alex Bligh <[email-masked]>
Date: Tue, 26 Feb 2008 19:06:37 +0000

> for more, go to <http://sa.vix.com/~vixie/dns-0x20.txt>.

Very clever.

Alex

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 27 Feb 2008 16:39:28 +0200

Paul Vixie wrote:
>       pollution events throughout Internet history.

"Citation needed".  Although there have certainly been many publicized
cases of cache pollution over the years, I'm not aware of a single
case where that pollution was shown to have resulted from an ID
guessing attack.  Demonstrations of vulnerability, yes, but not actual
attacks.  If you know of any documented cases, please share them.

> 4.3. Much effort has been expended in trying to make the DNS transaction
> ID more random and less predictable.  Ultimately such efforts are
> hopeless since with only 16 bits to fight over, a determined attacker
> can use a purely random attack, or even a constant attack, and
> theoretically, eventually, statistically speaking, break through the
> requestor's defenses.

Saying that efforts to make the ID unpredictable are "hopeless" sounds
like there is no point in even trying, which is certainly not the
case.  Even with the technique you describe, the ID still needs to be
unpredictable, and for the 0x20 bits to bring any added benefit, they
need to be unpredictable, too.  How about replacing "hopeless" by
"insufficient"?
-- 
Andreas Gustafsson, [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Wed, 27 Feb 2008 15:09:25 +0000

> "Citation needed".  Although there have certainly been many publicized cases
> of cache pollution over the years, I'm not aware of a single case where that
> pollution was shown to have resulted from an ID guessing attack.
> Demonstrations of vulnerability, yes, but not actual attacks.  If you know
> of any documented cases, please share them.

if i did know of any, i probably couldn't talk about them.  so how about if
i change this text to say "...many cache pollution vulnerabilities
demonstrated..." since that was what i actually meant.

> need to be unpredictable, too.  How about replacing "hopeless" by

done.  draft is updated at http://sa.vix.com/~vixie/dns-0x20.txt, and also
contains a change that was due to wouter@nlnetlabs, such that the tuple used
for matching incoming responses to outstanding requests is correctly limited
to the RCODE=0 or RCODE=3 case, and for OPCODE=0.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 27 Feb 2008 19:59:55 +0000

> I once proposed using a subset of UDP ports, per master.
> 
> That is, if you open (say) 64 ports, when speaking with master 1.2.3.4,
> you always use port[0], and 1.2.3.5 will always get port[1].  You can
> change the ports periodically.

in bind 9.5.0-beta i see an option called "querypool".  can you tell us
how that feature maps to your suggested port mapping/churning?

> This means that to discover all known ports (say, if you wanted to fake
> a master) you need to know what the port will be.  Since a given address
> always gets the same port, an attacker would need to have a lot of
> addresses to discover all ports.

as far as that goes, a full resolver would be harder to pollute if it randomly
chose an authority server each time, rather than sorting by RTT or always
using them in order.  and if that was a common implementation choice, then
zones would be "more secure" if they had more authority servers, since it
would be harder for an attacker to guess what server a response had to come
from.  that may be worth a separate I-D -- anybody see a problem with it?

> Additionally, why not just add this to EDNS0 as an option?  That is,
> make a huge number?  I'm not entirely certain the claim that request
> names are copied directly holds up to all devices.  An EDNS0 option
> would allow any length of additional ID space, and servers can remember
> who participates and who does not, to minimize delay and maximize trust.

this falls apart in the first millisecond after a downgrade attack, so, no.

---

From: Michael Graff <[email-masked]>
Date: Wed, 27 Feb 2008 13:24:54 -0600

- --Michael

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Wed, 27 Feb 2008 19:18:20 -0500

Hi,

I like the dns-0x20 idea although presumably in some cases, like
resolving a country code or resolving x69.us, it would add only two or
three bits.

If you are talking about my cookie proposal below (current draft at
http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-03.txt
)
I'm not aware of any downgrade attack. Could you enlighten me?

Thanks,
Donald

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Paul Vixie
Sent: Tuesday, February 26, 2008 1:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: dns-0x20.txt 

...
via the full resolver, would have to have a fallback plan.  the fallback
plan would be subject to downgrade attacks (similar to the cookie
approach
that's been elsewhere proposed) and is thus not worth pursuing.

...

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Wed, 27 Feb 2008 19:20:13 -0500

Hi,

On using an EDNS0 option, please see my draft at
http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-03.txt
.
For simplicity is proposes a fixed size but it would be trivial to make
it variable.

Thanks,
Donald

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Michael Graff
Sent: Wednesday, February 27, 2008 2:25 PM
To: Paul Vixie; [email-masked]
Subject: Re: dns-0x20.txt

...

- --Michael

---

From: Paul Vixie <[email-masked]>
Date: Thu, 28 Feb 2008 00:54:11 +0000

> http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-03.txt)

i hadn't read that and wasn't aware of it, but it's similar to the idea i
was thinking of, which was first proposed by me during the work that led
up to the publication of RFC 2671.  basically, EDNS0 is susceptible to a
downgrade attack, and any cookie carried in an OPT RR is susceptible to
that downgrade attack.

if somebody is flooding you with answers that don't have an OPT RR, and
then injects a query that causes you to go upstream and you begin by probing
for EDNS0 by including an OPT RR in your upstream query, and then you open
up the hose that has the answer flood in it, and one of those answers has
the right port number and query ID in it, then you'll take it, because you
will think that the other end, that you're just now probing, doesn't speak
EDNS0.

i admit this is a slim window but then so is guessing somebody's PRNG state
and i think that if we're going to try to improve things, we should improve
them rather than just adding more of the same.  like for example DNSSEC.

* * *

marka has made the revolutionary (to me at least) proposal that once you've
heard EDNS0 from a responder, you should remember that you did, and you
should not be willing to believe that they've lost this capability.  i'm a
little worried about the cost of that state, and i'm a little worried about
timing it out in the case of an actual real-world server downgrade, but i'm
intrigued.

especially in light of brian's proposal that the probing be done prospectively
rather than opportunistically.  brian, please note, i wanted it done
opportunistically because it would result in zero extra packets once full
deployment was reached, but in light of subsequent events, i'd be willing to
say 100% is never going to be reached, and extra packets will therefore always
be with us, and so we might as well send them prospectively.

if we do what marka said and we do what brian said, then cookies can work,
assuming that the prospective probe packet is allowed to contain a random
string which must be echoed back exactly, so that only a congestion attack
can prevent the probe from succeeding.  (maybe the probe needs retries.)

what a hairball.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Feb 2008 12:26:50 +1100

> timing it out in the case of an actual real-world server downgrade, but i'm

	I don't remember saying that.

	EDNS has been on standards track for 9+ years now.  It takes
	less than a day to add EDNS support to a nameserver.  There
	really is no excuse anymore for any vendor shipping a DNS
	server that doesn't respond to EDNS queries using EDNS.

	If you have a DNS server, however old, that drops EDNS
	queries then you should ship a fix.  The server is BROKEN
	and the rest of us are feed up with working around broken
	implementations.
	
	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Thu, 28 Feb 2008 01:50:57 +0000

> 	and the rest of us are feed up with working around broken

"send diffs."

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Feb 2008 14:21:55 +1100

> > 	and the rest of us are feed up with working around broken

   5.3. Responders who do not understand these protocol extensions
   are expected to send a response with RCODE NOTIMPL or FORMERR
   as per RFC 1034.  Firewalls that do not pass EDNS are expected
   to respond requests with FORMERR.

   5.4. Firewalls that see a UDP/EDNS request that indicates a UDP
   buffer size that is larger than the firewall's maximum DNS/UDP
   transmission size should respond to the EDNS request with
   RCODE=<TBA> and set the UDP size to the firewalls maximum DNS/UDP
   transmission size.
   
   5.5. There are firewalls that pass EDNS queries but fail to allow
   responses larger that 512 octets through.  A client MAY choose to
   treat a timeout out as indicating the a UDP buffer size of 512
   octets should be advertised in future requests.

   5.6. There are responder and firewalls that silently drop EDNS
   requests.  A client MAY choos to treat timeouts as indicating
   lack of EDNS support.  The client however MUST first attempt
   making EDNS requests with a UDP payload size of 512 if it makes
   this decision.

   5.7. A client MAY treat SERVFAIL as indicating lack of support
   for EDNS for this query only.

---

From: Wouter Wijngaards <[email-masked]>
Date: Thu, 28 Feb 2008 10:08:39 +0100

Eastlake III Donald-LDE008 wrote:
| Hi,
|
| On using an EDNS0 option, please see my draft at
| http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-03.txt
| .
| For simplicity is proposes a fixed size but it would be trivial to make
| it variable.

I like the idea of using an EDNS0 option to contain random data.
Perhaps without a complicated hashing scheme (as you have), but simpler
(once you know the server speaks that option; you are guarded by the
server copying the option back to you; of course the occasional timeout
or reboot presents small windows of downgrade attack. State could be
stored on disk though.). Anyway, your proposal is nice.

Also the dns-0x20 draft breaks binary labels. Badly.
Binary data is garbled by the process. If this is deployed, binary
labels are no longer an option later on (as some upstream full resolver
may break the uppercase bit in the binary data).

DNSSEC, as it gets deployed, makes spoof protection mechanisms obsolete.
And DNSSEC is already deployed on some TLDs. Configuring keys is a much
more reliable way to prevent spoofing for them.

Best regards,
~   Wouter

---

From: Wouter Wijngaards <[email-masked]>
Date: Thu, 28 Feb 2008 09:58:10 +0100

Changed subject line.

Mark Andrews wrote:
|>> 	EDNS has been on standards track for 9+ years now.  It takes
|>> 	less than a day to add EDNS support to a nameserver.  There
|>> 	really is no excuse anymore for any vendor shipping a DNS
|>> 	server that doesn't respond to EDNS queries using EDNS.
|>>
|>> 	If you have a DNS server, however old, that drops EDNS
|>> 	queries then you should ship a fix.  The server is BROKEN
|>> 	and the rest of us are feed up with working around broken
|>> 	implementations.
|> "send diffs."
|
|    5.3. Responders who do not understand these protocol extensions
|    are expected to send a response with RCODE NOTIMPL or FORMERR
|    as per RFC 1034.  Firewalls that do not pass EDNS are expected
|    to respond requests with FORMERR.
|
|    5.4. Firewalls that see a UDP/EDNS request that indicates a UDP
|    buffer size that is larger than the firewall's maximum DNS/UDP
|    transmission size should respond to the EDNS request with
|    RCODE=<TBA> and set the UDP size to the firewalls maximum DNS/UDP
|    transmission size.

I like the text up to here. The remainder is not going in the draft.

|    5.5. There are firewalls that pass EDNS queries but fail to allow
|    responses larger that 512 octets through.  A client MAY choose to
|    treat a timeout out as indicating the a UDP buffer size of 512
|    octets should be advertised in future requests.

Firewalls that drop responses larger than 512 should send an errorcode.

|    5.6. There are responder and firewalls that silently drop EDNS
|    requests.  A client MAY choos to treat timeouts as indicating
|    lack of EDNS support.  The client however MUST first attempt
|    making EDNS requests with a UDP payload size of 512 if it makes
|    this decision.

Firewalls should not silently drop EDNS, but instead send the rcode.

|    5.7. A client MAY treat SERVFAIL as indicating lack of support
|    for EDNS for this query only.

I fail to see relevance of the statement. I suggest to remove it.

I agree with the 'packet loss is packet loss' statement earlier.
If some firewall drops packets, then there is packet loss. If the
firewall wanted to support DNS, it could send a DNS error.

Also, about the topic: every EDNS query gets an EDNS answer.
This is incorrect. Some queries with EDNS do not get EDNS in the answer.
For example: parsing fails on the server in the query section, result is
formerr with no EDNS OPT in the reply. There are many more cases (mostly
errors). A different query or trying later may return with EDNS.

Best regards,
~   Wouter

---

From: Jim Reid <[email-masked]>
Date: Thu, 28 Feb 2008 10:21:27 +0000

> 	and the rest of us are feed up with working around broken

Mark, I agree that DNS stuff which doesn't support EDNS is broken.  
However there's no standards-track RFC that says "thou MUST implement  
ENDS" or "those that don't are broken". This was why Lawrence and I  
came up with draft-ietf-enum-edns0-00.txt. The prime motivation for  
that was to ensure handset manufacturers and the like put EDNS  
support in their ENUM-aware resolvers. Since there's currently no  
other IETF document that says they should do this, they won't add  
this to the handset firmware or whatever.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Feb 2008 21:42:35 +1100

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Changed subject line.
> 
> Mark Andrews wrote:

	The aboves is what should happen.

> Firewalls that drop responses larger than 512 should send an errorcode.

	This is to deal with what does happen.

> Firewalls should not silently drop EDNS, but instead send the rcode.

	Similarly this is to deal with what does happen.
> I fail to see relevance of the statement. I suggest to remove it.

	SERVFAIL is a catch all response.  A RFC 1034 server may still
	end up emitting this to a EDNS query ....

> errors). A different query or trying later may return with EDNS.

	If you parse the OPT record you should add it to the response.
	This allows FORMERR to signal that you don't understand something
	else.

	What we got wrong with EDNS is the rcode handling.  We
	shouldn't have pasted the bits together.  We should have
	just put the rcode in both places, for rcodes > 14 you would
	have a "extended rcode" indication (15) in the header.   We
	could fix this with EDNS1.
 
> Best regards,
> ~   Wouter
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> 
> iD8DBQFHxneikDLqNwOhpPgRAs7+AJ9FbIUe1q+qeccv+I172ULsdBNkhwCfdr4e
> AzyBRjpnvQRWzsIEXKU6WnA=
> =jAuT
> -----END PGP SIGNATURE-----

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Feb 2008 21:52:34 +1100

> ENDS" or "those that don't are broken". 

	I said "respond" not "talks EDNS".  RFC 1034 has FORMERR
	so the server can tell the client that it doesn't understand
	the request.  Servers that don't emit FORMERR when they
	don't understand the request are *broken*.

> This was why Lawrence and I

---

From: Wouter Wijngaards <[email-masked]>
Date: Thu, 28 Feb 2008 12:03:11 +0100

Mark Andrews wrote:
|> 	The aboves is what should happen.

Agreed.

|> 	This is to deal with what does happen.
|> 	Similarly this is to deal with what does happen.

Yes, you're right. Those middleboxes are going to make the edns draft
very complicated. But it shouldn't break DNSSEC to deal with it.

|> 	SERVFAIL is a catch all response.  A RFC 1034 server may still
|> 	end up emitting this to a EDNS query ....

Yep. So that warrants some discussion about it; not sure what, 'an EDNS
query may elicit a SERVFAIL response from a non-EDNS server'?
Split up the text to describe some cases that show the server supports
EDNS (it is in the reply), that it doesn't (rcode NOTIMPL for one), and
inconclusive errors (like packet loss).

|> 	If you parse the OPT record you should add it to the response.
|> 	This allows FORMERR to signal that you don't understand something
|> 	else.

Good idea.

|> 	What we got wrong with EDNS is the rcode handling.  We
|> 	shouldn't have pasted the bits together.  We should have
|> 	just put the rcode in both places, for rcodes > 14 you would
|> 	have a "extended rcode" indication (15) in the header.   We
|> 	could fix this with EDNS1.

Yes it is a bother, and support for EDNS rcodes is lacking. But it is a
waste of 4 bits. Maybe define for every EDNS rcode a fallback rcode for
in the header? (i.e. FIREWALL_EDNS_SIZE_ERROR(NOTIMPL))

Best regards,
~   Wouter

---

From: Pekka Savola <[email-masked]>
Date: Thu, 28 Feb 2008 13:02:39 +0200 (EET)

> Firewalls that drop responses larger than 512 should send an errorcode.

Which is better, in the grand scheme of things, firewalls which try to 
parse and validate DNS packets (and are always falling behind the DNS 
features that they should understand), or that firewalls that try to 
understand as little as possible about DNS packets?

I'd argue that trying to get firewalls to have more and more DNS 
parsing logic is sinking in a swamp.  No matter what we try to do, we 
sink down and down..

Wouldn't it better to a) just cope with firewalls (whether they do 
silent discard or not), or b) recommend they send back an ICMP error 
message?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Michael Graff <[email-masked]>
Date: Thu, 28 Feb 2008 07:47:06 -0600

Paul Vixie wrote:

|> This means that to discover all known ports (say, if you wanted to fake
|> a master) you need to know what the port will be.  Since a given address
|> always gets the same port, an attacker would need to have a lot of
|> addresses to discover all ports.
|
| as far as that goes, a full resolver would be harder to pollute if it
randomly
| chose an authority server each time, rather than sorting by RTT or always
| using them in order.  and if that was a common implementation choice, then
| zones would be "more secure" if they had more authority servers, since it
| would be harder for an attacker to guess what server a response had to
come
| from.  that may be worth a separate I-D -- anybody see a problem with it?

The next logical step is to ask all authority servers and only believe
an answer when you get confirmation.  It'll double the traffic, but DNS
isn't that much now, is it?  (1/2 :)

Or use DNSSEC.

- --Michael

---

From: Paul Vixie <[email-masked]>
Date: Thu, 28 Feb 2008 17:33:11 +0000

> may break the uppercase bit in the binary data).

binary labels are already not usable.  case folding is universal.

> more reliable way to prevent spoofing for them.

agreed, but it's still years away (at a minimum) from universal deployment.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 28 Feb 2008 11:31:16 -0800

At Thu, 28 Feb 2008 17:33:11 +0000,

> binary labels are already not usable.  case folding is universal.

If this means RFC2673, I don't think dns-0x20 necessarily breaks it
because it uses separate bits to indicate the labels are binary.  We
can simply specify the 0x20 resolver MUST NOT modify binary labels.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 28 Feb 2008 20:44:13 +0000

> can simply specify the 0x20 resolver MUST NOT modify binary labels.

i will add that note to the draft.  bitstring labels are dead, anyway,
but we ought to make sure there's an applicability statement for 0x20.

---

From: [email-masked]
Date: Tue, 26 Feb 2008 19:56:18 +0100

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

Paul Vixie wrote on 02/26/2008 06:43:12 PM:

> This document describes a method by which an initiator can improve
> transaction identity using the 0x20 bit in DNS labels.

Clever!

Roy

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 28 Feb 2008 18:58:01 -0800

At Wed, 27 Feb 2008 13:24:54 -0600,

> addresses to discover all ports.

I suspect it's not that helpful, especially such a relatively small
number of ports as 64.  For example, a professional attacker
conducting a bot net would easily identify all the ports.  IPv6 may
make it even easier (since the attacker can validly send probe queries
from millions of source addresses from a single host).

---
JINMEI, Tatuya

---

From: Joe Abley <[email-masked]>
Date: Fri, 29 Feb 2008 12:44:56 -0500

On 27-Feb-2008, at 19:54, Paul Vixie wrote:

> should not be willing to believe that they've lost this capability.

I'm worried about how you would determine that the responder was the  
same across subsequent queries sent to the same address and port.

Anycast servers provide meat for this concern. If the query frequency  
is very low, even routine server renumbering or system administration  
might provide some protein.

On the face of it, this proposal does not seem very robust.

Joe

---

From: Paul Vixie <[email-masked]>
Date: Fri, 29 Feb 2008 17:57:04 +0000

> > marka has made the revolutionary (to me at least) proposal that once
> > you've heard EDNS0 from a responder, you should remember that you did, and
> > you should not be willing to believe that they've lost this capability.
> 
> I'm worried about how you would determine that the responder was the  same
> across subsequent queries sent to the same address and port.

NSID?

> Anycast servers provide meat for this concern. If the query frequency is
> very low, even routine server renumbering or system administration might
> provide some protein.
> 

i agree.  however, we have in the past insisted that all authority servers for
a zone support the same level of dnssec.  could we not also insist that all
members of anycast clusters support the same level of edns?

---

From: Joe Abley <[email-masked]>
Date: Fri, 29 Feb 2008 13:10:25 -0500

>> across subsequent queries sent to the same address and port.

If we're talking green fields, sure, but I don't think it's reasonable  
to expect non-EDNS-capable servers to support NSID.

> members of anycast clusters support the same level of edns?

EDNS is deployed, though, and DNSSEC (largely) is not, so the  
practical results of insisting might be very different.

Joe

---

From: Joe Abley <[email-masked]>
Date: Fri, 29 Feb 2008 13:18:22 -0500

>> across subsequent queries sent to the same address and port.

Oh, and NSID doesn't work, unless you have administrative control of  
all the servers you are talking to, and are able to ensure that the  
NSID data returned by individual servers is unique.

Joe

---

From: [email-masked]
Date: Fri, 29 Feb 2008 18:49:11 +0000

> NSID data returned by individual servers is unique.

	I think paul is thinking of anycast as what he calls "owned"
	anycast, where a single org has the administreative control
	of all the servers...

	"unowned" anycast has no such restriction and then your 
	concerns are perfectly valid.

--bill

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Fri, 29 Feb 2008 16:34:43 -0500

Hi,

See below...

> Sent: Wednesday, February 27, 2008 7:54 PM

That's not exactly true of my proposal. See further below.

> will think that the other end, that you're just now probing, 

What you are talking about can reasonably be called a flaw, but it isn't
really what I understand as a "downgrade attack". The canonical example
of a downgrade attack is where you go through some protocol to set up a
secure connection but you forget to secure the initial negotiation over
what cryptographic algorithm to use. Thus an attacker can always force
you to use the weakest algorithm you will accept, that is, downgrade you
for all the rest of that session to a less secure cipher or whatever.

What you are talking about is a small window which might get some bad
data through but, with my proposal, this window does not occur on every
transaction but only occasionally (like maybe once a day) for a
particular respondent.

If you look at Section 5 of
http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-03.txt
you would expect any initial DNS resolvers and servers shipped with this
Cookies mechanism to default to the Enabled mode. That way, as soon as
they complete one transaction with successful cookies, they latch into
Enforced mode as soft state for the particular server or resolver at the
other end. This doesn't last forever and they would fall back to Enabled
no later than the next time the local secret is reset.

Of course, if you know the other end supports cookies and are willing to
go to the effort, you can configure the resolver/server to always
Enforce cookies for that correspondent and you are then immune to the
attack suggested. (Well, 2**64 immune...)

Thanks,
Donald

---

From: Mark Andrews <[email-masked]>
Date: Sat, 01 Mar 2008 18:00:50 +1100

> practical results of insisting might be very different.

	It's been a implict requirement since EDNS was first
	published.