Subject: [DNSOP] More solicitation for feedback on dns64

From: Andrew Sullivan <[email-masked]>
Date: Tue, 24 Mar 2009 20:03:47 -0400

Dear colleagues,

Despite the speed with which I went through the dns64 issue, there is
in fact something in this that could really do with some attention.
Again, this isn't a WG document and really needs to be discussed in
behave, but I'll make a more detailed plea here now that you all heard
me talking really fast saying something.

Suppose that we have a security-aware, non-validating stub behind a
translator.  On query it sets DO and does not set CD.

The translator is a validating, recursive resolver that also performs
the translation function (a "translating validator", for short).

The general principle is that we MUST validate before translation.
So, the translating validator queries for the AAAA record, doesn't get
one, queries for the A record, and gets one with all the DNSSEC data
necessary for validation.  The translating validator successfully
validates the A record.  Now, it translates.

To perform the translation, it moves the A record to the additional
section, strips off all the RRSIG and other DNSSEC-relevant data,
synthesizes the AAAA record to match the A record, and sets the AD
bit.  It then ships the resulting response to the stub.

The question is whether that's broken in such a way that it will break
any clients.  In particular, are there clients that will get heartburn
if AD is set on a response when there's otherwise apparently no
security data in the response?

For background, the extant -02 draft doesn't do it as outlined above.
It said instead that the translating validator MUST NOT set the AD
bit, because the answer being returned isn't actually validatable.
The counter-argument, raised by Dave Thaler, is that RFC 4035 allows
the validator to set AD if it knows it can trust the answer (and of
course, the validator can know that: it validated the response from
the DNS, and it knows the prefix it is using).  In addition, Dave
reports that there is an implementation that uses the AD bit, in a
secure-last-hop context, as a boolean security flag such that
applications can make different decisions based on whether AD was
set.  So he has a use case that he wants supported.

Any feedback welcome.  As I said at the mic, discussion is really
going on in behave; I'll happily take direct feedback as well.

Thanks for your time today.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 25 Mar 2009 11:08:08 -0700

Hi Andrew,

Also following the dns64 discussion, I thought the real issue was if we
had a security-aware validating stub that does not understand
translation. The stub resolver sets the CD bit but has no clue of how to
do the translation.

Regarding the situation below, I would say the AD bit would not break
anything protocol wise. RFC 4035 says that such a stub MAY check the AD
bit in order to see if the validator performed verification, but it
SHOULD NOT attach any value to it if it does.

By the way, does the AD bit actually says something about RRSIGs need to
be present in the response? If so, point me out 'cuz I couldn't find it.

Kind regards,

Matthijs Mekking

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 25 Mar 2009 18:43:48 -0400

> translation. The stub resolver sets the CD bit but has no clue of how to

That's not an issue: it's just a known breakage.  If you have a
translation-oblivious, validating stub resolver, and you're behind a
translator, it won't work.  We've decided to accept that admittedly
lousy situation on the grounds that we can't do anything better, and
because at this stage of DNSSEC deployment, if you know how to run a
validated stub, you'll probably be able to learn about the translation
and know how to upgrade your system.  But yes, it's unpleasant. 
 
> be present in the response? If so, point me out 'cuz I couldn't find it.

Not as far as I have been able to uncover.  I'm just worried that
someone might have built something making that sort of assumption.
I'm glad to hear the answers are apparently, "I don't think so."

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Doug Barton <[email-masked]>
Date: Thu, 26 Mar 2009 00:16:41 -0700

Andrew,

I "attended" (remotely) the behave group Tuesday, and heard your
presentation to dnsop Tuesday as well, and I have to say I'm impressed
with the work your group is doing, even (especially?) the bits I don't
really understand.  :)

> the translation function (a "translating validator", for short).

Ok so far.

> bit.  It then ships the resulting response to the stub.

Here is where the alarm bells go off in my head. From 4035, Section 3.1.6:
	A security-aware name server MUST NOT set the AD bit in a
	response unless the name server considers all RRsets in the
	Answer and Authority sections of the response to be authentic.

(Also see 3.2.3, and the rules for validation in Section 5.)

