Re: Evaluation: draft-ietf-dnsext-ad-is-secure

[Erik Nordmark <Erik.Nordmark@sun.com>]

>    I fear  that implementors will trust the AD bit as meaning "secure" and 
> then not bother to protect the transport, which admits the possibility of 
> spoofing attacks.  Therefore I propose an alternative paragraph for the RFC 
> Editor note:
> 
>      In the latter two cases, the end consumer must also completely
>      trust the network path to the trusted resolvers or a secure
>      transport is employed to protect the traffic.

It was smb that suggested 
	In the latter two cases, the end consumer must also trust the
	path to the trusted resolvers.
so as long as he is ok with the above text ...

>    Further, I suggest that the Security Considerations be expanded to 
> provide a discussion on how a secure transport can be provided.  I would 
> think that DNSSEC and IPsec are obvious alternatives. 

Oops - should have been there.

Section 3 says:
   A resolver MUST NOT blindly trust the AD bit unless it communicates
   with the full function resolver over a secure transport mechanism or
   using message authentication such as TSIG [RFC2845] or SIG(0)
   [RFC2931] and is explicitly configured to trust this resolver.

Did you more or less want to repeat the TSIG and SIG(0) in the
security considerations plus give IPsec as an example of a secure transport?
If so I can ask for some suggested text from the authors.

  Erik