Subject: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers"

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Thu, 26 Jun 2008 16:33:14 -0400

This note starts a Working Group Last Call for this Standards Track document
ending on noon July 12'th 2006 (Dublin time).

URL for the document and its history:
http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/

This document updates and clarifies RFC1034 in how a resolver should generate
random query ID, how to use multiple ports and possibly addresses to make
it harder to guess the details of a query by a particular resolver.

Please read the document carefully, in particular section 9. At this point
the chairs would like to know if the current RFC2119 wording in that
section is acceptable or how it can be improved.

The document process rules in this group, require that at least
5 members of the working to state that they have read the document
and there is consensus of support to publish as an Standards Track RFC.

         Olafur & Andrew

--
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: Brian Dickson <[email-masked]>
Date: Thu, 26 Jun 2008 17:49:35 -0400

> and there is consensus of support to publish as an Standards Track RFC.

I have read the document carefully.

I have one, very minor nit, on the recommendations in section 9.

Has consideration been given on the matching of "Question name", in a 
case-SENSITIVE manner?

I realize there is other outstanding (in both senses :-)) work on 
randomizing uc/lc on labels that match '[-a-z0-9]*', and I would hope 
this instant ID could be constructed to dovetail with that other ID.

It may require some tinkering in other bits of the text, to handle the 
edge cases of authority servers giving answers whose question matches 
case insensitively but not case-sensitively.

Repeating the question (once) should suffice,  and a case mismatch 
caused by the authority server could be detected.

Conversely, a spoofed packet would need to match case to succeed, or to 
succeed in meeting the 'birthday attack' criteria twice while not 
matching case. Both branches of those conditionals, significantly 
improve the resulting forgery resilience.

Other than that, I am in favo(u)r of the document moving forward.

Brian Dickson

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 Jun 2008 14:59:13 -0700

At 4:33 PM -0400 6/26/08, Ólafur Gu©£mundsson /DNSEXT
>section is acceptable or how it can be improved.

It can be improved.

>9.  Recommended Countermeasures

This should be "Required Countermeasures" because of the use of the 
word "MUST" in the body of the section.

>
>    Given the above, a resolver implementation MUST match responses to
>    the following attributes of the query:
>
>    o  Remote address
>
>    o  Local address
>
>    o  Query port
>
>    o  Query ID
>
>    o  Question name (compared case-insensitively)
>
>    o  Question class and type
>
>    before applying DNS trustworthiness rules (see [RFC2181], section
>    5.4.1).  More precisely, the response source IP address MUST match
>    the query's destination IP address and the response destination IP
>    address MUST match the query's source IP address.

What happened to the other fields (query port, ID, name, and class)? 
This sentence sounds like that only the addresses must match, which 
is not what the rest of the section says. I propose dropping this 
sentence, or making it much longer.

>    A mismatch should
>    be considered a format error, and the response invalid.

A mismatch MUST be considered a format error and the response MUST be 
considered invalid.

>
>    Resolver implementations MUST have the ability to:
>
>    o  Use an unpredictable source port for outgoing queries from the
>       range (53, or > 1024) of available ports that is as large as
>       possible and practicable;
>
>    o  Use multiple different source ports simultaneously in case of
>       multiple outstanding queries;
>
>    o  Use an unpredictable query ID for outgoing queries, utilizing the
>       full range available (0-65535);

(Editorial: drop the last semicolon)

A conformant implementation "MUST have the ability" to do those 
things, but doesn't need to make that available to the operator? That 
seems like undershooting the goal. Proposed change:

-----
A resolver MUST use an unpredictable source port for outgoing queries 
in a port range that is as large as possible and practicable. That 
range SHOULD be 53 plus 1024 to 65535 inclusive unless other 
restrictions are put on the range by the operating system or a 
firewall.

If a resolver has  multiple outstanding queries, it SHOULD use 
different source ports for each query unless doing so is restricted 
by the operating system or a firewall.

A resolver MUST use an unpredictable query ID for outgoing queries in 
the range of 0 to 65535 inclusive.
-----

>    Please note that source ports could be selected from a larger range
>    than indicated, but that this range is regarded as safe, with some
>    lower port numbers reserved for activities which might conflict with
>    proper DNS operation.
>
>    In case these abilities are enabled, the implementation MUST strive
>    to have its choices of source port and query ID remain unpredictable,
>    even if an attacker has knowledge of its (pseudo-)random generator.

How would an implementer do that? If this means to say "use a secret 
value as a seed to the pseudo-random generator", it needs to say so 
explicitly.

>
>    If a resolver is multihomed or otherwise has the ability to transmit
>    and receive datagrams using more than one IP source address, then an
>    IP address can be chosen at random in order to increase an attacker's
>    difficulty in guessing what address to flood.

Worded as a requirement: "...then an IP address SHOULD be chosen at 
random unless doing so would have a negative operational impact, in 
order to..."

>    If a resolver sends out multiple equivalent queries to any
>    authoritative server, before receiving a response, all MUST have
>    identical ID, source address and source port.
>
>    Resolvers SHOULD favour authoritative nameservers with which a trust
>    relation has been established;

Why is this a SHOULD instead of a MUST? Under what circumstances 
would I accept an response from an untrusted server over one from a 
strusted server?

>    Stub-resolvers SHOULD be able to use
>    TSIG ([RFC2845]) or IPSEC ([RFC4301]) when communicating with their
>    recursive resolver.

Add "if those services are available" to the end of the sentence to 
explain the SHOULD.

>    In case a cryptographic verification of response validity is
>    available, resolver implementations MAY waive above rules, and rely
>    on this guarantee instead.

This is completely unclear. Does it mean DNSSEC, IPSEC, or TSIG, all 
of which give cryptographic verification? Which "above rules" might 
be waved?

>
>    Proper unpredictability can be achieved by employing a high quality
>    random generator, as described in [RFC4086].

Most of RFC 4086 is about pseudo-random generators, not true random 
generators, as the document makes clear. This sentence would be 
better worded as "[RFC4086] gives guidelines for attaining high 
quality pseudo-random and random values."

