Subject: [DNSOP] Should root-servers.net be signed

From: "George Barwood" <[email-masked]>
Date: Sun, 7 Mar 2010 08:06:20 -0000

I have been wondering about this.

For a resolver behind a NAT firewall that removes port randomization,
it is possible for an attacker to spoof the priming query ( only 16 bits of
ID protection ).

If root-servers.net is unsigned, it's not possible for the resolver to validate
the set of root IP addresses, meaning that

(a) An attacker can control every unsigned zone.

(b) An attacker can monitor every request to a signed zone ( no privacy ).

(c) An attacker can deny service to any zone, on a selective basis.

Apparently there are currently no plans to sign root-servers.net

The main argument against seems to be that the priming query
response size (with DO=1) would be greatly increased.

Any thoughts?

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 07 Mar 2010 18:21:52 +0900

> For a resolver behind a NAT firewall that removes port randomization,

You should also assume that the firewall traps all the packets to
port 53.

> it is possible for an attacker to spoof the priming query (only
> 16 bits of ID protection ).

Yes, it is possible even with signed root, because the client can't
directly ask name servers and must just rely on the firewall.

So, the answer is that root servers should not be signed, because
signing is useless.

						Masataka Ohta

---

From: Jim Reid <[email-masked]>
Date: Sun, 7 Mar 2010 10:20:17 +0000

On 7 Mar 2010, at 08:06, George Barwood wrote:

> the set of root IP addresses

So what? If the served zones are signed, it simply doesn't matter if  
the address of a name server is spoofed or hijacked. The Bad Guy won't  
have the private keys, so will be unable to return answers which  
validate. In the context of a referral from the root, what matters is  
the signature over the TLD's RRset (and its KSKs), not the IP address  
of the root server or any signature that might or might not exist over  
its name.

> (c) An attacker can deny service to any zone, on a selective basis.

It's not clear what point you're making or what your concerns are.  
None of these things listed above are remotely relevant. Apart from  
(a) which is hardly news: zones can be spoofed if they're not signed.  
[What next? Can we expect revelations about what bears do in the  
woods?] Privacy -- whatever that might mean -- has never been a design  
goal of DNS. Or Secure DNS for that matter. An eavesdropper can  
monitor *any* DNS request (signed or not) if they're close enough to  
the client or server. DoS attacks can and are mounted on any zone,  
whether or not they're signed. Meanwhile, in other news, water is  
discovered to be wet and fire is proven to be hot.

> Apparently there are currently no plans to sign root-servers.net

There's no point doing that IMO until .net is signed and there's a  
single chain of trust from root-servers.net to the One True Trust  
Anchor, the signed root. If the zone was to be self-signed, that would  
mean yet another TA would need to be embedded and maintained in  
validator configurations. Which creates more failure modes and scope  
for errors. And since validating the answers for root-servers.net will  
rarely if ever matter, adding that TA would be a lot of risk for  
almost no reward.

---

From: [email-masked]
Date: Sun, 7 Mar 2010 12:37:12 +0000

ah come on Jim... folsk should sign their zones as soon
 as they see fit, regardless of parental buy in.  so the
 one true root or even .net being signed doesnt really matter
 if the root-servers.net zone gets signed tomorrow.

 how useful it will be, who knows... not sure how the value 
 proposition works for ay given second or third level delegation
 beign signed.

--bill

On Sun, Mar 07, 2010 at 10:20:17AM +0000, Jim Reid wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 07 Mar 2010 21:47:02 +0900

Jim Reid wrote:

> The Bad Guy won't have the private keys,

Wrong.

While the Bad Guy as an ISP administrator won't have the private
keys, the Bad Guy as a zone administrator will have the private
keys.

That is, DNSSEC is not secure cryptographically, which is another
reason why not to deploy DNSSEC.

						Masataka Ohta

---

From: Jim Reid <[email-masked]>
Date: Sun, 7 Mar 2010 13:22:41 +0000

On 7 Mar 2010, at 12:47, Masataka Ohta wrote:

> keys, the Bad Guy as a zone administrator will have the private keys.

True, but irrelevant. The original discussion was a theoretical,  
misplaced concern about spoofed priming queries. It was not about  
whether the Bad Guy had control over the zone being spoofed. Please  
don't confuse the two.

> reason why not to deploy DNSSEC.

This claim is ridiculous. Unless someone uncovers a fundamental flaw  
in public key cryptography, DNSSEC is secure cryptographically  
provided the private key(s) remain private.

Now some people may (or may not) trust a third party to manage their  
keys and zone signing for them. That's their choice. It's just one of  
the many trade-offs that have to be considered in any sort of security  
system. For some, a private key held by a third party may well meet or  
exceed their security requirements. It takes a wild leap of the  
imagination and powerful reality distortion to use that as  
justification for the claims you made.

---

From: Jim Reid <[email-masked]>
Date: Sun, 7 Mar 2010 13:43:36 +0000

On 7 Mar 2010, at 12:37, [email-masked] wrote:

> as they see fit, regardless of parental buy in.

Bill, IMO there's not much point in signing root-servers.net until its  
parents are signed. [And as I explained earlier, signing that zone is  
highly unlikely to make any difference to the threat of spoofed  
responses to priming queries.] While folk should sign zones as they  
see fit, lack of parental buy-in is a major reason why they don't sign  
their zones. The horrors of alternate Trust Anchors should make  
everyyone think very long and hard about when to deploy DNSSEC.

This is maybe just about tolerable for a handful of TLDs. However I  
hope all this will melt away once we reached the promised land of a  
signed root this summer.

That said, I'd encourage people to put zone signing into pre- 
production so they can figure out how to update procedures and  
documentation, train ops/support staff and also get experience with  
signing tools, key rollovers and so forth. They'll then be ready to  
flick the switch come the glorious day when their parent(s) are  
signing delegations.

---

From: Joe Baptista <[email-masked]>
Date: Sun, 7 Mar 2010 08:52:30 -0500

My recommendation - upgrade your NAT.

regards
joe baptista

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 07 Mar 2010 22:55:06 +0900

> True,

Good enough.

> This claim is ridiculous. Unless someone uncovers a fundamental flaw  in 
> public key cryptography,

The fundamental flow of public key cryptography for its, wrongly
claimed, cryptographical security is that trusted third parties
are not cryptographically secure, which you have already said
"True,".

As you can see that the Bad Guy as a zone administrator will
have the private keys, there is no cryptographical security,
here.

> DNSSEC is secure cryptographically  provided 
> the private key(s) remain private.

The provision is not cryptographical.

> keys and zone signing for them. That's their choice.

Have you ever heard about such thing as monopoly?

With monopoly, consumers do not have any choice, which is the case
with DNS.

You are totally bound to "." and many are to ".com".

> It's just one of  
> exceed their security requirements.

That there are many operational trade-offs means that the security
is not cryptographic. 

						Masataka Ohta

---

From: Nicholas Weaver <[email-masked]>
Date: Sun, 7 Mar 2010 07:31:10 -0800

> reason why not to deploy DNSSEC.

I don't see what your argument here is.

DNSSEC is a "PKI in disguise", and like ANY PKI, you still depend on trust up the heirarchy, as that is exactly how a PKI is supposed to work: One level up says something about the levels down.

But DNS has ALWAYS depended on trust-up-the-heirarchy anyway, so this aspect of DNSSEC doesn't increase the level of trust required in DNS, it just only codifies it in cryptographic terms so there is no trust (that isn't made explicit) beyond the scope up the heirarchy.

