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

[Shumon Huque <[e-mail]>]

On Tue, Feb 6, 2018 at 10:19 PM, Adam Roach <[e-mail]> wrote:

> 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"
>
>
Adam - nits have been noted, and will be fixed.

Shumon Huque