[TLS] Adam Roach's Yes on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)

[Adam Roach <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-tls-dnssec-chain-extension-06: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I like this mechanism and look forward to its deployment. I have one point of
clarification and a small handful of editorial comments.

First, the point of clarification:

§4:

>  if the server does not recognize the
>  provided name and wishes to proceed with the handshake rather than to
>  abort the connection, the server uses the domain name associated with
>  the server IP address to which the connection has been established.

Unless I missed something important, this scenario doesn't seem to make much
sense: if the client provides name A and the server replies with name B, the
client either (1) isn't performing server name validation (in which case it is
nonsense for the client to ask for a dnssec_chain), or (2) is going to error
out the connection. Do I have that right? If there's some situation in which
the server acting as described above provides some benefit, I would love to
see it described in here. If it's just a matter of having completely described
behavior for corner cases, it may be worthwhile indicating that the client
will reject the connection if the server decides to complete the handshake
like this.

---------------------------------------------------------------------------

> Intended status: Standards Track                               R. Barnes
> Expires: July 27, 2018                                           Mozilla

s/Mozilla/Cisco/

---------------------------------------------------------------------------

§1:

>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>   document are to be interpreted as described in [RFC2119].

This document has significant usage of these terms in lowercase. Please consider
using the boilerplate from RFC 8174 instead.

---------------------------------------------------------------------------

§3.3:

>  the case in DANE in which a client either ignores the name in
>  certificate (as specified in [RFC7671] or there is no attestation of

Nit: "...in the certificate..."

Nit: Add closing paren after [RFC7671]

---------------------------------------------------------------------------

§4:

>  specific processing needed for aliases and wildcards.  If DNS
>  responses messages contain any domain names utilizing name

Nit: "response"