This is actually why DNSSEC is useful: it IS a PKI, who's heirarchical nature already matches the existing heirarchy on naming.  In the end, signing A records is useless.  But signing TXT and CERT records will be incredibly useful, if validated on the end-host application.

Additionally, since it would be end-host application validating those signatures, it can enforce that "there must exist a signature path from the root" (aka, it is actually a PKI). [1]

But since unless you manually or do some other finagling can't easily establish trust if you don't have trust above, root-servers.net should only sign after .net is signed at this point in the rollout.  And any PROPER useage of DNSSEC won't rely on root-servers.net ever being signed at all, because its only on the name path for resolvers.

[1] Thus, you don't have to worry about also needing the name path for the resolvers signed or the DOS attack by a MitM stripping signatures as part of their changing DNS results.

---

From: "George Barwood" <[email-masked]>
Date: Sun, 7 Mar 2010 15:57:30 -0000

----- Original Message ----- 
From: "Jim Reid" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, March 07, 2010 10:20 AM
Subject: Re: [DNSOP] Should root-servers.net be signed

> woods?] 

Prevention of spoofing is a goal of DNSSEC.
However, if a zone ( such as root-servers.net ) is not signed, spoofing is not prevented.
This has negative consequences, and weakens the protection that DNSSEC offers.

> Privacy -- whatever that might mean -- has never been a design  
> the client or server. 

Yes, but I'm talking about blind spoofing attacks, where a single successful spoof
results in the attacker gaining a lot, and which can be stopped by signing root-server.net

> DoS attacks can and are mounted on any zone,  

> Anchor, the signed root. 

I hadn't considered that. The dependency on .net is perhaps a little odd.
A more logical set of name server names might be simply

a.root-servers
b.root-servers
..
k.root-servers

so that the dependency is removed. There may be objections to this.

> If the zone was to be self-signed, that would  

I agree that there is little point in signing root-servers if it can not
be validated without configuring a special trust anchor.
Of course another solution to that is to sign .net

-- George

---

From: [email-masked]
Date: Sun, 7 Mar 2010 17:10:15 +0000

> everyyone think very long and hard about when to deploy DNSSEC.

	and you think this is the primary reason to sign/not sign?
	i suspect that the real reason to sign early/often is actuall
	enumerated below.
 
> hope all this will melt away once we reached the promised land of a  
	
	signed root nirvana anint going to happen.

> flick the switch come the glorious day when their parent(s) are  

	bingo.  thats the reason to sign now, irrespective
	of some laggard parent.

--bill

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 08 Mar 2010 04:03:00 +0900

> DNSSEC is a "PKI in disguise", and like ANY PKI, you still depend
> on trust up the heirarchy,

Yes, you do understand the problem.

> But DNS has ALWAYS depended on trust-up-the-heirarchy anyway,
> so this aspect of DNSSEC doesn't increase the level of trust
> required in DNS,

The problem is that DNSSEC was wrongly advertised to increase
the level of security.

The reality, however, is that ISPs are as secure/reliable/trustable
as zones, which means DNSSEC does not increase the level of security.

> it IS a PKI

PKI is broken, of course. So?

> Additionally, since it would be end-host application validating
> those signatures, it can enforce that "there must exist a
> signature path from the root" (aka, it is actually a PKI). [1]

The meaningful security for end hosts is that the security is
broken only if one of the end hosts is compromised, which means
fate sharing, whereas, with DNSSEC, end hosts can do nothing if
intermediate zones are compromised.

> [1] Thus, you don't have to worry about also needing the name
> path for the resolvers signed or the DOS attack by a MitM
> stripping signatures as part of their changing DNS results.

MitM of a zone chain can easily change DNS results.

						Masataka Ohta

---

From: Jay Daley <[email-masked]>
Date: Mon, 8 Mar 2010 09:08:18 +1300

> The problem is that DNSSEC was wrongly advertised to increase

I think you are picking your own definition of security to suit your argument.  Those promoting DNSSEC have only ever said that the "security" it provides is basic validation of a) message originator and b) message integrity.

> as zones, which means DNSSEC does not increase the level of security.

I don't understand what that means.  Are you suggesting that DNSSEC should have some how dealt with insecure/unreliable/untrustworthy ISPs?

> PKI is broken, of course. So?

That is a bit like saying that all cars are broken because of a few problems Toyota are having.  In other words it is a totally unsupported generalisation. 

> intermediate zones are compromised.

DNS is largely asymmetric.  On the whole I produce, others consume.  So why would I need to fate-share with any consumer of my DNS messages?  Your vision of security is for something quite different.

Is this the essence of your grievance - DNSSEC has a chain of trust so any zone operator is dependent on another, thereby making a zone operator vulnerable to bad actors amongst those they depend on?

If so then please explain how you can reliably get keys for my zones 
1.  without a relying on others in a chain of trust
2.  in a way that scales

kind regards
Jay

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

---

From: Nicholas Weaver <[email-masked]>
Date: Sun, 7 Mar 2010 13:47:56 -0800

> as zones, which means DNSSEC does not increase the level of security.

IF you use DNSSEC for A records, I agree with you completely.  Simply put because either the end application never trusted DNS OR is trivially p0wned by a MitM.

IF you use DNSSEC for TXT and CERT records, its a very different story.  Existing PKIs have too MANY paths of trust, and path of trust which is disjoint from the name heirarchy.  By uniting these and REDUCING the paths of trust, you end up with a better system.

And PKI, dispite what you say, is not broken.  Heirarchical trust OR web of trust, you have to have some transitive trust to make a usable system.

---

From: "George Barwood" <[email-masked]>
Date: Sun, 7 Mar 2010 23:08:31 -0000

> But since unless you manually or do some other finagling can't easily establish trust if you don't have trust above, root-servers.net should only sign after .net is signed at this point in the rollout.

The dependency on .net for the root name servers seems strange to me.

Intuitively, I should not have to trust .net to get a validated set of root name servers.

The names of the root name servers are somewhat arbitrary, and since they are very integral to the
root zone, it would seem more straight-forward to not put them into a public registry TLD, but rather
to use a special TLD ( e.g. "root-servers" or possibly a sub-domain of ARPA ). I don't see any
reason to use a sub-zone, the records may as well go in the root I think ( allows a secure resolver
to start up slightly faster ).

> And any PROPER useage of DNSSEC won't rely on root-servers.net ever being signed at all, because its only on the name path for resolvers.

I think a proper use of DNSSEC is to use it to get a validated set of root server IP addresses.

This doesn't cure all the security ills of the world, but does constitute a small improvement in security,
especially for TLDs that have not yet been signed.

If TLDs also do not sign their name server domains, then a single blind spoof packet allows
an attacker to intercept all the traffic for a resolver. Even the root server traffic is somewhat
sensitive - it can often be what some end-user has just typed, which could well be confidential,
such as a password ( e.g. they think they are entering a password, but are actually typing into an address bar ).

Sure, it doesn't allow an attacker to forge signatures - but that's not the be-all and end-all of security.

I note that .se does sign it's name servers.

---

From: Chris Thompson <[email-masked]>
Date: 08 Mar 2010 00:09:28 +0000

On Mar 7 2010, George Barwood wrote:

>The names of the root name servers are somewhat arbitrary, and since
>they are very integral to the root zone, it would seem more straight-
<forward to not put them into a public registry TLD, but rather to use
>a special TLD ( e.g. "root-servers" or possibly a sub-domain of ARPA ).
>I don't see any reason to use a sub-zone, the records may as well go
>in the root I think ( allows a secure resolver to start up slightly
>faster ).