That section is talking about validation of the response, the type of
synthesis that you're describing is not even considered in the
document (or anywhere else in DNSSEC unless I miss my guess). The only
place that this kind of synthesis IS mentioned in 4035 is in
relationship to CNAME RRs synthesized from DNAMEs in Section 3:

	A security aware name server that synthesizes CNAME RRs from
	DNAME RRs as described in [RFC2672] SHOULD NOT generate
	signatures for the synthesized CNAME RRs.

> security data in the response?

You're asking the wrong question. The real question is, is it OK to
set the AD bit for a synthesized response in the first place, to which
I would say "clearly it is not." Of course there are a lot of people
on this list more knowledgeable about the protocol stuff than I am,
but to my mind this seems like a slam dunk.

Furthermore, NAT64/DNS64 already provides a mechanism for the owner of
the v4-only host to set up the translation on _their_ end, which could
of course include proper DNSSEC signatures on the AAAA records for
their NAT64 box.

> bit, because the answer being returned isn't actually validatable.

It isn't that it isn't validatable, it's that the data in the answer
section is not the data that was actually validated.

> the validator to set AD if it knows it can trust the answer

I disagree with Dave's reading, see above. You also seem to be munging
the plain-english version of the term "answer" with the DNS meaning of
"data in the answer section of the packet" which is dangerous.

> (and of

Unfortunately this part of the argument muddies the water quite a bit
because now you're talking about "local policy," which I'm using here
as a DNSSEC term of art that can (for better or worse) be applied with
a broad brush to cover a multitude of sins.

One potential meaning of a validated DNSSEC response (and even the
protocol geeks disagree on exactly what it _should_ mean) is that when
I as an end user receive a validated response to my query for
blah.example.com I can connect directly to that IP address with a very
high degree of confidence that whoever controls the example.com zone
intends that IP address to be the one, true, blah.example.com. (Note
my sneaky use of the word "direct" in that sentence.)

That's great if I'm in the 1% of Internet users that actually can
connect directly to anything. If I'm in the other 99% (yeah, I'm
exaggerating) then there is almost certainly some kind of middleware
box between me and the rest of the Internet controlled by (you guessed
it) _local policy_. Given that I already have to trust whoever is
running the network (or built the box) to deal honestly with my
packets as they go from my host, through locally controlled
middleware, out to the Internet, and back; what harm does a "local
policy" of setting the AD bit for synthesized DNS64 answers cause?
Furthermore, if the person controlling the network is a bad actor,
they are just going to do it anyway, regardless of what the protocol
says.

So now that I've spoken firmly out of both sides of my mouth, for me
personally I think this _is_ a violation of 4035, but it is probably a
necessary one.

Now the bad news, I don't know the answer to your actual question
(will a stub choke on AD being set without the signature data in the
answer). Hopefully the folks at nlnet labs are paying attention to
this thread, since they are doing "bleeding edge" work on validating
resolver stuff with unbound.

Hopefully someone more knowledgeable than I can prove me wrong on one
or more points, but in any case I hope this helps stir up some
discussion, or is otherwise useful.

Doug

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 26 Mar 2009 04:50:27 -0400

> (Also see 3.2.3, and the rules for validation in Section 5.)

Yes.  But 3.1.6 also says

   […] A security-aware
   name server's local policy MAY consider data from an authoritative
   zone to be authentic without further validation.  However, the name
   server MUST NOT do so unless the name server obtained the
   authoritative zone via secure means (such as a secure zone transfer
   mechanism) and MUST NOT do so unless this behavior has been
   configured explicitly.

So AD doesn't mean "I validated this", but rather "I know this is
valid".  The translating validator _can_ know it's valid: it validated
the "base" A record, and then performed a translation using the data
it also has by secure means (the sysadmin configured it that way, or
it obtained the prefix via some secured connection, or something like
that).  

> of course include proper DNSSEC signatures on the AAAA records for

Remember that what we're trying to do is provide a (nasty) connection
between two completely different networks: there's the v4 network, and
there's the v6 network.  The claim is that we need to find a way to
make people on the v6-only network reach hosts that are in a v4-only
network.  If you disagree with the assumption, that's the one you need
to attack.  (The response, I expect, will probably be something like,
"Operators tell us they need this."  Also, the discussion certainly
doesn't belong on dnsop -- this message itself is, I suspect, already
past far enough.)  One basic assumption is that you can't force (or
convince) the v4 end nodes to do anything.  Relying on people to do
the right thing has gotten us where we are with v6, and I think what
people are hoping for is some way to make it not the case that "just
use v6 and no more v4" means "lose all the resources currently on the
v4 network".