>
>    If a resolver detects that an attempt is being made to spoof it,
>    perhaps by discovering that many packets fail the criteria as
>    outlined above, it MAY abandon the UDP query and re-issue it over
>    TCP.  TCP, by the nature of its use of sequence numbers, is far more
>    resilient against forgery by third parties.

The "MAY" here seems weak. It may abandon UDP any time it wants 
anyway. Also, the word "spoof" in this context is quite unclear. 
Normally, it is used as an active verb, such as "Mallory tried to 
spoof the responses". Proposed rewording:

-----
If a resolver detects that an attempt is being made to send it 
spoofed responses, perhaps by discovering that many packets fail the 
five criteria for matching queries to responses, the resolver SHOULD 
abandon the UDP query and re-issue it over TCP if using TCP is 
possible in the system.
-----

The second sentence is important, but out of place in 
recommendations. The use of TCP to reduce spoofing is never mentioned 
anywhere else in the document. but it should be. A new section, 
probably 4.7, should be added to discuss using TCP when an attack is 
detected.

--Paul Hoffman, Director
--VPN Consortium

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 26 Jun 2008 23:07:31 -0400

>ending on noon July 12'th 2006 (Dublin time).

Correction: "July 12'th 2008 (Dublin time)".

         Olafur

---

From: Wouter Wijngaards <[email-masked]>
Date: Fri, 27 Jun 2008 11:35:52 +0200

Hi Dnsext,

I reviewed -05 of the forgery resilience draft for WGLC.

Unbound 1.0.0 implements the forgery resilience measures.  They are
enabled by default.  And I think these measures are important for modern
day resolvers.  Let me emphasize that I think the content was well worth
implementing to enhance security, before I continue to critique the text
of the document.

I think that because the measures are not to cause interoperability in
the DNS but for security enhancement, this draft is a BCP (not standards
track).

I think the line 'This document updates RFC 1034' should be removed. I
do not think there is any reason.

About the case sensitivity idea.  I have also implemented that in
unbound, however, the default is turned off.  The fall back when no the
case fails needs to get a serious calculation of how many queries to
retry before accepting the downgrade to case insensitive.  The number of
queries needs to be considered in the light of a DoS or flood because of
this.  Otherwise, I think case sensitive query name comparisons could be
a very good idea, and could fit in the framework provided by this draft.

The second formula in section 7.2 has one too many '-' in the dividing
line, otherwise, the ascii art formulas are nicely done.

The unbound implementation uses a practical range of ports, about 59k
ports, using above 1024, avoiding ports in the IANA allocated ports
list, and leaving open a couple small windows in the traditional unix
ephemeral port system ranges.  These choices are made to avoid denial of
service by grabbing important ports for the server that the resolver is
running on.  I think the current text about port ranges is sort of OK,
but these recommendations may be helpful to other implementors.

However, the paragraph:
~   If a resolver sends out multiple equivalent queries to any
~   authoritative server, before receiving a response, all MUST have
~   identical ID, source address and source port.
MUST change to SHOULD. Please add more text to explain the following:
It is allowed to send multiple queries to an authoritative server before
receiving a response, e.g. due to UDP time outs, but at any time the
server MUST only accept for reception one tuple of ID, source address
and source port.

So, in order to follow this precisely (and unbound doesn't due to UDP
retry logic), I want this changed so that the resolver is required to
only *listen* to one ID, source addres and source port combination.

bert hubert in the Authors Addresses is missing capitalization.  The
header says A. Hubert.

So, I think the draft is fine, but should be changed, as above.  Also,
it should be BCP.  Additionally, if name comparison sensitivity work is
done, I would prefer that that new text is presented to the working
group to get feedback on that text.

Best regards,
~   Wouter

---

From: Shane Kerr <[email-masked]>
Date: Fri, 27 Jun 2008 14:32:29 +0200

> a very good idea, and could fit in the framework provided by this  

Most cache poisoning attacks are going to rely on guessing state from  
the querying server, so this involves sending multiple answers to a  
query, right?

In this case, I think rather that as soon as a server has answered a  
query preserving case, then future queries to that server should rely  
on that behavior. It means sort of increasing the security if  
possible, rather than trying to determine whether a server preserves  
case through retries.

There are problems with this of course (operators using multiple  
vendors on a single IP address via load balancing, for example), but I  
think it is basically a way to add 0x20-style security without extra  
packets.

> Additionally, if name comparison sensitivity work is

I agree.

--
Shane

---

From: Paul Vixie <[email-masked]>
Date: Fri, 27 Jun 2008 13:57:38 +0000

> From: Shane Kerr <[email-masked]>
> ...
> In this case, I think rather that as soon as a server has answered a query
> preserving case, then future queries to that server should rely on that
> behavior. It means sort of increasing the security if possible, rather than
> trying to determine whether a server preserves case through retries.
> 
> There are problems with this of course (operators using multiple vendors on
> a single IP address via load balancing, for example), but I think it is
> basically a way to add 0x20-style security without extra packets.

how will you know if a server preserves case unless you send something having
mixed case and it echos you, and then you send it different mixed case and it
echos that also?

responses are supposed to be in "zone case".  so if you query for 3com.com
you get back 3Com.com, as a way to protect the zone owner's trademarks.  the
implementations i tested almost always answer in "query case" except where
they "always downshift to lower case".  nobody preserves "zone case", which
is a latent bug and if i worked at 3Com i'd be angry about it.

furthermore, name compression in intermediaries tends to ignore case, so if
the first instance of the "3Com.com" domain happens to be "3COM.COM" then
that case will be seen not just in the answer section but also the authority
and additional sections.  therefore the parent zone's delegation is likely
to have more impact on the case of a domain name than anything at the apex,
since it'll have entered a given cache first.