I have a lot of sympathy with that PoV.

It's notable that draft-jabley-reverse-servers intends to put
nameservers for the "arpa" sub-domains in matching sub-domains 
of "arpa" (but still seems to mandate more zone cuts than seem 
advisable to me).

>I note that .se does sign it's name servers.

And indeed ns.se is in the se zone (no zone cut). But the consequence
is that a DO=1 "priming" query for "se" returns 2706 bytes while one for
"." from the (DURZ-signed) root servers returns only 801 bytes.

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: Jim Reid <[email-masked]>
Date: Mon, 8 Mar 2010 00:12:29 +0000

> I note that .se does sign it's name servers.

That's because the .se name servers live in the .se zone. Unlike the  
root servers which don't live in the root zone.

---

From: Jim Reid <[email-masked]>
Date: Mon, 8 Mar 2010 00:37:51 +0000

On 7 Mar 2010, at 23:08, George Barwood wrote:

>> But since unless you manually or do some other finagling can't  
>> easily establish trust if you don't have trust above, root- 
>> servers.net should only sign after .net is signed at this point in  
>> the rollout.
>

Get over it.

> Intuitively, I should not have to trust .net to get a validated set  

You only need to trust the signatures over the signed delegations from  
root servers, not the signatures (if any) over the address records for  
the zone's name servers. This has been explained to you already.  
Spoofed IP addresses for the root's name servers -- either through DNS  
or evil routing trickery -- won't matter once the zone is signed for  
real. An impostor won't be able to sign their bogus root zone because  
they won't have access to the actual keys. Anything for the root  
that's returned from these spoofed addresses simply won't validate.

> This doesn't cure all the security ills of the world, but does  
> constitute a small improvement in security, especially for TLDs that  
> have not yet been signed.

Nope. If some TLD isn't signed it can be spoofed regardless of whether  
or not the root (or root-servers.net) is signed. The same is true for  
any unsigned zone that lives user a trust anchor which is used for  
validation.

> If TLDs also do not sign their name server domains, then a single  
> blind spoof packet allows an attacker to intercept all the traffic  
> for a resolver.

Yawn. That's still true whether or not root-servers.net is signed and  
the resolver validates that zone's signatures. Or if the zone isn't  
signed. See above.

> Even the root server traffic is somewhat sensitive - it can often be  
> what some end-user has just typed, which could well be confidential,  
> such as a password ( e.g. they think they are entering a password,  
> but are actually typing into an address bar ).

So don't do that. Duh!

What point are you trying to make here or ascribe to the use or non- 
use of DNSSEC? If people put crap in their DNS queries, that crap will  
more than likely get presented to external name servers. DNSSEC is not  
and never has been about confidentiality. Either of DNS data or  
queries. If fail to see how stupid end user behaviour with web  
browsers that leaks sensitivie data can have anything to do with  
DNSSEC deployment at all. Or why you raise this non-issue on this list.

---

From: Jim Reid <[email-masked]>
Date: Mon, 8 Mar 2010 00:58:10 +0000

On 8 Mar 2010, at 00:09, Chris Thompson wrote:

> nameservers for the "arpa" sub-domains in matching sub-domains of  
> "arpa" (but still seems to mandate more zone cuts than seem  
> advisable to me).

Most important TLDs are moving towards in-bailiwick targets for their  
NS records and accompanying address records. Or have already done so.  
One of the main reasons is to reduce latency and sysqueries. The  
referral response returns all the info and the resolver doesn't need  
to resolve the address of ns.whatever.othertld in order to get to the  
name server(s) it next wants to query.

The root servers indirectly achieve the same result because they all  
serve root-servers.net. IIRC the reasons for not putting the names of  
the root servers into the root zone were down to complications in the  
database/systems which were used to generate the root zone ~15 years  
ago. This would have been around the time when the names of the  
servers got rationalised. Making that change today would generate a  
bazillion layer-9 problems. These are best avoided because a tidy-up  
of root server names would get caught up in the maelstrom of new  
gTLDs, IDN ccTLDs, root signing and IPv6 which is keeping everyone  
more than busy.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 08 Mar 2010 11:34:42 +0900

Jay Daley wrote:

> I think you are picking your own definition of security to suit
> your argument.

>>as zones, which means DNSSEC does not increase the level of security.

feel free to deny me. Otherwise, accept the reality.

> Are you suggesting that DNSSEC should have some how dealt with
> insecure/unreliable/untrustworthy ISPs?

DNS is dealt with zones as insecure/unreliable/untrustworthy as ISPs.

> DNS is largely asymmetric.  On the whole I produce, others consume.
> So why would I need to fate-share with any consumer of my DNS
> messages?

DNS?

Fate sharing security is required for applicaitons running on
end hosts. DNS security itself is abstract and is no goal.

> 1.  without a relying on others in a chain of trust

I can't, which is why DNSSEC is as insecure as plain DNS.

> 2.  in a way that scales

It seems to me that cryptographic, end to end, or fate sharing
security is not scalable.

						Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Mon, 08 Mar 2010 13:50:48 +1100

> DNS is dealt with zones as insecure/unreliable/untrustworthy as ISPs.

There is plenty of evidence for ISPs modifying DNS responses to
queries directed to their recursive servers without notifying the
client population before doing so.

There are also reports of ISPs modifying DNS responses not directed
to their recursive servers.  If you wish to include hotels in the
ISP category (which they are for the duration of your stay at the hotel)
then there is ample evidence of this happening.

So yes I don't trust ISPs.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 08 Mar 2010 12:06:01 +0900

Nicholas Weaver wrote:

> And PKI, dispite what you say, is not broken.  Heirarchical trust
> OR web of trust, you have to have some transitive trust to make
> a usable system.

As the Internet (and telco net, too, which has been used for
more than 100 years with moderate security) is the hierarchical
trust OR the web of trust, to which PKI adds nothing, which is
how PKI is broken.

> you have to have some transitive trust to make a usable system.

Sure. We already have the transitive trust between ISPs of the
Internet and plain old DNS is the usable system.

DNSSEC adds nothing to it.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 08 Mar 2010 13:34:13 +0900

> then there is ample evidence of this happening.

Are you saying the ISPs and the hotel are phishing their customers?

Or, are you just saying DNSSEC can not be used by customers of the
ISPs and the hotel?

> So yes I don't trust ISPs.

For doing (or not doing) what?

I don't think ilegally behaving ISPs can continue thier business.

						Masataka Ohta

---

From: Florian Weimer <[email-masked]>
Date: Mon, 08 Mar 2010 12:38:48 +0000

* Jim Reid:

> the address of a name server is spoofed or hijacked.

This is only true if the whole DNS tree is signed (and if you don't
value query privacy).

-- 
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: Joe Abley <[email-masked]>
Date: Mon, 8 Mar 2010 09:38:50 -0500

> I have been wondering about this.

Our[*] reasoning so far with respect to signing ROOT-SERVERS.NET can I think be paraphrased as follows:

- if we sign ROOT-SERVERS.NET it will trigger large responses (the RRSIGs over the A and AAAA RRSets) which is a potential disadvantage
- if we do not sign ROOT-SERVERS.NET there is a threat that the unsigned A and AAAA RRSets from ROOT-SERVERS.NET might be spoofed somehow and that the spoofing will be undetected
- however, since the root zone is signed, validators can already tell when they are talking to a root server that serves bogus information
- signing ROOT-SERVERS.NET would result in potentially-harmful large responses with no increase in security
- let's not do that then

