-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 Andrew Sullivan schreef: > 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBScpzCA8yVCPsQCW5AQJHigf/VZ3c0bfvJJN6Fuuqeuob33RHIBVKNB0m R2hU1dYknV4ral9LFLCh4cMb7bSKwvXoP3Kn9FUj4khJXylURxVn7w8ys7pu8NXJ wYoxuIWsjBPB/11xaXVFsxRdBrjfESlOXvTURluJEBR14J++SlajFMbE2UlSyTfs yVvlGRdxqZ1WXytkn5dXvrjOc9jKOKqBhqX0udSZOsiySNdiskzrF9cDWz3UaKe0 /FEoGvex3I4jY+h8zBvDjkKzGGZWqMK5oCLScAxs3EY++pKjUQE/U7iIWjPRHXL8 NrcPIuDtZF8DxUOzj1fidZ/ENspw4mU2pRF8tS/Lfy7QovKTnrjshA== =opYL -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
