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. :)
Andrew Sullivan wrote:
> 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).
Ok so far.
> 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.
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.
> 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?
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.
> 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.
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 counter-argument, raised by Dave Thaler, is that RFC 4035 allows
> 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
> 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.
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