I also find Jim's point regarding NET rather compelling. If the NET zone is not signed, then validating responses from a signed ROOT-SERVERS.NET zone would require yet another trust anchor to be manually-configured.

It's hard for me to agree that the aggregate operational complexity involved in those manual trust anchors, and the potential effects of a KSK-roll without synchronised updating of that static configuration, represents a smaller risk than leaving the zone unsigned, at least for now.

If this logic is faulty then I'd love to hear about it.

Joe

[*] I say "our", but really I mean my personal recollection of conversations with other members of the root-signing design team some time ago, which I haven't cross-checked with anybody before hitting send.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 8 Mar 2010 10:27:29 -0500 (EST)

> - if we sign ROOT-SERVERS.NET it will trigger large responses (the RRSIGs over the A and AAAA RRSets) which is a potential disadvantage

Is it? Is DNSSEC that bad then? Why did we design it that way?

> - however, since the root zone is signed, validators can already tell when they are talking to a root server that serves bogus information

How does that work without ROOT-SERVERS.NET being signed with a known trust anchor?
How does my validating laptop know that the curent wifi is not spoofing a.ROOT-SERVERS.NET to some local IP?

> - signing ROOT-SERVERS.NET would result in potentially-harmful large responses with no increase in security

If it is harmful, we should abandon DNSSEC?

> If this logic is faulty then I'd love to hear about it.

I agree about the trust anchor issue. Not so much with some of the statements above it.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 8 Mar 2010 07:29:27 -0800

>I also find Jim's point regarding NET rather compelling. If the NET zone is not signed, then validating responses from a signed ROOT-SERVERS.NET zone would require yet another trust anchor to be man…

...and to manually be removed in the future when the keys for root-servers.net are rolled. For bonus points, imagine the consequences of that happening after .net is signed.

This list is DNSOP, not DNSEXT: we are tasked with thinking about the operational aspects of both doing and undoing a particular action, and the effects on the DNS for when that doing and undoing happens incorrectly.

--Paul Hoffman, Director
--VPN Consortium

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 8 Mar 2010 07:48:52 -0800

> How does my validating laptop know that the curent wifi is not spoofing a.ROOT-SERVERS.NET to some local IP?

If your ISP is acting as a MitM on DNS, its acting as a MitM on everything, so DNSSEC buys you f-all if you are using it for A records, because any app using that A record either doesn't trust the net or is trivially p0owned by the ISP.

DNSSEC is ONLY useful for things like TXT and CERT records fetched by a DNSSEC aware cryptographic application, and that would require a valid signature chain from the root(s) of trust (either preconfigured or on a path from the signed root) validated on the client, so an imitation a.root-servers.net won't matter, as it won't be able to provide improper data.

So in your example, root-servers.net doesn't need to be signed, and buys no increase in trust WHETHER IT IS SIGNED OR NOT, because even if it IS signed, that coveys no value about the results returned from it, because the signatures are not along the trust heirarchy for DNSSEC, which follows the name path, not the lookup path.

Remember, DNSSEC is a PKI, with only one path of trust which matches the name path (so, for *.foo.bar.com, the trust path is foo.bar.com, bar.com, .com, ., either to a signed root, a signed TLD, or a trust anchor configured for either bar.com or foo.bar.com) [1].  You MUST be able to validate along the path (the transitive trust of a PKI), but you ONLY need to validate along the path (the limited trust of a PKI).

Thus although root-servers.net is a domain involved in the resolution of anything for *.foo.bar.com (its on the resolution path), it is not on the trust path, so whether it is signed or not has no impact on whether the chain up will validate cryptographically.

QED:  Signing root-servers.net should be done for completeness, but only AFTER .net is signed, because really, its a signature path that doesn't actually matter and SHOULDN'T actually be validated for normal lookups [2], but only when the values are directly requested by a cilent!

[1] And this is why I want DNSSEC: it IS a PKI and should be used as such, but one with a much cleaner trust path than the SSL-model PKI, and without adding any NEW trust paths to the system as this is the same trust path needed for normal DNS.

[2] I really don't like DNSSEC's reliance on the recursive resolver to do signature validations, because there really is no right answer for what the recursive resolver should do on cryptographic failures (contrast with the client where there are good answers).  

But if the recursive resolver IS validating DNSSEC, it MUST ONLY validate the path of trust for the names requested by the client, simply to minimize spurious and irrelevant cryptographic failures.  If the recursive resolver is validating the signatures of root-servers.net for internal use, it is doing it wrong: something which reduces reliability but doesn't increase security.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 8 Mar 2010 11:00:11 -0500 (EST)

> If your ISP is acting as a MitM on DNS, its acting as a MitM on everything, so DNSSEC buys you f-all if you are using it for A records, because any app using that A record either doesn't trust the…

If I detect an in-path attacker, I can choose to disconnect from that network.
That is not "buying f-all". It's useful to know when you are under attack.

> DNSSEC is ONLY useful for things like TXT and CERT records fetched by a DNSSEC aware cryptographic application, and that would require a valid signature chain from the root(s) of trust (either prec…

I understand that :P

> So in your example, root-servers.net doesn't need to be signed, and buys no increase in trust WHETHER IT IS SIGNED OR NOT, because even if it IS signed, that coveys no value about the results retur…

If it was signed (along with .net) or via DLV or manual trust anchor, again
I could tell I am under attack and disconnect from the rogue network. There
is a use for that.

Though I agree with people who say this is better done when a full path of
trust from the root down is in place to avoid more manual configuration.

> [1] And this is why I want DNSSEC: it IS a PKI and should be used as such, but one with a much cleaner trust path than the SSL-model PKI, and without adding any NEW trust paths to the system as thi…

No need to preach to the choir. We were the ones (ab)using KEY records for
IPSEC-OE.

> [2] I really don't like DNSSEC's reliance on the recursive resolver to do signature validations, because there really is no right answer for what the recursive resolver should do on cryptographic f…

That problem never goes away, see how browsers handle cert failures....

> But if the recursive resolver IS validating DNSSEC, it MUST ONLY validate the path of trust for the names requested by the client, simply to minimize spurious and irrelevant cryptographic failures.…

I don't agree with your "in path" view. If I need to validate a nameserver
ns.foo.bar., then yes it needs to attempt to validate the path "." ->
"bar." -> "foo.bar." -> "ns.foo.bar.". Or instead of "validate", at
least needs to confirm "not verifiably bogus" in the absense of DNSSEC
for certain parts if the tree.

Paul

---

From: Tony Finch <[email-masked]>
Date: Mon, 8 Mar 2010 16:18:49 +0000

> responses with no increase in security

Can't you deal with this by omitting the root-servers.net RRSIGs from the
additional section of responses to queries to the root?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: Joe Abley <[email-masked]>
Date: Mon, 8 Mar 2010 11:21:22 -0500

> Is it? Is DNSSEC that bad then? Why did we design it that way?

Practice with ORG and SE and CZ and other TLDs suggests that the harm is marginal. However, there's an argument that root servers have to worry about the effect of priming queries on a different client base, and hence perhaps some care is warranted.

Note that I said "potential disadvantage". I make no prediction as to whether there winds up being any discernible harm.

> How does that work without ROOT-SERVERS.NET being signed with a known trust anchor?

Because validators are equipped with a trust anchor for the root zone's KSK.

An unsigned ROOT-SERVERS.NET might leave validators talking to a bogus root server, but they won't believe any of the signed replies they get from it.

> How does my validating laptop know that the curent wifi is not spoofing a.ROOT-SERVERS.NET to some local IP?

I would suggest that your validating laptop doesn't care. The only reason people care about root servers is so that they can be pointed to servers which have the answers they want. End users don't typically seek answers which can be found solely in the ROOT-SERVERS.NET zone).