the reason dns-0x20 currently says "try several times with different cases
and make the server solve your case-riddle and solve different QID-riddles
each time" is to be sure that a case-mismatch in the response isn't due to
any kind of attack.  so the thing dns-0x20 is trying to prove is that you're
safe to consume a mismatching answer, and not that a given server does or
doesn't preserve case.  that difference sounds subtle but it's gigantic.

and i don't see how to do it without extra packets.  but i don't mind those
extra packets, it only overloads servers who don't preserve case, and they
have a trivial way to get the extra traffic to stop: start preserving case.

> > Additionally, if name comparison sensitivity work is done, I would prefer
> > that that new text is presented to the working group to get feedback on
> > that text.
> 
> I agree.

it was previously agreed here that we would not workshop the dns-0x20 idea
as part of the forgery-resilience effort, and that the two drafts would
proceed independently.  forgery-resilience is already two years old and i'd
rather see it published without any mention (that is, no mention at all) of
domain name case.  i have not read the current draft but if it talks at all
about preserving case or comparing casefully vs. caselessly then i object.

i welcome comments on the dns-0x20 draft itself, but not if it makes the
forgery-resilience draft take longer to see the light of day.  we need it
out in the field.  actually we needed it years ago.  let's get it out there.

---

From: Scott Rose <[email-masked]>
Date: Fri, 27 Jun 2008 10:55:55 -0400

I've read the draft and after Paul Hoffman's comments/changes are 
addressed I think it should move forward.

One comment:

    "In case these abilities are enabled, the implementation MUST strive
    to have its choices of source port and query ID remain unpredictable,
    even if an attacker has knowledge of its (pseudo-)random generator."

Along the lines of Paul's comment - can the implementer really guarantee 
that in any way?  I think the MUST in the above can be toned down or 
dropped.

Scott

-- 
----------------------------------------
Scott Rose            Computer Scientist
NIST
ph: +1 301-975-8439
[email-masked]

http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
-----------------------------------------

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 27 Jun 2008 09:16:50 -0700

>do not think there is any reason.

There are SHOULDs and MUSTs in this document that are not in 1034 in 
areas that 1034 touches on, so it does in fact update 1034.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Vixie <[email-masked]>
Date: Fri, 27 Jun 2008 16:23:54 +0000

> From: Paul Hoffman <[email-masked]>
> 
> This seems to be adding a new and useful feature in a terribly kludgy way
> that is likely to cause hidden interoperability problems. The WG should
> balance whether or not the value (harder to forge when the feature works) is
> worth those potential problems.

http://tools.ietf.org/id/draft-vixie-dnsext-dns0x20-00.txt is the draft, and
it is unrelated to forgery-resilience, which is today's topic here.  please
read the draft and comment on it (everybody, not just mr. hoffman).

> If not, creating a trivial DNS extension (add another 64 bits of randomness)
> would gain the benefit desired with no interop problems for those systems
> that implement the new extension.

trivial?  "you keep using that word; i do not think it means what you think
it means."  or perhaps: "they tried, and failed?" ... "they tried, and died."

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 27 Jun 2008 08:58:58 -0700

This seems to be adding a new and useful feature in a terribly kludgy 
way that is likely to cause hidden interoperability problems. The WG 
should balance whether or not the value (harder to forge when the 
feature works) is worth those potential problems. If not, creating a 
trivial DNS extension (add another 64 bits of randomness) would gain 
the benefit desired with no interop problems for those systems that 
implement the new extension.

--Paul Hoffman, Director
--VPN Consortium

---

From: Brian Dickson <[email-masked]>
Date: Fri, 27 Jun 2008 14:30:26 -0400

> mixed case and it echos you, and then you send it different mixed case and it

[snip]

> have a trivial way to get the extra traffic to stop: start preserving case.

"Don't check for an error condition you don't know how to handle."
Corollary - don't check for things you don't care about.

This can be handled nearly trivially, with one extra query (and then 
only for those servers who don't preserve
the case of the query):

=> If the question in the response matches case-insensitively, but not 
case sensitively, re-query with the question
*from* the suspect answer, including the answer's question's case.

=> If *that* doesn't match upon receiving an answer, that's an error, 
for sure.

Here's why:
=> If something is not preserving case, but gives otherwise matching 
answers, then it could reasonably be expected to return *consistent* 
results.

E.g. Q->A:
    Foo->Foo (good - case matched)
vs
    Foo->FOO (try one more time)
    FOO->FOO (good - results were the same, and on the second query case 
matched.)
vs
    Foo->foo (try one more time)
    foo->FOO (bad - results changed between case-insensitive identical 
queries)

There are probably some corner cases involving load balancers and 
heterogenous software implementations.
I believe it is the case that either:
(1) case should be preserved between query and response
(2) case of answer should be independent of case of query, *but* always 
the same for a given label in the zone.

Is this an assertion true as either (1) or (2), for all known authority 
server software systems deployed?
Does anyone know, or have a good guess?
Does anyone know of counterexamples?

> out in the field.  actually we needed it years ago.  let's get it out there.

I agree whole-heartedly (and then some) with this last statement.
If it isn't nearly trivial to add case stuff, in terms of 
required/recommended, perhaps as a footnote/appendix,
i.e. outside of the official aspects of the ID, would be a prudent thing 
to do...

Brian

---

From: Tony Finch <[email-masked]>
Date: Fri, 27 Jun 2008 19:44:41 +0100

> Has consideration been given on the matching of "Question name", in a

I think the conclusion of Vixie's 0x20 discussion was to keep it separate
from Bert's draft, because 0x20 introduces interoperability problems
whereas the forgery-resilience techniques are safe.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
FORTIES CROMARTY FORTH: MAINLY SOUTHWESTERLY 4 OR 5, OCCASIONALLY 6, BECOMING
VARIABLE 4. MODERATE OR ROUGH DECREASING SLIGHT OR MODERATE. OCCASIONAL RAIN.
MODERATE OR GOOD, OCCASIONALLY POOR.

---

From: Tony Finch <[email-masked]>
Date: Fri, 27 Jun 2008 19:52:14 +0100