> "data in the answer section of the packet" which is dangerous.

Yeah, sorry, I was careless.  I should have typed "response" there.

> > set.  So he has a use case that he wants supported.

[…]

> policy" of setting the AD bit for synthesized DNS64 answers cause?

Well, sure, if someone can rewrite you're packets you're in big
trouble.  On the other hand, there's only so much damage such a case
can do without being detected.  And a simple thing that I can imagine
applications doing without AD set is changing the URL-bar colour to
indicate "not a secured response".  Probably the effects of someone
messing with packets belongs on another list, however.  BEHAVE would
love some more reviewers for the nat64 part of this work!

> they are just going to do it anyway, regardless of what the protocol

Also, if they're a network operators.  The idea here is to solve the
same problems NAT-PT does.  And despite its status, NAT-PT is (I am
assured) deployed today.

Thanks for the feedback.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 26 Mar 2009 11:14:14 +0100

> it obtained the prefix via some secured connection, or something like

Yes, both inputs to the translation must be secure: the prefix and the A
record.  So, the prefix comes from the disk, or was also signed.  Not
from an (unsigned) DHCP announcement option for the prefix.

Otherwise, the output of the translation should not have the AD bit. So,
if the translating cache picked up the prefix from an (unsigned) DHCP
announcement option, that prefix is 'insecure'.  And the security status
of the translation should be the one from the weakest link.

The AD bit can be set on two conditions: the question contained the DO
bit, or the question contained the AD bit (see dnssec-updates draft).

The caching translator can also opt to never give AD bit for
translations.  This is again the local policy knob: 'no trust anchor for
the prefix'.

Like Matthijs noted, for me the most interesting thing was that the A
record was put in the additional section *without signature*.  Even
though the DO bit was set.  I would think, if the DO bit is set, you
return signatures if you have them.  That makes the most sense to me.
But without signature does not actually break anything, because 4034
allows signatures from the additional section to be omitted to make the
reply fit into the UDP datagram.  However, I believe you are required to
at least try to send that signature (according to RFC4034).

The signature is of course useful if the respondent can check the
translation. (and perform validation itself; you do not know if it does
so, regardless of whether the CD bit is set).

I would like the signature of the A record put in the additional section
as well; of course you would only get that if you signal DO bit.

Best regards,
   Wouter

---

From: Doug Barton <[email-masked]>
Date: Thu, 26 Mar 2009 11:50:44 -0700

Andrew Sullivan wrote:
> valid". 

That is a pretty large (and I believe unwarranted) leap in logic.
There is a world of difference between "I am authoritative for this
zone" and "I validated a response I got from an authoritative server
and then glued stuff onto it."

> The translating validator _can_ know it's valid: it validated

Now you're back to the local policy argument. Wouter already mentioned
additional concerns about your statement "obtained the prefix via some
secured connection" that make me even more queasy.

> convince) the v4 end nodes to do anything. 

I "get" what your goal is. I also "get" the value in achieving that
goal for the common case. What you're trying to argue is that for this
particular edge case the benefit of achieving the goal outweighs
whatever cost may be associated with violating the protocol regarding
the AD bit. So far I remain unconvinced.

> Relying on people to do

This area is where I believe our opinions diverge pretty widely, but I
agree with you that discussion of these problems is off topic for
dnsop. (That said, please keep in mind that I'm approaching this as a
strong advocate of v6 adoption.)

> can do without being detected.

Actually if I can rewrite your packets AND set the AD bit on your DNS
responses I basically 0wn you, even in a world where the OS,
application, and human layers all understand and care about DNSSEC
(modulo the CD bit of course, but that's off topic for this particular
discussion).

At this point I think I've said my piece, I'd like to encourage others
to jump in.

hope this helps,

Doug

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 26 Mar 2009 17:03:54 -0400

> and then glued stuff onto it."

So this is indeed the key point of contention.  Some argue that the
proposed behaviour is completely legal under DNSSEC, for exactly the
same reason as, if you obtained a zone by TSIG-secured zone transfer,
it would be legal for you to respond with the AD bit set even though
you didn't do the validation steps.