Joe

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 8 Mar 2010 08:21:41 -0800

> That is not "buying f-all". It's useful to know when you are under attack.

Except the attacker doesn't have to mess with a.root-server.net at all, as they can MitM the final application traffic just fine, and that final application either didn't trust the A record (so who cares if its tampered with), or gets 0wned by the MitM, so why bother at all?

So for A records against a MitM, the signature for root-servers.net is irrelevant.

For DNSSEC validation, this is irrelevant too: Either the final resolution MUST have a valid chain from the root of trust to the final value, OR there must be an NSEC record showing where the DNSSEC data ends.  A bogus a.root-servers.net record won't affect this.

>> DNSSEC is ONLY useful for things like TXT and CERT records fetched by a DNSSEC aware cryptographic application, and that would require a valid signature chain from the root(s) of trust (either pre…

And in THAT case, the a.root-servers.net name doesn't matter either, because it is the signature chain for the TXT or CERT record that is validated.  So for records validated on a client application, the signature for root-servers.net is irrelevant.

So in either case, when your adversary is a MitM, the signature for root-servers.net is irrelevant: it is not validated and gains no BENEFIT from validation.

Especially since the MitM can simply return bogus values from the REAL a.root-servers.net, and thats no different behaviorally.

> That problem never goes away, see how browsers handle cert failures....

Except that for the client there actually IS a good answer:

For the default, existing APIs (gethostbyname etc): conduct an iterative query from the root and use that value, for ANY signature or cryptographic failure, as the application using the API either is also trivially vulnerable to a MitM or doesn't really trust the record.

For enhanced DNSSEC APIs: return the error to the client which, because its DNSSEC aware, should 'know what to do', or at least kick the problem to an application which may have a hope of doing something right.

There is no such "good default answer" for the recursive resolver.

> for certain parts if the tree.

NSEC is about provable denial of DNSSEC information amongst anything else, no?  

So the path from your trust anchors must either be complete and validate OR have an NSEC record corresponding to the break.  In either case, validating the name server's record for internal use doesn't affect the security of this chain.

But it CAN add additional failure modes.  DNSSEC MUST NOT significantly reduce the reliability of DNS, or the blowback will be extreme.  

And needlessly validating things that don't need to be validated CAN NOT increase security in the face of a man-in-the-middle (its not on the cryptographic trust path, and it is the cryptographic path that needs to be validated) but MUST reduce reliability.

---

From: Joe Abley <[email-masked]>
Date: Mon, 8 Mar 2010 11:22:13 -0500

> additional section of responses to queries to the root?

Are you suggesting that we implement a coordinated code change to all root servers in the name of security or stability?

Diversity in operation and code base is usually thought to be a strength of the root server system.

Joe

---

From: Thierry Moreau <[email-masked]>
Date: Mon, 08 Mar 2010 12:31:22 -0500

> An unsigned ROOT-SERVERS.NET might leave validators talking to a bogus root server, but they won't believe any of the signed replies they get from it.

That is a narrow view of what a bogus root server may do. It may also 
replicate every official root signatures (basically signed delegations) 
and spoof unsigned delegations.

Your enemy may make a bogus signed TLD nameserver with the same strategy 
so that unsigned delegations to SLD can also be spoofed.

If DNSSEC usage includes validation of A/AAAA, then signed A/AAAA for 
nameservers at the root and TLD seem to provide some (arguably marginal 
but not null) integrity assurance for unsigned domains.

That's just an observation on the above reasoning. A full pros and cons 
analysis is obviously more encompassing.

Regards,

-- 
- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1

Tel. +1-514-385-5691

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 8 Mar 2010 09:22:28 -0800

On Mar 8, 2010, at 9:31 AM, Thierry Moreau wrote:

> That is a narrow view of what a bogus root server may do. It may also replicate every official root signatures (basically signed delegations) and spoof unsigned delegations.
> 
> Your enemy may make a bogus signed TLD nameserver with the same strategy so that unsigned delegations to SLD can also be spoofed.
> 
> If DNSSEC usage includes validation of A/AAAA, then signed A/AAAA for nameservers at the root and TLD seem to provide some (arguably marginal but not null) integrity assurance for unsigned domains.
> 
> That's just an observation on the above reasoning. A full pros and cons analysis is obviously more encompassing.

But in order to BECOME the bogus nameserver, the attacker is becoming a MitM, so the attacker can just directly spoof any non-valid reply, they don't need to spoof the reply to become the bogus nameserver, but the unsigned replies directly.

---

From: Tony Finch <[email-masked]>
Date: Mon, 8 Mar 2010 19:35:29 +0000

On Mon, 8 Mar 2010, Joe Abley wrote:
> Are you suggesting that we implement a coordinated code change to all
> root servers in the name of security or stability?

I suppose it was more a protocol / implementation question, along the
lines of BIND's minimal-responses option.

> of the root server system.

Yes, but I'm not sure how that has any bearing on the question.

Tony.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 09 Mar 2010 07:33:44 +1100

In message <[email-masked]>, Nicholas W
eaver writes:
> >> - if we sign ROOT-SERVERS.NET it will trigger large responses (the RRSIGs 
> over the A and AAAA RRSets) which is a potential disadvantage
> > 
> >> - however, since the root zone is signed, validators can already tell when
>  they are talking to a root server that serves bogus information
> > 
> If your ISP is acting as a MitM on DNS, its acting as a MitM on everything, s
> o DNSSEC buys you f-all if you are using it for A records, because any app us
> ing that A record either doesn't trust the net or is trivially p0owned by the
>  ISP.

Which is not true and you should know it.  RBL's depend on accurate
transmission of A records to work reliably.
 
> DNSSEC is ONLY useful for things like TXT and CERT records fetched by a DNSSE
> C aware cryptographic application, and that would require a valid signature c
> hain from the root(s) of trust (either preconfigured or on a path from the si
> gned root) validated on the client, so an imitation a.root-servers.net won't 
> matter, as it won't be able to provide improper data.

and MX and SRV and ...

Yes there are many applications where you have multiple vectors to attack
them over, however that does not justify leaving a attack vector open.

> So in your example, root-servers.net doesn't need to be signed, and buys no i
> ncrease in trust WHETHER IT IS SIGNED OR NOT, because even if it IS signed, t
> hat coveys no value about the results returned from it, because the signature
> s are not along the trust heirarchy for DNSSEC, which follows the name path, 
> not the lookup path.
> 
> 
> 
> Remember, DNSSEC is a PKI, with only one path of trust which matches the name
>  path (so, for *.foo.bar.com, the trust path is foo.bar.com, bar.com, .com, .
> , either to a signed root, a signed TLD, or a trust anchor configured for eit
> her bar.com or foo.bar.com) [1].  You MUST be able to validate along the path
>  (the transitive trust of a PKI), but you ONLY need to validate along the pat
> h (the limited trust of a PKI).
> 
> Thus although root-servers.net is a domain involved in the resolution of anyt
> hing for *.foo.bar.com (its on the resolution path), it is not on the trust p
> ath, so whether it is signed or not has no impact on whether the chain up wil
> l validate cryptographically.
> 
> 
> 
> QED:  Signing root-servers.net should be done for completeness, but only AFTE
> R .net is signed, because really, its a signature path that doesn't actually 
> matter and SHOULDN'T actually be validated for normal lookups [2], but only w
> hen the values are directly requested by a cilent!
> 
> 
> 
> [1] And this is why I want DNSSEC: it IS a PKI and should be used as such, bu
> t one with a much cleaner trust path than the SSL-model PKI, and without addi
> ng any NEW trust paths to the system as this is the same trust path needed fo
> r normal DNS.
> 
> [2] I really don't like DNSSEC's reliance on the recursive resolver to do sig
> nature validations, because there really is no right answer for what the recu
> rsive resolver should do on cryptographic failures (contrast with the client 
> where there are good answers).  
> 
> But if the recursive resolver IS validating DNSSEC, it MUST ONLY validate the
> path of trust for the names requested by the client, simply to minimize spur
> ious and irrelevant cryptographic failures.  If the recursive resolver is val
> idating the signatures of root-servers.net for internal use, it is doing it w
> rong: something which reduces reliability but doesn't increase security.
> 
>

---

From: "George Barwood" <[email-masked]>
Date: Mon, 8 Mar 2010 22:08:12 -0000

----- Original Message ----- 
From: "Joe Abley" <[email-masked]>
To: "Tony Finch" <[email-masked]>
Cc: "George Barwood" <[email-masked]>; <[email-masked]>
Sent: Monday, March 08, 2010 4:22 PM
Subject: Re: [DNSOP] Should root-servers.net be signed

> Diversity in operation and code base is usually thought to be a strength of the root server system.

It's interesting to note that currently

dig any . @a.root-servers.net +dnssec

truncates, leading to TCP fallback

but

dig any . @l.root-servers.net +dnssec

does not truncate ( response size is 1906 bytes ).

George

---

From: Mark Andrews <[email-masked]>
Date: Tue, 09 Mar 2010 10:35:52 +1100

In message <43FC3F50679F458A869F99D72ECD1237@localhost>, "George Barwood" write
s:
> > Are you suggesting that we implement a coordinated code change to all root 
> servers in the name of security or stability?
> 

A.ROOT-SERVERS.NET would appeared to be configured to not send DNS
responses that will result in fragmentation leading to a artificially
higher TCP load.  For named max-udp-size is what controls this.

Mark

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 09 Mar 2010 08:37:49 +0900

Nicholas Weaver wrote:

> DNSSEC is ONLY useful for things like TXT and CERT records fetched
> by a DNSSEC aware cryptographic application, and that would
> require a valid signature chain from the root(s) of trust
> (either preconfigured or on a path from the signed root) validated
> on the client, so an imitation a.root-servers.net won't matter, as
> it won't be able to provide improper data.

DNSSEC is still not useful, because attackers can pretend that retail
ISPs can't pass DNSSEC packets.

Then, there is a choice of:

	1) not to use the net with untrustworthy zones and ISPs

	2) to use the net even with untrustworthy zones and ISPs

