A DANE Record and DNSSEC Authentication Chain Extension for TLS
draft-ietf-tls-dnssec-chain-extension-07

Note: This ballot was opened for revision 06 and is now closed.

(Ben Campbell) Yes

Comment (2018-02-07 for -06)
No email
send info
I am happy to see this published, but have a few minor comments:

- I agree with Alexey's comments.

-3.4: "If the TLSA record set was synthesized by a DNS wildcard, the chain
   must include the signed NSEC or NSEC3 records that prove that there
   was no explicit match of the TLSA record name and no closer wildcard
   match."

Should that "must" be a "MUST"?

- Nit in Authors List: Unless I've missed something, Richard's affiliation is no longer current. (I only point it out in case it's an oversight; I have no objection if it's that way on purpose.)

Warren Kumari Yes

Comment (2018-02-07 for -06)
No email
send info
I was one of the very early DANE people / WG chair / etc.

Y'all have come along, commandeered our protocol..... and made it much better (and deployable)... <insert old man shakes fist at cloud meme>.  
Seriously, thank you -- I was saving this document to be able to do a very thorough review, but unfortunately have run out of time, so only have one comment to offer:  

Section 3.1.  Protocol, TLS 1.2
"Therefore, a server MUST NOT construct chains for domain names other than its own." -- what is a servers' "domain name"? E.g: My webserver has certs with many SANs, and SNI, etc Perhaps this should be more along the lines of "MUST NOT construct chains for domain names which it is not responsible? (Obviously, this will also require some wordsmithing, I don't really know what it means to be "responsible" for a domain; perhaps "domains it doesn't have certificates for"? something...)

Alexey Melnikov (was Discuss) Yes

Comment (2018-03-21)
No email
send info
Now that TLS 1.3 is approved for publication, I think adding a Normative Reference to TLS 1.3 is no brainer. I am clearing my DISCUSS on the assumption that this would be fixed before publication of the RFC.

1) TLS 1.3 needs to be a normative reference, but it is not even listed in References.

2) The first mention of NSEC3 need a normative reference.

(Kathleen Moriarty) Yes

Adam Roach Yes

Comment (2018-02-06 for -06)
No email
send info
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"

(Alia Atlas) No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

Suresh Krishnan No Objection

Mirja Kühlewind No Objection

Comment (2018-02-07 for -06)
No email
send info
Two minor, mostly editorial comments:

1) Intro (sec 2): " It also provides the
   ability to avoid potential problems with TLS clients being unable to
   look up DANE records because of an interfering or broken middlebox on
   the path between the client and a DNS server."
Is that actually a well-known problem (can you provide a reference?) or would it be enough to say something like this:
" It also provides the
   ability to avoid potential problems with TLS clients being unable to
   look up DANE records when DNS server is not reachable."

2) IANA Considerations should probably be updated.

(Terry Manderson) No Objection

Comment (2018-02-07 for -06)
No email
send info
No objection, Alexey's DISCUSS already has hit the issue I also noted.

(Eric Rescorla) (was Discuss) No Objection

Comment (2018-03-21 for -06)
No email
send info
Thanks for handling my DISCUSS points.

Alvaro Retana No Objection