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
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
