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

[Adam Roach <[e-mail]>]

On 2/6/18 9:28 PM, Viktor Dukhovni wrote:
>
>> On Feb 6, 2018, at 10:19 PM, Adam Roach <[e-mail]> wrote:
>>
>> 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.
> 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.

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.

> 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.

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).

> 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.


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

/a