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" _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