This question comes down to whether the AD bit is guaranteeing that
the data is exactly the data that would be provided by the authority
server, or whether it is merely a claim of trustworthiness.  If it's
the former, and one wants to argue for that, one will need a very
strong argument about which parts of the DNSSEC RFCs prove as much.
 
A
-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 26 Mar 2009 15:57:12 -0700

I haven't found the dns64 draft yet, but was involved in the 
discussion in 2001 over the AD bit.

>>  > So AD doesn't mean "I validated this", but rather "I know this is

That is correct.  The AD bit isn't a statement of how the server 
learned the information but an affirmation that the response meets 
the server's security metric.

>>  and then glued stuff onto it."

Yeah, there is a large difference.  But I don't see how this is 
germane.  So long as the server is content that the data is valid, it 
gets the AD bit.

>strong argument about which parts of the DNSSEC RFCs prove as much.

It's the latter, merely a claim of trustworthiness according to the 
sender of the response.  A DNSSEC signature provides "authenticity" 
back to the signer.  The AD bit is set by the sender, not the signer. 
The AD bit is not protected by any RFC 4033-5 (DNSSEC III) mechanism, 
it is protected (if) by message integrity (TSIG) or underlying 
network security (eg VPN, IPSEC, your choice).

Just as DNSSEC does not guarantee correctness - the signer might sign 
an incorrectly typed AAAA record - the AD bit does not guarantee 
source authenticity.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Getting everything you want is easy if you don't want much.

---

From: Holger Zuleger <[email-masked]>
Date: Fri, 27 Mar 2009 01:28:42 +0100

Regarding the original thread, I fully support the opinion of Andrew and 
Edward. But regarding the AD bit discussion, I wondered if the following 
statement is true for authoritative name servers:

Edward Lewis wrote:
> That is correct.  The AD bit isn't a statement of how the server learned 
> the information but an affirmation that the response meets the server's 
> security metric.
So why doesn't an authoritative name server set the AD bit on answers to 
queries with the DO flag set?
For sure the autoritative server sets the AA bit, but it would be 
helpful for the stub resolver if it sets the AD bit also!

Best regards
  Holger

---

From: Edward Lewis <[email-masked]>
Date: Thu, 26 Mar 2009 17:35:02 -0700

At 1:28 +0100 3/27/09, Holger Zuleger wrote:

>So why doesn't an authoritative name server set the AD bit on 
>answers to queries with the DO flag set?

Good question.  Perhaps the authoritative server does not have DNSSEC enabled?

(BIND specific - in recent versions of BIND, since Feb 2007, if 
dnssec-enabled is not yes, it doesn't do DNSSEC processing.)

---

From: Mark Andrews <[email-masked]>
Date: Fri, 27 Mar 2009 11:49:41 +1100

> dnssec-enabled is not yes, it doesn't do DNSSEC processing.)

	AD=1 is a may.  We recommend that you have a recursive-only
	view if you are mixing recursion and authoritative modes in
	the one server.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Doug Barton <[email-masked]>
Date: Thu, 26 Mar 2009 18:28:06 -0700

Edward Lewis wrote:
> 
> I haven't found the dns64 draft yet, but was involved in the discussion
> in 2001 over the AD bit.
> 

Ed,

As I said, I'm happy to defer to those who know the protocol stuff
better than I do, and I think you probably qualify. :)

The DNS64 draft is here:
http://tools.ietf.org/html/draft-bagnulo-behave-dns64-02

I think that what you're saying above coincides with the "local
policy" argument that I made in my first post. If the local
validating/translating resolver is satisfied that the prefix it's
going to prepend to the answer is valid according to local policy,
setting the AD bit is Ok. The fact that it is probably Ok doesn't mean
 I like it. Of course I still have the tool of setting the CD bit in
queries to defeat this if it really matters to me.

Doug

---

From: Jelte Jansen <[email-masked]>
Date: Fri, 27 Mar 2009 08:27:38 +0100

Edward Lewis wrote:
>> So why doesn't an authoritative name server set the AD bit on answers
>> to queries with the DO flag set?
> 

I would say that AA=1 already gives you more information than AD would; you
can't really get more authenticated than being authoritative for the data (from
a sender's point of view).

So setting it or not wouldn't add any information.

Jelte