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

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

Here is what I have for updated RFC-editor note today.

RFC-editor notes:
Please add the standard IPR section to the document.

Before the last paragraph in section 4 add this paragraph:

      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.

Add this paragraph to the end of section 2.2:

	Note that having the AD bit clear on an authoritative answer is
	normal and expected behavior.

The draft also has an odd "MUST" in section 2.2.1:
  Organisations that require that all DNS responses contain
  cryptographically verified data MUST separate the functions of
  authoritative and recursive servers, as authoritative servers are not
  required to validate local secure data.
This introduces a new concept "local secure data", w/o defining it.

Replace that paragraph with:
  Organisations which require that all DNS responses contain
  cryptographically verified data will need to separate the
  authoritative name server and signature verification functions, since
  name servers are not required to validate signatures of data for which
  they are authoritative.


Add this paragraph at the end of the security considerations section:
   A resolver MUST NOT blindly trust the AD bit unless it communicates
   with the full function resolver over a secure transport mechanism, such as
IPsec, or
   using message authentication such as TSIG [RFC2845] or SIG(0)
   [RFC2931]. In addition, the resolver must have been explicitly configured
to trust this resolver.

---