Redefinition of DNS Authenticated Data (AD) bit
draft-ietf-dnsext-ad-is-secure-06

The final paragraph of the Security Considerations is written
in a way that obscures meaning, in contrast to the related
final paragraph of Section 3.

> Resolvers (full or stub) that blindly trust the AD bit without
>    knowing the security policy of the server generating the answer can
>    not be considered security aware.


A better version would be "that blindly trust the AD bit MUST
be used only in an environment in which configurations ensure
that the security policy of the server is  appropriate to
the AD bit's information being valid for a decision on whether
to use the information it applies to"

Perhaps rather than obscuring meaning, it is actually wrong.
But the above hasty attempt tried to express something less
wrong.

this 'discuss' is meant literally. i just think that there are 
some issues here worth discussing. 

the major issue here is that having a remote, often untrusted, server 
assert (often over an untrusted channel) that the data met its local 
policies is not overly useful and is possibly misleading. the counter 
is that the stub client may have a trust relationship, via tsig or 
whatever, with the server, which also provides a trustable channel. 

on the other hand, this is no worse, and arguably better than the 
current definition of the AD bit. this then devolves into the 
question of whether it is better to improve a weak assertion or to 
recover the bit and reserve it for future use. 

who is going to use this assertion? is it thought that application 
layers will learn the trust state of the dns data which they use? 

and then, there is the exciting question of what this means in the 
presense of the dreaded opt-in. the client can not tell if the server 
which set the AD bit is locally configured to like opted-out data.