Skip to main content

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

Yes

(Kathleen Moriarty)

No Objection

(Alia Atlas)
(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
(Spencer Dawkins)
(Suresh Krishnan)

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

Warren Kumari
Yes
Comment (2018-02-07 for -06) Unknown
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...)
Adam Roach Former IESG member
Yes
Yes (2018-02-06 for -06) Unknown
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"
Alexey Melnikov Former IESG member
(was Discuss) Yes
Yes (2018-03-21) Unknown
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.
Ben Campbell Former IESG member
Yes
Yes (2018-02-07 for -06) Unknown
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.)
Kathleen Moriarty Former IESG member
Yes
Yes (for -06) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Eric Rescorla Former IESG member
(was Discuss) No Objection
No Objection (2018-03-21 for -06) Unknown
Thanks for handling my DISCUSS points.
Mirja Kühlewind Former IESG member
No Objection
No Objection (2018-02-07 for -06) Unknown
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.
Spencer Dawkins Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (2018-02-07 for -06) Unknown
No objection, Alexey's DISCUSS already has hit the issue I also noted.