Subject: Re: [dnsext] RFC 4035 section 3.1.6

From: Mark Andrews <[email-masked]>
Date: Tue, 04 May 2010 17:01:12 +1000

In message <2ADB0ACEB9554760821CE5B271B3505C@local>, "George Barwood" writes:
> [ Apologies for my last message being posted on the wrong thread ...]
> 
> ----- Original Message ----- 
> From: "Mark Andrews" <[email-masked]>
> To: "George Barwood" <[email-masked]>
> Cc: "Olafur Gudmundsson" <[email-masked]>; "Andrew Sullivan" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, May 04, 2010 12:53 AM
> Subject: Re: [dnsext] Side effect of DNS control plane changes Re: BNAME, Synthesized CNAME, and DNSSEC 
> 
> 
> > 
> > Setting AD on authoritative answers is a LOCAL POLICY decision.
> > Accepting AD requires you to understand the LOCAL POLICY of the
> > server that is sending the response.
> > 
> > There is no security problem here.  You either accept the LOCAL
> > POLICY or you do your own validation.
> 
> But the standard should be specifying the default behavior for a validating
> implementation.
> 
> Do we agree that the default behavior for a slave zone obtained by AXFR is
> that DNSSEC authentication MUST be performed using configured trust anchors
> when responding to recursive queries?

No, I don't agree.

> And if that's so, surely the standard should make this clear? ( I say it doesn't )
> 
> George
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 04 May 2010 17:46:32 +1000

In message <8ACD3C15A81A41ADABF7ED33436D68F3@local>, "George Barwood" writes:
> Cc: <[email-masked]>; "Ólafur Guðmundsson /DNSEXT chair" <[email-masked]>; "Andrew Sullivan" <[email-masked]>
> Sent: Tuesday, May 04, 2010 8:01 AM
> Subject: Re: [dnsext] RFC 4035 section 3.1.6 
> 
> 
> > 
> Doesn't that allow unpleasant, unpredictable side-effects for applications
> depending on DNSSEC for security?

No.  Applications that are depending on DNSSEC for security should
be validating their own answers.  This has always been the goal
from day one.  Validation in the recursive server is primarly there
to protect the server itself.  The secondary benefit is that it
protects non-DNSSEC aware clients.
 
> Suppose I configure a server to use it's own DNS service for resolving local
> queries.
> 
> An application running on that server may have DNSSEC as a requirement 
> ( looking forward to the days when DNSSEC is universally available ).
> 
> Now when an administrator adds a new AXFR slave zone, that zone is no 
> longer secure for the application. Either the DNS service returns AD=1
> "lies" (so there is an illusion of security), or it stops setting AD=1,
> and the application fails ( because it is depending on AD=1 to proceed ).
> 
> To allow this possibility seems a very bad idea to me.
> 
> Regards,
> George

---

From: Mark Andrews <[email-masked]>
Date: Tue, 04 May 2010 19:30:17 +1000