On Fri, 27 Jun 2008, Scott Rose wrote:
> Along the lines of Paul's comment - can the implementer really guarantee that
> in any way?  I think the MUST in the above can be toned down or dropped.

Perhaps it should say "knowledge of the implementation of its
(pseudo-)random number generator" as opposed to its secret internal state.
This is the usual criterion for a cryptographically secure PRNG.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
ROCKALL MALIN: CYCLONIC BECOMING SOUTHWESTERLY 5 OR 6, OCCASIONALLY 7 AT
FIRST. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH. RAIN OR THUNDERY SHOWERS.
MODERATE OR GOOD, OCCASIONALLY POOR.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 27 Jun 2008 22:10:49 +0000

> heterogenous software implementations.

indeed, i think my proposed mechanism would still have to be used, because
of the degenerate HA/LB case.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 27 Jun 2008 16:30:34 -0700

At 2:30 PM -0400 6/27/08, Brian Dickson wrote:
>    FOO->FOO (good - results were the same, and on the second query 
>case matched.)

If the attacker knew you were doing this, why wouldn't he just send 
back the same response to your second query, like half a second later?

--Paul Hoffman, Director
--VPN Consortium

---

From: Brian Dickson <[email-masked]>
Date: Fri, 27 Jun 2008 20:19:03 -0400

> back the same response to your second query, like half a second later?

The presumptions (in the ID) are that the attacker doesn't have access 
to the wire itself, and does not have control of arbitrary authority 
servers.
At best, the attacker has control of some authority server somewhere.

The recommendations of the ID include, repeat queries using different 
source ports. This alone would defeat the "send back the same response" 
vector.

Plus:

If the attacker can deterministically know the parameters to inject bad 
"foo", you're already toast.

If the attacker doesn't, the case check is no worse, probably a bit 
better, and possibly a lot better.

Note the following:

The probability for a single-instance birthday attack, based on random 
query-id, is low even with other factors weakening things (e.g. number 
of ports used << 2^16).

The probability of two successive such successful injections (i.e. both 
succeed in guessing PRNG 16-bit values) is substantially lower, i.e. 
decreases from 1/N to 1/(N^2) for some (large) value N.

(That's why I raised the case issue, and hinted that while not strictly 
necessarily, having it dovetail into the 0x20 proposal, is a nice segue.)

Brian

---

From: Tony Finch <[email-masked]>
Date: Fri, 27 Jun 2008 19:44:41 +0100

Tony.

---

From: bert hubert <[email-masked]>
Date: Sat, 28 Jun 2008 09:12:48 +0200

> from Bert's draft, because 0x20 introduces interoperability problems

I would indeed vastly prefer to keep things separate.

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

---

From: bert hubert <[email-masked]>
Date: Sun, 29 Jun 2008 13:39:18 +0200

> This is the usual criterion for a cryptographically secure PRNG.

Added this, thanks.
http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/changeset/28

---

From: bert hubert <[email-masked]>
Date: Sun, 29 Jun 2008 13:36:11 +0200

> word "MUST" in the body of the section.

I've changed it to 'Countermeasures' while this discussion runs.

> >   [Local address, Query port, Query ID, Question name,Question class and type]

This sentence was added during the previous round of editing. It indeeds
adds only a partial explanation. As a middle ground, I've removed this
partial improvement, and beefed up the original bullet-points:

 Given the above, a resolver implementation MUST match responses to the
 following attributes of the query:

  * Source address against query destination address                                                                            
  * Destination address agaist query source address                                                                             
  * Destination port against query source port                                                                                
  * Query ID                                                                                  
  * Question name
  * Question class and type

 before applying DNS trustworthiness rules (see <xref target="RFC2181"/>,
 section 5.4.1).

> A mismatch MUST be considered a format error and the response MUST be 

Makes sense.

> (Editorial: drop the last semicolon)

Thanks.

> seems like undershooting the goal. Proposed change:

Do you think we need to make it explicit? Having an ability appears to imply
that it can be used.

> range SHOULD be 53 plus 1024 to 65535 inclusive unless other 

While I see merit in your suggested changes, this paragraph is starting to
suffer from metal fatigue and it will soon break. In other words, I prefer
not to tinker with it anymore unless the improvement is vast.

> value as a seed to the pseudo-random generator", it needs to say so 

This is one way to do it, I'm not ruling out anybody using a hardware
random generator. I've added: 'This can be achieved by seeding an algorithm
with a secret state.'.

> random unless doing so would have a negative operational impact, in 

This is an operator requirement, and hence outside the cope of this
document.

> would I accept an response from an untrusted server over one from a 

Fine.

> Add "if those services are available" to the end of the sentence to 

Done.

> of which give cryptographic verification? Which "above rules" might 

I've move this paragraph up so it covers only ('the above') the things you
could do away with when using cryptgraphic verification of response
*authenticity*. I don't want to restrict this document to any specific
verification protocol that might come along. So DNSSEC, IPSEC, TSIG might
all be fine.

> Most of RFC 4086 is about pseudo-random generators, not true random 

I've added '(pseudo-)'. This paragraph is the result of prolonged
discussions, and it too is starting to suffer from metal fatigue, hence only
a small change.

> spoof the responses". Proposed rewording:

I'm pondering better wording for this paragraph. Your suggestion comes a
long way but it is still not abundantly clear.

> abandon the UDP query and re-issue it over TCP if using TCP is 

On the MAY, SHOULD front, I think this needs some more discussion.

Paul, many thanks for your careful reading of the draft! Your changes can be
seen in http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/changeset/27

	Bert

---

From: bert hubert <[email-masked]>
Date: Sun, 29 Jun 2008 13:41:36 +0200

Thanks.

> that in any way?  I think the MUST in the above can be toned down or 

I anticipated this problem, hence the somewhat odd wording that an
implementation "MUST strive". This is like the guaranteeing the pursuit of
happiness instead of guaranteeing happiness.

I hope the 'MUST strive' formula means we can lambast implementations that
don't try hard enough, without mandating them to solve the halting problem.

