Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys

[Viktor Dukhovni <[e-mail]>]

On Tue, Jun 03, 2014 at 01:04:55AM -0400, Paul Wouters wrote:

> On Mon, 2 Jun 2014, Viktor Dukhovni wrote:
> 
> >In whatever document ends up publishing the details,  I would say:
> >
> >   TLS clients that support out of band public keys ([TLS WG
> >   document reference]) authenticated via DANE TLSA records SHOULD
> >   NOT employ the "oob public key" TLS extension unless all the
> >   server's TLSA records are compatible with out of band public
> >   keys.  The client SHOULD send an SNI extension with the server's
> >   TLSA base domain even if it is willing or expecting to use out
> >   of band public keys.
> 
> Again, I don't see why. If there is one TLSA record that matches the
> public key of the server, that's good enough. If you do any kind of TLS
> key rollover, the TLS admin better pre-publish the proper TLSA records.

Suppose the only one that does is a "DANE-TA(2) Cert(0) SHA2-256(1)".
What then?

	; transition state when updating DNS records prior to new
	; key deployment.
	;
	example.com IN TLSA 3 1 1 {recent past blob}
	example.com IN TLSA 2 0 1 {current blob}

A client that negotiates "oob public key" in this state fails to
authenticate the server.

> Saying that all TLSA records should be of a type compatible with oob
> serves no purpose and could hinder deploymentment of oob TLS.

Obviously I have a purpose in mind, for some reason it is not
getting through.  I think some others have understood, perhaps they
can have a crack at explaining it to you.

> If a TLS client local policy prefers oob, and it finds only non-oob
> compatible TLSA records, it could omit using oob to prevent issues.
> But I don't think that is a MUST.

We can quibble over MUST vs. SHOULD.  However, and especially
because the point appears to be non-obvious to many, experts
included, it needs to be made.  ALL the TLSA records need to be "3
1 X", possibly also "3 0 0", or else the client SHOULD skip "oob".

> >   Servers that support "oob public key" MAY employ SNI to select
> >   the correct public key, either by identifying a matching
> >   certificate from which to extract the key, or via some other
> >   mapping from the requested domain to the corresponding key.
> 
> I do not see why we need to drag SNI into this. How is SNI different for
> bare keys versus certificates?

It isn't.  I just wanted to spell it out.  DANE clients send SNI, even
if when they use "oob public key".  As in my reply to John Gilmore, if
everyone agrees this is obvious, it is not essential (but harmless, no?).

-- 
	Viktor.