draft-ietf-dnsext-ad-is-secure

[Erik Nordmark <[e-mail]>]

The document was approved by the IESG today with some changes as an RFC editor 
note. Mostly what I sent to the list earlier but some rewording in the first
item, and the addition of the last item. (I know the last item is largely a
repeat of existing text elsewhere in the draft, but in the interest of time
and knowing that 2535bis will fold all this into one document I cut some
corners.)

If these tweaks are problematic let me know and I'll stop the presses.

  Erik

RFC Editor note:

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.

---


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>