But let me know what you think.

	Bert

---

From: bert hubert <[email-masked]>
Date: Sun, 29 Jun 2008 13:44:06 +0200

On Fri, Jun 27, 2008 at 11:35:52AM +0200, Wouter Wijngaards wrote:
> -----BEGIN PGP SIGNED MESSAGE-----

Thank you!

> do not think there is any reason.

I don't consider myself competent to discuss the nuances of this. 

> unbound, however, the default is turned off.  The fall back when no the

It has previously been decided to not commingle the case sensitivity tricks
with this draft since there are cases where the 0x20-trick appears not to
work.

> line, otherwise, the ascii art formulas are nicely done.

Ah! Fixed, thanks. 

> but these recommendations may be helpful to other implementors.

This paragraph has gone to and fro many times over the past two years. I
like to think it has settled down by now. 

> MUST change to SHOULD. 

Why?

> Please add more text to explain the following:

Understood, and it even makes more sense this way. 

> bert hubert in the Authors Addresses is missing capitalization.  The

And both are true - my initial is A but people call me Bert. I've added
caps.

Thanks for your review!

---

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Sun, 29 Jun 2008 08:00:16 -0400

x20 is out-of-scope for this document, please take any discussion on 0x20 (and
other additions) to a mail thread that does not contain WGLC in the subject
line.

         thanks
         Olafur

---

From: Alex Bligh <[email-masked]>
Date: Sun, 29 Jun 2008 13:19:02 +0100

> happiness instead of guaranteeing happiness.

General comment: I find it difficult to understand the benefit of "MUST
strive to do X" over "SHOULD do X".

Take two implementations, neither of which do X, and and RFC worded
"MUST strive to do X". One could be conformant to the RFC and one not,
even though the functionality was identical, on the basis that one
implementer tried hard to make his implementation do X, and one
didn't try at all. They could even have identical code.

I think you either want to go for the simple options ("SHOULD do X"
or "MUST do X") or focus on the result you want to achieve rather than
an analysis of the effort put in "MUST (maximise|minimise) effect Y".

In this case I suggest:
>    "In case these abilities are enabled, the implementation MUST *ensure*
>    its choices of source port and query ID remain unpredictable,
>    even if an attacker has knowledge of both *the algorithm used by the*
>    implementation including its* (pseudo-)random generator *and
>    previous wire data*"

Clearly if you know both the algorithm and the internal state of a
PRNG you can predict its next output. Not knowing the algorithm
is insufficient if the algorithm can be guessed from wire data
(e.g. an incrementing port).

The only reason I can think of toning this down from MUST is
because some host systems might not support it. But then the result
is the implemented system as a whole is not conformant in that it
is not "more resilient against forged answers"; that isn't a
disaster, just a reflection of reality. If you really need to
tone it down for this reason insert "subject to user configuration
or host limitations" or similar. But I think "MUST" is better.

Alex

---

From: Alex Bligh <[email-masked]>
Date: Sun, 29 Jun 2008 13:20:18 +0100

> (e.g. an incrementing port).

I forgot to add that I don't think that change is critical, given
this is a WGLC, just a nice-to-have.

Alex

---

From: Paul Vixie <[email-masked]>
Date: Sun, 29 Jun 2008 16:33:41 +0000

> But let me know what you think.

i think it's unreasonable to use words like this that don't offer specific
guidance.  as an implementor, i'd ignore the words, knowing they were a trap
so that folks could yell at me no matter what i did, and so, i'd ignore the
yelling, too.

(remembering that one of the great mass murderers of the first half of the
20th century was convicted only of tax evasion since that's all the
authorities could actually prove.)

---

From: bert hubert <[email-masked]>
Date: Sun, 29 Jun 2008 20:41:05 +0200

> is not "more resilient against forged answers"; that isn't a

The reason it was toned down originally was that it was claimed it is a
mathematical impossibility to ensure that a (pseudo-)random generator be
unpredictable forever and ever.

The only thing one can do is try. 

But I'm fine with any wording, although I have a soft spot for 'MUST
strive'.

Perhaps Scott has some guidance - NIST routinely mandates things in this
area, perhaps there is some better wording that does not mandate
implementors to be able to predict the progress of mathematics for the next
100 years.

	Bert

---

From: Alex Bligh <[email-masked]>
Date: Sun, 29 Jun 2008 20:44:47 +0100

> The only thing one can do is try.

Well technically that might be accurate, but (I allege) only in the sense
that it is mathematically impossible to generate a hash function that is
never invertible given enough data and CPU processing power. Indeed many
PRNG algorithms are very similar to a truncated hash of the internal
state.

I really wouldn't worry about this, but if we are going to get pedantic,
I have a slightly different concern which is that the problem is not
really making the port etc. difficult to predict accurately, but making
it difficult to predict. Using a port of 20000 or 20001 randomly is
impossible to predict (and conforms to the previous "MUST"),
but is all but useless against forged replies.

So I suggest:
>    "In case these abilities are enabled, the implementation MUST
>    minimise the ability of third parties to guess the implementation's
>    future choices of source port and query ID remain even where that
>    third party has knowledge of both the algorithm
>    used by the implementation including its (pseudo-)random
>    generator and all previous wire data"

Alex

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 29 Jun 2008 14:11:16 -0700

There seems to be a basic disconnect in this discussion, and 
reconnecting it will help us focus.

Is this document meant to be a Best Current Practices RFC or a 
Standards Track RFC? The two have *very* different properties for the 
section we are discussing.

If is meant to be a BCP, we can actually drop the reference to RFC 
2119 and dispense with the caps-lock MUST and SHOULD stuff and just 
say what we mean in the language we think is most appropriate for 
describing what we think an operator should do if they are doing 
their "best".

If it is meant as a Standards Track RFC, then the RFC 2119 language 
has a fairly precise meaning. A disinterested third party should be 
able to examine an implementation and read the RFC and say "this 
implementation conforms to the RFC" or "this implementation does not 
conform to the RFC".