In message <1DA3B92B08DF4E0EB4264FBE8090C2BC@local>, "George Barwood" writes:
> That's a valid configuration. However the standard makes it clear 
> ( http://tools.ietf.org/html/rfc4035#section-4.9 ) that depending
> on a trusted security-aware recursive name server via a secure channel
> is also a valid configuation. Indeed this is precisely why the AD bit exists.

And if you choose to use AD then you need to understand its limitations
or configure the recursive server to always validate.  There is no
MUST here.

Accept "aa" or "ad" is a reasonable policy for a DNSSEC aware client.

Remember authoritative servers and caches have very different
temporal behaviours and trying to force DNSSEC validation constraints,
which are essentially cache constraints, onto a authoritative data
space is a bad idea.  You can't just validate the authoritatve data
and set a flag.  The validation times out.

named has match-recursive as one of the view selection criteria
just because it is such a bad idea.

Mark

---

From: Edward Lewis <[email-masked]>
Date: Tue, 4 May 2010 13:40:30 +0200

At 12:09 +0100 5/4/10, George Barwood wrote:

>My point is that a server MUST (IMO, by default at least) either
>offer validated resolution, or not.

Let me replay something:

At 23:05 +0100 4/20/10, George Barwood wrote:
>From: "Edward Lewis" <[email-masked]>
>Cc: <[email-masked]>
>Sent: Tuesday, April 20, 2010 7:59 PM
>Subject: Re: [dnsext] RFC 4035 section 3.1.6 - security hole?
>
>>  I'd encourage you to look at this page:
>>  http://www.ops.ietf.org/lists/namedroppers/namedroppers.2001/threads.html
>>
>>  and pull up all of the messages with this in the subject line:
>>       I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt
>>
>>  There are 80 of them.
>
>I looked at about 20 or so quickly.
>Obviously this was a contentious issue for some reason that I cannot fathom.
>It's quite bizarre to have end-to-end security with unpredictable exceptions.
>Hopefully no actual implementations do this, I'd certainly classify it
>as a major security bug.

I didn't reply to that message because I there was no logical 
response that I felt was within the rules and bounds of the charter 
of this WG.

But since you continue to bring this up, I'll reply to that by 
saying, you only read maybe 25% of the background material by your 
estimate.  From that you can hardly be expected to have gotten 
sufficient background.  You've been given a pointer to information - 
follow it.

Secondly, you say "for some reason I cannot fathom" and then go on to 
"certainly classify is as a major security bug."  I don't want to 
make this personal at all, but that sort of logic is hard to respond 
to in a rational way.  If you cannot grasp the issue, then how can 
you come to a conclusion?

The point is, in the past (year 2001) the WG debated this point at 
length and consensus was reached to have authoritative servers not 
DNSSEC validate data on input yet allow them to set the AD bit.  It 
would be reasonable to question the decision, and possibly reverse it 
based on new information.  However, you are saying that you ignored 
exploring all of the archive material and declare this to be the 
wrong decision.  To have any sway on this, demonstrate that you 
understand why it is the way it is, and what has happened in the past 
9 years that should change the consensus.

You are only saying that the documents do not support your thought. 
That is with the good reason that the current consensus, which hasn't 
changed in nearly a decade, disagrees with your claim.  You are not 
going to see documents changed without changing consensus, and you 
are not even on that road.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Wouldn't it be nice if all of the definitions of equivalence were the same?

---

From: Paul Vixie <[email-masked]>
Date: Tue, 04 May 2010 11:52:17 +0000

> From: "George Barwood" <[email-masked]>
> Date: Tue, 4 May 2010 12:09:57 +0100
> 
> My point is that a server MUST (IMO, by default at least) either offer
> validated resolution, or not.

i disagree.

> Having configurations where validation sometimes occurs (relative to the
> configured trust anchors) but not for all zones, is asking for trouble -
> it's confusing and dangerous.

i agree but the point is irrelevant.

> A proper implementation will keep the recursive and authoritative
> services logically separate, so there is no externally visible
> interaction between them.

that's not the issue.

> - George

the definition of the relationship between a stub and recursive does not
include security other than dnssec itself.  while many stubs will ask for
and many recursives will provide other forms of security, such as TSIG to
protect the channel and AA/AD to signal certitude, that's not in the spec
and so, the setting and checking and meaning of the AD bit is unspec'd.

if you want to define that AD means a given certitude when set by a
validating recursive in a response to a stub, then you'll also have to
require some channel security to protect this bit from spoofers.  that's
new work, not part of the dnssec effort to date.

marka has tried for about the last 36 hours to explain this to you and i
wish you would read what he's telling you.  dnssec applications should be
doing their own validation because their recursive and stub resolvers
should be dnssec-aware and all the metadata should be available end-to-end.

note, there are weaknesses in the model, and but not the one you've been
questioning in this thread.  the real weaknesses are that dnssec-unaware
recursives obstruct stub/application layer validation, and separately,
per dan kaminsky who first told me this, we need a way to ask for the full
certification chain in one message, so that stub/recursive RTT does not
become a barrier to stub/application validation.

---

From: Chris Thompson <[email-masked]>
Date: 04 May 2010 15:25:19 +0100

On May 4 2010, Paul Vixie wrote:

>[...] and separately,

Shouldn't that be *a* (rather than *the*) full certification chain? The
stub/application might have different ideas about what constitutes an
acceptable trust anchor than the recursive server does.

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

---

From: Paul Vixie <[email-masked]>
Date: Tue, 04 May 2010 14:48:52 +0000

> Date: 04 May 2010 15:25:19 +0100
> From: Chris Thompson <[email-masked]>
> 

there's no way for the responder to know what this would be.  i think we
should have a way to send all metadata that can be used to validate the
answer, so for example if there are two keys in .COM that sign VIX.COM DS,
and two keys in .VIX.COM that sign WWW.VIX.COM AAAA, then the stub/app
ought to have a way to request, in one round trip, a security blob having:

	. DNSKEY ;KSK
	. DNSKEY ;ZSK
	. RRSIG(DNSKEY) ;ZSK by KSK
	COM DS
	COM RRSIG(DS)
	COM DNSKEY ;KSK
	COM DNSKEY ;ZSK#1
	COM DNSKEY ;ZSK#2
	COM RRSIG(DNSKEY) ;ZSK#1 by KSK
	COM RRSIG(DNSKEY) ;ZSK#2 by KSK
	VIX.COM DS
	VIX.COM RRSIG(DS)
	VIX.COM DNSKEY ;KSK
	VIX.COM DNSKEY ;ZSK#1
	VIX.COM DNSKEY ;ZSK#2
	VIX.COM RRSIG(DNSKEY) ;ZSK#1 by KSK
	VIX.COM RRSIG(DNSKEY) ;ZSK#2 by KSK
	WWW.VIX.COM RRSIG(AAAA) ;by ZSK#1
	WWW.VIX.COM RRSIG(AAAA) ;by ZSK#2

we'd expect an EDNS buffer size of 32K or 64K to be nec'y, or even TCP, to
carry all this in one transaction.  but it's otherwise a whole lot of separate
transactions to pull that stuff in one metadata-rrset at a time, only to have
the noncaching stub throw it all away before the start of its next work unit.

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 4 May 2010 08:11:41 -0700

> the noncaching stub throw it all away before the start of its next work unit.

Stupid question: Who cares if its spread across multiple transactions if the stub fetches the transactions in parallel?

---

From: Paul Vixie <[email-masked]>
Date: Tue, 04 May 2010 15:32:02 +0000

> From: Nicholas Weaver <[email-masked]>
> Date: Tue, 4 May 2010 08:11:41 -0700
> 
> Stupid question: Who cares if its spread across multiple transactions if
> the stub fetches the transactions in parallel?

well, i don't know if it's a stupid question or not.  many stubs are in
embedded systems that don't allow a lot of parallelism, and the per-packet
cost may be notable compared to the per-octet cost of transporting it, and
the opportunity to cause congestion is better with asynchronous responses
than a single big response.  (i'm thinking about WRED here.)

but the most important reason why i can't expect to parallelize these fetches
is that a stub/app might not know to look in DLV unless the server can mention
DLV in a full-chain answer.  (DLV isn't part of the standard so it won't
affect this WG's deliberations, but it does affect my own thinking.)

---

From: Edward Lewis <[email-masked]>
Date: Tue, 4 May 2010 17:59:59 +0200

At 15:32 +0000 5/4/10, Paul Vixie wrote:
>well, i don't know if it's a stupid question or not.

If I read correctly, somewhere someone suggested that a resolver be 
able to return the list of RR's that went into validating a 
particular piece of data.

Actually, I kind of like that idea, even if the consequences aren't 
what some might anticipate.  For one, if a cache responds from a 
"hit" and is asked for the rationale, the result would include all 
the records used to "admit" the data into the cache upon arrival (to 
an earlier query).  It's conceivable that the list contain now 
expired signatures (like the signature of the DS record owned by the 
TLD authored by the root), so the list is no longer "valid."

And of course, if the validator's system clock is off, it might 
permit stale signatures to be considered fresh and vice versa.  And 
this would be seen.

OTOH, This would be a good way to see the trust anchors configured in 
the resolver.  And it could bolster NXDOMAIN rewriting.  (The 
NXDOMAIN was verified but I'm returning to you this instead.)

This could be an EDNS0 option - albeit one gi-mong-ous[0] option on 
return - because it's a hop-by-hop thing.  And the implementation 
could be specific to the code base.

[0] made the word up.

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 4 May 2010 09:06:56 -0700

> than a single big response.  (i'm thinking about WRED here.)

Well, what embedded system will be validating DNSSEC and couldn't be modified for a bit more parallelism?

The packet overhead is non-trivial, but is it really that bad?   DNS is such in the noise on network traffic compared with everything else out there that its an Amdahl's law situtaion.

Additionally, DNS requests are relatively short, even with DNSSEC and full chains of trust, so would WRED or similar come into play at all here?  I'd hope that everything would be fitting in an initial window if under TCP on a modern TCP stack.

> affect this WG's deliberations, but it does affect my own thinking.)

If you want to use DLV, why not speculatively fetch it always, or fetch it when necessary initiated by the stub?  If the latter, you'd have to hit the latency hit or traffic hit anyway if its either the recursive resolver or the stub thats doing the fetch subsequently or speculatively.