and most people will use the net anyway.

Note that DNSSEC dose not make untrustworthy zones trustable.

						Masataka Ohta

---

From: Joe Abley <[email-masked]>
Date: Mon, 8 Mar 2010 18:37:45 -0500

> does not truncate ( response size is 1906 bytes ).

A runs BIND9, as far as I know. L runs NSD 3.2.4. Different implementations behave differently.

Joe

---

From: Mark Andrews <[email-masked]>
Date: Tue, 09 Mar 2010 11:00:07 +1100

In message <[email-masked]>, Joe Abley writes
> A runs BIND9, as far as I know. L runs NSD 3.2.4. Different implementations b

Configured differently.  By default max-udp-size is 4096.  Yes there
are differences but this is not one.  Even the very oldest BIND9's
support a max-udp-size of 2048.  If A is running named then this is
a deliberate configuration choice.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Tue, 09 Mar 2010 11:59:11 +0100

Hi Tony, Joe,

> lines of BIND's minimal-responses option.

It is not a code change for NSD.  The RRSIGs of root-servers.net would
not be present in replies for the root.  E.g. in the prime response.

>> of the root server system.
+1 ; here exposing a subtle (interpretation?) difference.

Also +1 for the consensus analysis about signing: not on the path of
trust but still somewhat useful to do, but not add another TA for it.

Best regards,
   Wouter

---

From: Matt Larson <[email-masked]>
Date: Tue, 9 Mar 2010 09:53:53 -0500

> trust but still somewhat useful to do, but not add another TA for it.

I have not seen any consensus emerge one way or another regarding
signing root-servers.net.

Even after .net is signed (in Q4 2010), I don't believe it's a given
that root-servers.net should be signed.  There is definitely a
trade-off between increased response size and the incremental benefits
of signing that needs to be weighed and evaluated.  The answer is not
obvious (to me, anyway).  Personally, I currently lean against signing
it.

Matt

---

From: Matt Larson <[email-masked]>
Date: Tue, 9 Mar 2010 10:17:26 -0500

> does not truncate ( response size is 1906 bytes ).

a.root-servers.net's six anycast instances currently all run BIND 9
configured with "max-udp-size 1472" to avoid sending responses larger
than the Ethernet MTU.  This was a conscious conservative choice and
the infrastructure is capable of handling the resulting increased TCP
load.

It's worth noting that common queries with +DO for types at the root
node produce smaller results that do not result in +TC truncation:
./IN/NS is 801 bytes and ./IN/DNSKEY is 736 bytes.  ./IN/ANY is a
diagnostic outlier.

Matt

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 9 Mar 2010 07:31:32 -0800

> the infrastructure is capable of handling the resulting increased TCP

I'd set it at 1450 personally, because you do have some encapulation over ethernets (eg, PPPoE, IPSEC) which occur, so if the goal is "almost guarenteed no fragments", you need to leave a little additional headroom.

But given the current observed difficulty that resolvers have with fragments, this is, IMO, a very good decision.

I hate the idea of enshrining the "resolvers can't handle fragments" into the infrastructure, it really is necessary IMO, for root servers and TLD servers.

---

From: Tony Finch <[email-masked]>
Date: Tue, 9 Mar 2010 16:59:54 +0000

On Tue, 9 Mar 2010, Matt Larson wrote:
>
> Even after .net is signed (in Q4 2010)

I note that Verisign's press releases say "by Q1 2011" which I find rather
hard to interpret. Why don't they say "by the start of 2011"? Do they mean
"in Q1 2011"?

People on Twitter have been saying today that Verisign are planning to
sign "during the first half of 2011" though the link they are pointing to
says "by the first half of 2011".
http://searchsecurity.techtarget.com/video/0,297151,sid14_gci1411162,00.html?track=sy160

What is the date of the actual deployment deadline?

> There is definitely a trade-off between increased response size and the
> incremental benefits of signing that needs to be weighed and evaluated.

In what situations is the larger response size a problem for
root-servers.net? Why isn't it a problem for any other domain?

Tony.

---

From: Joe Abley <[email-masked]>
Date: Tue, 9 Mar 2010 13:12:59 -0500

> hard to interpret. Why don't they say "by the start of 2011"? Do they mean

It's possible you're making assumptions about VeriSign's fiscal year-end. I've always understood "Q1" to mean "within the first quarter of the fiscal year" which will only map to January-March for companies whose year end is 31 December. Perhaps VeriSign meant something different, however.

> root-servers.net? Why isn't it a problem for any other domain?

The lack of clear answers to such questions to me is an indication that care is needed.

Joe

---

