On Tue, Feb 6, 2018 at 10:19 PM, Adam Roach <a...@nostrum.com> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