My comments on this thread were based on reading the bit above the 
title of the draft which says "Standards Track" and taking that at 
face value. However, it seems that this is not what others on the 
list think is the case, or want to be the case. FWIW, it is the WG 
chairs who determine this, not the WG, although chairs often ask the 
WG for opinions.

--Paul Hoffman, Director
--VPN Consortium

---

From: Scott Rose <[email-masked]>
Date: Mon, 30 Jun 2008 08:55:10 -0400

> implementors to be able to predict the progress of mathematics for the next
There isn't much in the way of guidance for application developers other 
than "make sure you can (and do) use an approved PRNG".  A list of 
approved algorithms is on the NIST site and implementations are 
validated via the NIST Cryptographic Algorithm Validation Program:

http://csrc.nist.gov/groups/STM/cavp/

NIST tends to give guidance/recommendations on the crypto algorithm 
development side, then say implements "Shall" (as in "must comply with 
the regulation") use a library that has been validated.  NIST doesn't 
put the burden on the application developer to do anything more than 
properly use the approved crypto library.

So the phrase "MUST strive" could still be included (or "SHOULD strive") 
  with text indicating that it should be interpreted to mean the 
implementor should properly use the PRNG.

Scott

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 30 Jun 2008 10:54:31 -0400

Dear colleagues,

> and there is consensus of support to publish as an Standards Track RFC.

Just to be clear, we are requesting that the document be considered
for adoption as a standards track RFC.  Therefore, if you think the
draft needs fixing to address its suitability for the standards track,
those comments are on-topic.  Similarly, if you have read and do not
support the document as a standards track RFC, you should say so.  And
finally, of course, if you have read the document and think it should
be a standards track RFC, say that too.  But we'd like to avoid a
debate about whether it ought to be on the standards track, and we'd
like to avoid discussing how the document should be altered so that it
would be appropriate for some other intended status.

For what it's worth, our reasoning for putting this on the standards
track is that the requirement in section 9 that resolvers be capable
of using multiple source ports at once is arguably a new requirement,
and could have interoperation effects.  This is also the basis for the
note of what RFCs the I-D will update if approved.

Best regards,

Olafur & Andrew

-- 
Andrew Sullivan
[email-masked]
+1 503 667 4564 x104
http://www.commandprompt.com/

---

From: Paul Vixie <[email-masked]>
Date: Mon, 30 Jun 2008 15:34:52 +0000

> those comments are on-topic.  ...

i think it needs fixing along the lines of what wouter said, and to remove
any mention of upper/lower case comparisons of question name, but other than
that i am in favour of progressing this draft.

> note of what RFCs the I-D will update if approved.

this is going to be controversial some day.  use of multiple source ports is
one known defense for one known class of spoofing attack.  there may be other
defenses some day, and there may be other classes of spoofing attack.  making
multiple source ports a requirement isn't in the right spirit.  requirements
should be written in terms of results not methods.  it's fine to require that
dns transactions be protected against spoofing by an equivilent of 30 bits of
randomness (16 in the QID, 14 or so in the UDP port) but if someone wants to
implement that with 14 in the QID, 10 in the UDP port, 3 in the 0x20 bits (if
that bill ever becomes a law) and 3 in the IP source (using a brace of 8 IP
addresses), or if someone wants to randomize the IP destination (rather than
using RTT sorting or any other semi-deterministic selection criteria) to get
one or two bits of randomness, this RFC should permit the other approaches.
likewise if SIG(0) is used, or TSIG, or some new protocol feature that gives
a 30 (or 32 or 128 or whatever) bit QID.  or IPSEC tunnels with out of band
authentication data.

if this is going to be on the standards track, then section 9 will have to be
genericised and put in terms of requirements not methodologies.  if it's going
to be a BCP then it's fine like it is now.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 30 Jun 2008 11:38:59 -0400

Andrew Sullivan wrote:
> be a standards track RFC, say that too.

I have read the document.

I think it should be a standards track RFC.

I think it needs a minor fix to clarify the "compare the question 
section of the reply" as far as case-sensitivity is concerned.

Here's what I think needs to be clarified:

A response is valid if the question section matches in a 
case-insensitive fashion but not in a case-sensitive fashion.
A response is also valid if the question section matches in a 
case-sensitive fashion.

Clearly, an implementation would be compliant with the ID (and other 
RFCs) if the comparison is done in a case-insensitive fashion.

What needs to be clarified is that:
An implementation *may* do additional forgery-resilience stuff involving 
case-sensitivity, so long as it does not strictly require case-sensitive 
matching.
I.e. that a response which matches case-insensitively but not 
case-sensitively, that is not forged, is not permanently rejected.

Furthermore, it should be clear that this additional checking (case 
sensitivity) is *strictly* optional, and matching case-insensitively 
would be completely conforming.

I recognize that careful choice of words may be needed to convey this.

However, I think it is important to ensure that even prior to 0x20, that 
implementers may begin putting in hooks for it, without running afoul 
(or even appearing to run afoul of) forgery-resilience.

I believe everyone reading this list understands this already - it is 
important, however, that the sentiment of the WG be reflected in the ID, 
so that those who don't read anything but the RFCs, "get it".

Brian Dickson

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 30 Jun 2008 11:54:43 -0400

> that i am in favour of progressing this draft.

…
 
> to be a BCP then it's fine like it is now.

Since the request is about the document as a candidate for the
standards track, if you have ways you think it needs to be fixed,
sending replacement text will be a big help.

Best regards,

Andrew

---

From: Paul Vixie <[email-masked]>
Date: Mon, 30 Jun 2008 16:46:33 +0000

> sending replacement text will be a big help.

can i first see the current text, since there have been a lot of
proposed edits here in the last few days since a draft was pub'd.

---

From: bert hubert <[email-masked]>
Date: Mon, 30 Jun 2008 19:11:01 +0200

> proposed edits here in the last few days since a draft was pub'd.

Sure - the latest version in XML can always be read on
http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/browser/trunk/draft-ietf-dnsext-forgery-resilience.xml

It can be converted using http://xml.resource.org/

I've put the up to the minute text version on
http://ds9a.nl/tmp/draft-ietf-dnsext-forgery-resilience.txt

	Bert

---

From: Paul Vixie <[email-masked]>
Date: Mon, 30 Jun 2008 18:22:33 +0000

> http://ds9a.nl/tmp/draft-ietf-dnsext-forgery-resilience.txt

+---
| Updates: 1034 (if approved)
+---

strike this, unless you can cite chapter and verse of what's being changed.
(just because it's on the standards track doesn't mean it automatically
updates 1034, you have to say what changes you're making, which i don't see.)
merely amending the specification with new rules does not automatically
update 1034 or 1035.  (some day there will be an RFC which is automatically
updated by any DNS protocol amendment, but right now there isn't one.)

+---
| 9.  Countermeasures
...
|    o  Destination address agaist query source address
+---

s/agaist/against/

+---
...
|    Resolver implementations MUST have the ability to:
| 
|    o  Use an unpredictable source port for outgoing queries from the
|       range (53, or > 1024) of available ports that is as large as
|       possible and practicable;
| 
|    o  Use multiple different source ports simultaneously in case of
|       multiple outstanding queries;
| 
|    o  Use an unpredictable query ID for outgoing queries, utilizing the
|       full range available (0-65535)
+---

here's the rub.  maybe try this:

	Full DNS resolvers MUST defend themselves against IP spoofing
	as follows:

	o  Exposed transaction identity markers such as UDP source port
	   or DNS ID must be unpredictable by any trivial observation
	   (so, constants are outlawed, as are simple increments; and,
	   any random number generator used should be crypto-strength.)

	o  A minimum of 30 bits of transaction identity must be expressed
	   and compared, either using 16 bits of QID plus 14 bits of UDP
	   source port, or an equivilent amount expressed some other way
	   (for example, using multiple IP source addresses, or similar.)

	o  Use more than one IP/UDP endpoint simultaneously, in the case
	   of multiple outstanding upstream queries.  Any combination of
	   multiple IP source addresses and multiple UDP port numbers is
	   acceptable, as long as the number of combinations is nontrivial.

	Discussion:

	Since an attacker can force a full DNS resolver to send queries
	to the attacker's own name servers, any constant or sequential
	state held by such a resolver can be measured, and it must not be
	trivially easy to reverse engineer the resolver's internal state
	in a way that allows low-cost high-accuracy prediction of future
	state.

	A full DNS resolver with only one or a small number of upstream-
	facing endpoints is effectively using constants for IP source
	address and UDP port number, and these are very predictable by
	potential attackers, and must therefore be avoided.

	A full DNS resolver who uses a simple increment to get its next
	DNS ID is likewise very predictable and so very spoofable.

	Finally, weak random number generators have been shown to expose
	their internal state, such that an attacker who witnesses several
	sequential "random" values can easily predict the next ones.  A
	crypto-strength random number generator is one whose output cannot
	be predicted no matter how many successive values are witnessed.

+---
|    Please note that source ports could be selected from a larger range
|    than indicated, but that this range is regarded as safe, with some
|    lower port numbers reserved for activities which might conflict with
|    proper DNS operation.
| 
|    In case these abilities are enabled, the implementation MUST strive
|    to have its choices of source port and query ID remain unpredictable,
|    even if an attacker has knowledge of the implementation of its
|    (pseudo-)random generator.  This can be achieved by seeding an
|    algorithm with a secret state.
| 
|    If a resolver is multihomed or otherwise has the ability to transmit
|    and receive datagrams using more than one IP source address, then an
|    IP address can be chosen at random in order to increase an attacker's
|    difficulty in guessing what address to flood.
| 
|    If a resolver sends out multiple equivalent queries to any
|    authoritative server, at any time only one ID, source address and
|    source port combination MUST be acceptable as the correct answer.
| 
|    In case a cryptographic verification of response authenticity is
|    available, resolver implementations MAY waive above rules, and rely
|    on this guarantee instead.
| 
|    Resolvers MUST favour authoritative nameservers with which a trust
|    relation has been established; Stub-resolvers SHOULD be able to use
|    TSIG ([RFC2845]) or IPSEC ([RFC4301]) when communicating with their
|    recursive resolver, if these services are available.
| 
|    Proper unpredictability can be achieved by employing a high quality
|    (pseudo-)random generator, as described in [RFC4086].
| 
|    If a resolver detects that an attempt is being made to spoof it,
|    perhaps by discovering that many packets fail the criteria as
|    outlined above, it MAY abandon the UDP query and re-issue it over
|    TCP.  TCP, by the nature of its use of sequence numbers, is far more
|    resilient against forgery by third parties.
+---

i'd axe all of this text.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 30 Jun 2008 11:42:39 -0700

Given that we have cleared up the status, I reiterate my objection to:
    Resolver implementations MUST have the ability to:
That is too weak. There has been no arguments showing why using the 
three mechanisms listed would be harmful, nor that they are 
impossible. Why have this document on standards track if we are just 
suggesting that nice resolvers might do something?

--Paul Hoffman, Director
--VPN Consortium

---

From: Florian Weimer <[email-masked]>
Date: Mon, 30 Jun 2008 20:52:03 +0200

> updates 1034, you have to say what changes you're making, which i don't see.)

For interoperability reasons, TCP fallback when a potential blind
spoofing situation is detected requires an update RFC 1123, but this is
subject to interpretation (as was discussed before).

(TCP fallback with TC=0 is certainly a change from an operational
perspective, irrespective what you think the RFCs say.)

---

From: Florian Weimer <[email-masked]>
Date: Mon, 30 Jun 2008 22:02:55 +0200

> |    resilient against forgery by third parties.

Last sentence should read:

| The sequence numbers used by TCP provide a straightforward way to add
| a significant amount of additional randomness, provided that the TCP
| stack used by the resolver uses properly unpredictable initial
| sequence numbers.

(Not sure if one party is enough, or both server and client need proper
randomness.)

Perhaps the draft should mention that good query IDs should be used over
TCP, too.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 30 Jun 2008 20:03:15 +0000

> For interoperability reasons, TCP fallback when a potential blind spoofing
> situation is detected requires an update RFC 1123, but this is subject to
> interpretation (as was discussed before).

detecting these is questionable.  all you know is that the

	<servaddr,cliaddr,cliport,qid,qname,qclass,qtype>

did not match any of your outstanding upstream queries.  if you can find a
match for a shorter tuple, like:

	<servaddr,cliaddr,cliport,qid,qname,qclass,qtype>
	<servaddr,cliaddr,cliport,qid,qname,qclass>
	<servaddr,cliaddr,cliport,qid,qname,       qtype>
	<servaddr,cliaddr,cliport,qid,      qclass,qtype>
	<servaddr,cliaddr,cliport,    qname,qclass,qtype>
	<servaddr,cliaddr,        qid,qname,qclass,qtype>
	<servaddr,        cliport,qid,qname,qclass,qtype>
	<         cliaddr,cliport,qid,qname,qclass,qtype>

then you might be able to guess that it was a spoof, but it could also be a
stupid 4.2BSD-era (incl. SunOS or Ultrix) multihomed machine, or a NAT box
that thinks its smarter than you, or a late response to a previous query, or
a response to some other query you sent to the same server.

i don't think there's a "detect spoofing" here.  if you get a response that
doesn't match a query you've got outstanding, then you just drop it and keep
doing what you were doing (which means waiting for the next spoof attempt or
perhaps for the real answer.)

---

From: Florian Weimer <[email-masked]>
Date: Mon, 30 Jun 2008 22:43:19 +0200

* Paul Vixie:

> if someone wants to randomize the IP destination (rather than using
> RTT sorting or any other semi-deterministic selection criteria)

Randomizing IP destination is difficult to implemented effectively
because timing differences may reveal the destination actually chosen
with high probability, while it is still possible to send a spoofed
response.

There's probably an optimum distribution of IP destinations, at least
after fixing certain parameters of an attack scenario (bandwidth,
network delays, and so on).  In some cases it's a uniform distribution,
in others, always using the smallest RTT seems preferable.

---

From: bert hubert <[email-masked]>
Date: Mon, 30 Jun 2008 22:46:35 +0200

> (Not sure if one party is enough, or both server and client need proper

I'm not sure either - I copped out by adding:

"The sequence numbers used by TCP provide a straightforward way to add a
 significant amount of additional randomness, provided that the TCP stacks
 used employ properly unpredictable initial sequence numbers."

	Bert

---

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Mon, 30 Jun 2008 22:31:59 -0400

>updated by any DNS protocol amendment, but right now there isn't one.)

People arguing for BCP need to answer the following questions to the 
satisfaction of the chairs:
Why should this document be treated differently from RFC2181?
Why is RFC2119 language not needed to beat up bad implementors/operators ?

In addition Paul needs to instruct us on:
How to "cite chapter and verse" of an omission in an RFC?

History: Before DJBDNS no implementation used more than one port for
outgoing DNS questions, after that some implementation started using
ports OTHER than 53 for outgoing questions. Early implementations of
recursive resolvers only used one and frequently predictable port for
outgoing queries.

<chair-hat=off>
Unless the document is listed as one of the many ones that updates
RFC103x implementors that do not follow what happens in the IETF
will not pay attention to this document.
<chair-hat=on>

Lets spend less hot air on the status of the document and more effort on
improving it, this is an important document.

         Olafur

---

From: Paul Vixie <[email-masked]>
Date: Tue, 01 Jul 2008 02:41:23 +0000

> How to "cite chapter and verse" of an omission in an RFC?

good question.  let's get george's document finished so we have something
we can update when we want to tell implementors that the protocol is changed.

> recursive resolvers only used one and frequently predictable port for

that's not, by itself, a protocol issue.  complete interoperability does
not depend on the use of multiple ports.  from an ietf terminology point
of view, the use of multiple ports is a recommended solution to a security
problem which might also have other solutions.

> will not pay attention to this document.

the hotel rooms and coffee houses and corporate firewalls who intercept
my UDP/53 packets and send me back self-serving gibberish aren't following
RFC 1034 and i'm betting that a proscriptive "must carry clear channel DNS"
RFC which was on the standards track and which explicitly updated RFC 1034
would have no effect on the sales of the underlying devices.

> improving it, this is an important document.

with the language i proposed as a mostly-replacement for section 9, this
document could be on the standards track.  and if you want to say that it
updates RFC 1034 even though it doesn't really, then that's fine by me.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 01 Jul 2008 13:41:43 +1000

> recursive resolvers only used one and frequently predictable port for

BIND 8.
8.1          (vixie    08-Jan-99):      {"query-source", T_QUERY_SOURCE},

>From djbdns-1.05/CHANGES

19991129
        version: dnscache 0.50, alpha. not released yet.
19991223
        version: dnscache 0.60, alpha.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Jelte Jansen <[email-masked]>
Date: Tue, 01 Jul 2008 10:30:55 +0200

> Why should this document be treated differently from RFC2181?

2181 had actual interoperability changes.

> Why is RFC2119 language not needed to beat up bad implementors/operators ?

Because it is not necessary for you to implement this to make it work
with my software.

"You don't HAVE TO implement it, you're just really really stupid if you
don't."

This document somehow reminds me more of BCP38 than RFC2181, but
apparently i'm the only one :)

> will not pay attention to this document.

Hmm. One would almost like to ask, why have BCP's in the first place?
(hurray for generalization ;) )

If you are an implementor, and want to be a good boy, but are only using
the 'updates' links to see what you should do you are going to be
missing out on more than just forgery resilience. That mechanism
shouldn't be used just to get attention to the doc.

> improving it, this is an important document.

We do agree there

Jelte