From: Edward Lewis <[email-masked]>
Date: Tue, 9 Mar 2010 13:37:55 -0500

>hard to interpret. Why don't they say "by the start of 2011"? Do they mean

Not speaking for Verisign's calendar, but if you ask me:

'in Q4 2010'            would be from Sep 23, 2010 to Jan 7, 2011
'by the start of 2011'  anytime before Feb 1, 2011
'in Q1 2011'            would be from Dec 24, 2010 to April 7, 2011

Year    ; +/- a month
Quarter ; +/- a week

And even then, it's all fuzzy.

That's roughly how I read "press-renglish"
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: Matt Larson <[email-masked]>
Date: Tue, 9 Mar 2010 14:16:29 -0500

> hard to interpret. Why don't they say "by the start of 2011"? Do they mean

Those are calendar quarters.  When encountering "by Q1 2011", I think
it is safe to assume that what is meant is "by the end of Q1 2011".
That is the intent in this particular case.

> What is the date of the actual deployment deadline?

I don't know the source for the text on that web page, but the intent
has been to consistently communicate that .net will signed during Q4
2010 and that .com will be signed during Q1 2011.

> root-servers.net? Why isn't it a problem for any other domain?

I didn't mean to imply that it wasn't.  If the address records
corresponding to a zone's name servers do not in reside in the zone
itself, I'd give strong consideration to not signing the zone
containing those address records.  For example, .com and .net are
hosted on servers named in the gtld-servers.net zone, and we are not
necessarily going to sign the gtld-servers.net zone (at least not
right away): it's a question that needs careful weighing of the
trade-offs.  Admittedly, the root zone is special becase its apex NS
RRset is queried for (./IN/NS priming queries), whereas other zones
don't receive such queries as part of the normal resolution process.

Matt

---

From: Mark Andrews <[email-masked]>
Date: Wed, 10 Mar 2010 08:41:03 +1100

In message <[email-masked]>, Matt Larson writes
> obvious (to me, anyway).  Personally, I currently lean against signing

I would sign it at the DURZ stage so that you weed out the sites that
will have problems at this stage with large priming queries not later.

---

From: "George Barwood" <[email-masked]>
Date: Fri, 19 Mar 2010 07:21:27 -0000

----- Original Message ----- 
From: "Nicholas Weaver" <[email-masked]>
To: "Matt Larson" <[email-masked]>
Cc: <[email-masked]>; "Nicholas Weaver" <[email-masked]>
Sent: Tuesday, March 09, 2010 3:31 PM
Subject: Re: [DNSOP] Should root-servers.net be signed

> I'd set it at 1450 personally, because you do have some encapulation over ethernets (eg, PPPoE, IPSEC) which occur, so if the goal is "almost guarenteed no fragments", you need to leave a little ad…

+1

> But given the current observed difficulty that resolvers have with fragments, this is, IMO, a very good decision.

+1

I suggest the default value in BIND for max-udp-size should be 1450.
This appears to be best practice.
Since few zones are currently signed, it's not too late to make this change.
Later on it may be more difficult.

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 19 Mar 2010 05:33:09 -0700

> Later on it may be more difficult.

Actually, I'd say this ONLY for the root and TLDs.  For the rest, the onus should be on the resolver to discover that it can't handle fragmentation and adjust the MTU appropriately.

---

From: "George Barwood" <[email-masked]>
Date: Fri, 19 Mar 2010 13:09:06 -0000

----- Original Message ----- 
From: "Nicholas Weaver" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "Nicholas Weaver" <[email-masked]>; "Matt Larson" <[email-masked]>; <[email-masked]>
Sent: Friday, March 19, 2010 12:33 PM
Subject: Re: [DNSOP] Should root-servers.net be signed

>Actually, I'd say this ONLY for the root and TLDs.  For the rest, the onus should be on the resolver to discover that it can't handle fragmentation and >adjust the MTU appropriately.

There are advantages besides messages being lost.
It also prevents spoofing of fragments, and limits amplification attacks.

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 19 Mar 2010 07:26:01 -0700

> It also prevents spoofing of fragments, and limits amplification attacks.

It doesn't limit amplification attacks by much if at all, and spoofing of fragments is not likely to be happening in large responses, because large responses will almost invariably be due to DNSSEC.

Since 90% CAN handle fragments, those 90% SHOULD be able to use fragments, especially since the broken 10% will see higher lookup latency, NOT full failure to resolve.

---

From: "George Barwood" <[email-masked]>
Date: Fri, 19 Mar 2010 15:32:57 -0000

>It doesn't limit amplification attacks by much if at all

It cuts the response from 4K to 1.5K, and I think fragmentation that contributes
to these attacks being damaging.

>  and spoofing of fragments is not likely to be happening in large responses, because large .responses will almost invariably be due to DNSSEC.

Resolvers may set DO=1 but not validate everything ( or even anything ).

Taking .SE as an example, by sending an open resolver that doesn't/cannot randomize ports the query [ NS SE ] ,
if the .SE servers don't conceal the IP ID, only 1 spoof packet is needed, and poisoning is easy and certain, is it not?

Note: the .SE example does not truncate, it's very unusual for a response to be truncated with a EDNS @ 1450.

I think it's best to have a conservative value as the default setting, and that is 1450 bytes.

George

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 19 Mar 2010 08:41:10 -0700

> to these attacks being damaging.

All I need to do is find a set of open resolvers which don't have such limits to do juuust fine.  

And amplification attacks are overrated anyway:  DOS burns your bots, and most of your bots can't send spoofed packets anyway these days.  

So if you are going to burn your bots, do application level: its amazing how much damage SSL setups can do to your load if you don't have dedicated crypto hardware.

> Note: the .SE example does not truncate, it's very unusual for a response to be truncated with a EDNS @ 1450.

Actually, this doesn't apply, since the reason why ns.se is 2700B is all the RRSIGs in the additional section, which are after the A and AAAA records.  So spoofing this part of the datagrams is pointless anyway, since that only has meaning if DNSSEC validation IS performed.

I really don't want to enshrine "Fragments don't work at ALL" into the infrastructure, rather I want "fragments are unreliable, so you need to detect if its YOUR side thats f-ing up and take action", thus it should be the onus on the resolver, not the authorities, to detect when this occurs and do something about it.

---

From: "George Barwood" <[email-masked]>
Date: Fri, 19 Mar 2010 16:10:01 -0000

> All I need to do is find a set of open resolvers which don't have such limits to do juuust fine.  

Eventually the open resolvers will get updated, and thus these attacks will be effectively limited.
I don't think anyone has conclusively proved they are not a risk.

> Actually, this doesn't apply, since the reason why ns.se is 2700B is all the RRSIGs in the additional section, which are after the A and AAAA records.  So spoofing this part of the datagrams is poi…

Hold on - can't the spoofer can put whatever he likes in the fragment!? He is not limited to RRSIGs.

George

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 19 Mar 2010 09:20:49 -0700

> I don't think anyone has conclusively proved they are not a risk.

HAHAHA.  Not bloodly likely IMO: a lot of the "open resolvers" are broken end-user NATS and similar.  Those will only be updated sometime around when hell freezes over.
> Hold on - can't the spoofer can put whatever he likes in the fragment!? He is not limited to RRSIGs.

Hmm, you're right, IF the A records are accepted in the additional section, true, A records could be added to the RRSET for some of the names.  But frankly speaking, thats "ADDITIONAL", and shouldn't really be accepted at all, and if the resolver DOES cache it, I'd personally call it a bug.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 19 Mar 2010 12:41:43 -0400

