On Thu, Mar 26, 2009 at 12:16:41AM -0700, Doug Barton wrote: > 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.)
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). > 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. 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". > 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. Yeah, sorry, I was careless. I should have typed "response" there. > > 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. […] > 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? 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! > 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. 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 a...@shinkuro.com Shinkuro, Inc. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
