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

[Viktor Dukhovni <[e-mail]>]

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

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.