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

[Paul Wouters <[e-mail]>]

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.

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

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.

> For the server side, I would add:
>
>    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? If the client tells the server the SNI,
the server picks the right identity - regardless of the 7250 extension.

Paul