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

From: Adam Roach <[email-masked]>
Date: Tue, 06 Feb 2018 19:19:35 -0800

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"

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 6 Feb 2018 22:28:33 -0500

> On Feb 6, 2018, at 10:19 PM, Adam Roach <[email-masked]> wrote:
> 

DANE clients sometimes accept more than one name for the server.  This happens
when the server name is obtained indirectly from MX OR SRV records, or as the
result of (DNSSEC-validated) CNAME expansion.

So in principle, more than one name might be acceptable to the client.  In
practice however, I don't yet see a mechanism where a client that can't do
DNSSEC validation on its own would be in a position to do this.

So the server may indeed be able to validate a certificate for some name
that the client did not expect, and it would then be up to some external
mechanism (prompt the user?) to accept that name or not.

It is not entirely unreasonable to allow the client that freedom, but it
would likely not be a mainstream mode of operation.

Perhaps I am not thinking creatively enough about other ways for the client
to be configured security to accept one of many names for the server, and
to "guess" the wrong one.

-- 
	Viktor.

---

From: Adam Roach <[email-masked]>
Date: Tue, 6 Feb 2018 21:39:55 -0600

> result of (DNSSEC-validated) CNAME expansion.

Ah, that's an interesting point. You may want to keep this in mind when 
responding to the question put forth by the GEN-ART reviewer.

> DNSSEC validation on its own would be in a position to do this.

My understanding is that this mechanism isn't just for clients that 
can't do their own DNSSEC validation; it's also intended to reduce 
latency for interactive applications (web browsers and 
real-time-communication clients in particular).

> to "guess" the wrong one.

I think we're in the same boat here. :)

/a

---

From: Shumon Huque <[email-masked]>
Date: Tue, 6 Feb 2018 23:21:48 -0500

On Tue, Feb 6, 2018 at 10:39 PM, Adam Roach <[email-masked]> wrote:

> My understanding is that this mechanism isn't just for clients that can't
> do their own DNSSEC validation; it's also intended to reduce latency for
> interactive applications (web browsers and real-time-communication clients
> in particular).
>
>>
>>
>
Yes, that's true. But if we were to consider the MX/SRV use case, then for
this specification to be complete, it would have to consider clients that
are unable to validate on their own. This means the dnssec_chain extension
would have to provide records that can (also) validate the MX or SRV
records, which it doesn't do right now.

In early discussions about the scope of this draft, I believe we decided to
omit the MX/SRV case to keep things simple. This is why the draft only
references RFC 6698 and 7671, and not 7672 and 7673. (Well it mentions 7672
only tangentially to suggest that such clients likely won't need this
mechanism).

Shumon Huque

---

From: Shumon Huque <[email-masked]>
Date: Tue, 6 Feb 2018 23:23:56 -0500

> https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/
Adam - nits have been noted, and will be fixed.

Shumon Huque