> HAHAHA.  Not bloodly likely IMO: a lot of the "open resolvers" are broken end-user NATS and similar.  Those will only be updated sometime around when hell freezes over.

Stuff gets updated when its brokenness becomes obvious to the person who owns it.   So revealing its brokenness is a mitzvah.

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 19 Mar 2010 10:02:29 -0700

> Stuff gets updated when its brokenness becomes obvious to the person who owns it.   So revealing its brokenness is a mitzvah.

But its not broken for the person doing it.

In fact, given it costs $10-50 to replace ($10 for a reflash when you consider time and effort) and, with flat rate internet billing, $0 to maintain as 'broken', unless the ISP is going to cut the person off, it makes no sense for them to fix!

And the ISP has no reason either, as people are not using this for significant DOS attacks anyway: application level DOS is where its at if you are going to burn bots (which are a REAL resource) for DOS attacks, due to a combination of far greater effectiveness AND the widespread use of filters against spoofed packets.

So why spend $10-

---

From: "George Barwood" <[email-masked]>
Date: Fri, 19 Mar 2010 19:01:25 -0000

> Hmm, you're right, IF the A records are accepted in the additional section, true, A records could be added to the RRSET for some of the names.  
> But frankly speaking, thats "ADDITIONAL", and shouldn't really be accepted at all, and if the resolver DOES cache it, I'd personally call it a bug.

It may be a bug, but I suspect many existing resolvers will use it.

For the priming query, a resolver has to accept glue, it's the purpose of the query ( and a special case ).

It might be considered a bug for glue to be sent with a response that is not a referral, except for the priming query.

The main (only?) reason for sending the NS RRset in an Authoritative response
( other than as a direct answer to the question ) is in case the client has not yet
discovered the zone ( because it's a child zone is hosted on the same server ),
and in this case, glue is not required, let alone signed glue.

However it could be considered a valid optimization, and it's what most existing implementations seem to do.

Anyway, do we yet agree that 1450 is the best default for max-udp-size, and that higher values are dangerous?

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 19 Mar 2010 12:48:24 -0700

On Mar 19, 2010, at 12:01 PM, George Barwood wrote:
> 
> Anyway, do we yet agree that 1450 is the best default for max-udp-size, and that higher values are dangerous?\

No:  I agree it is the proper default for the TLD authorities and roots, but for everything else, the higher value should be what the resolver requests.

Enshrining "tho shalt never fragment" into the Internet Architecture is dangerous, and will cause far MORE problems. Having something which regularly exercises fragmentation as critical to the infrastructure and we wouldn't have this problem where 10% of the resolvers are broken WRT fragmentation.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 19 Mar 2010 20:08:08 +0000

> From: Nicholas Weaver <[email-masked]>
> Date: Fri, 19 Mar 2010 12:48:24 -0700
> ...
> Enshrining "tho shalt never fragment" into the Internet Architecture is
> dangerous, and will cause far MORE problems. Having something which
> regularly exercises fragmentation as critical to the infrastructure and
> we wouldn't have this problem where 10% of the resolvers are broken WRT
> fragmentation.

+1.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 19 Mar 2010 14:32:57 -0700

> I think it's best to have a conservative value as the default setting, and that is 1450 bytes.
1450 is not a conservative value anymore.

See RFC2460 Section 5.
(dealing with IPv6/1280 ->  IPv4/<1280)
  ,---
  In response to an IPv6 packet that is sent to an IPv4 destination
  (i.e., a packet that undergoes translation from IPv6 to IPv4), the
  originating IPv6 node may receive an ICMP Packet Too Big message
  reporting a Next-Hop MTU less than 1280.  In that case, the IPv6 node
  is not required to reduce the size of subsequent packets to less than
  1280, but must include a Fragment header in those packets so that the
  IPv6-to-IPv4 translating router can obtain a suitable Identification
  value to use in resulting IPv4 fragments.  Note that this means the
  payload may have to be reduced to 1232 octets (1280 minus 40 for the
  IPv6 header and 8 for the Fragment header), and smaller still if
  additional extension headers are used.
'---
This should guide the recommended DNS message size fallback of say
1232 or less, depending upon other extension headers being used.

Bill Manning suggested 1220B, see:
http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg02996.html

-Doug

---

From: "George Barwood" <[email-masked]>
Date: Sat, 20 Mar 2010 08:50:39 -0000

----- Original Message ----- 
From: "Nicholas Weaver" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "Nicholas Weaver" <[email-masked]>; <[email-masked]>
Sent: Friday, March 19, 2010 7:48 PM
Subject: Re: [DNSOP] Should root-servers.net be signed

>Enshrining "tho shalt never fragment" into the Internet Architecture is dangerous, and will cause far MORE problems. Having something which >regularly exercises fragmentation as critical to the infrastructure and we wouldn't have this problem where 10% of the resolvers are broken WRT >fragmentation.

I'm not suggesting that. If the higher level protocol has definite security checks, or security is not important,
fragmentation is ok. But for DNSSEC neither of these is true.

BTW, I wrongly implied earlier in the thread that the threat was worse if port randomization was not possible.
That's not true, the threat is strong even with port randomization, becaause only the first fragment as the source port
( and DNS ID ). Therefore the only thing protecting the fragment is the 16 bit IP ID field.

In addition, by flooding the victim with fragments, it's probably possible to stop any valid fragment getting through,
so this is a Kaminsky-like attack, the attacker can repeat it as many times as required.

If I'm right, it's currently easy for an attacker to spoof an open cache by sending ANY queries for UK.
The resolver will not normally have any authoritative records, so will send an ANY query to the server,
and the response (which will fragment) can be attacked with success expected after sending ~32K spoof
fragments ( note : these fragments will hang around in re-assembly buffers, so attack is quite efficient ).

---

From: Nicholas Weaver <[email-masked]>
Date: Sat, 20 Mar 2010 07:26:46 -0700

> fragmentation is ok. But for DNSSEC neither of these is true.

Then what you're arguing here is don't request stuff with DO unless you are willing to validate.  Given the exercise of DO requesting is done (the firewalls have figured it out), drop DO on unvalidated traffic, don't drop fragmentation.

---

From: "George Barwood" <[email-masked]>
Date: Sat, 20 Mar 2010 16:11:29 -0000

----- Original Message ----- 
From: "Nicholas Weaver" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "Nicholas Weaver" <[email-masked]>; <[email-masked]>
Sent: Saturday, March 20, 2010 2:26 PM
Subject: Re: [DNSOP] Should root-servers.net be signed

On Mar 20, 2010, at 1:50 AM, George Barwood wrote:
>>> Enshrining "tho shalt never fragment" into the Internet Architecture is dangerous, and will cause far MORE problems. Having something which >>regularly exercises fragmentation as critical to the infrastructure and we wouldn't have this problem where 10% of the resolvers are broken WRT >>fragmentation.
>> 

>Then what you're arguing here is don't request stuff with DO unless you are willing to validate.  Given the exercise of DO requesting is done (the >firewalls have figured it out), drop DO on unvalidated traffic, don't drop fragmentation.

What I'm suggesting is that there is currently a real security problem (worse than Kaminsky),
and the most practical way to fix it is for servers not to send UDP responses that will fragment. 
For example, the recently signed UK zone, which is an immediate concern for me.

There is no practical reduction in performance for zones that mostly issue referrals. 
Normal responses will easily fit into 1450 byte packets for sensible key sizes ( actually much
less - about 800 bytes should be sufficient, maybe a bit more during key rollover ).