Viktor suggested:
> 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.
>
> [ Rationale. ]
>
> Compatible TLSA records include all records with certificate
> usage DANE-EE(3) and selector SPKI(1) with any matching type.
TLS servers that offer raw public keys should not restrict their TLSA
records to only those that match raw public keys. This is not only
unnecessary, but harmful. It harms interoperability, and it dents the
general applicability strategy of TLSA records, which is that clients
look through the set of returned TLSA records for the one(s) that are
relevant to their current negotiation.
Raw public key support is *negotiated* by the TLS server. In the
general case, it will likely offer both raw public keys and PKIX
certificates, and the client will choose which option it likes. So
that the transaction can complete authentication regardless of which
option the client chooses, the server's domain name zone should be
free to publish TLSA records that match raw public keys, TLSA records
that match PKIX certificates, or both.
The TLS server itself should always be free to offer any kind of
authentication that it supports. The raw public keys draft already
says that it should only offer to negotiate certificate types that it
actually both supports and possesses a relevant key for; that is all
the constraint that needs to be placed on the TLS server.
I do not understand the reference to SNI. Why is there any greater
need to send an SNI option than in any other TLS negotiation? Is
there something to say here that wasn't already said in RFC 3546 or
RFC 6066? e.g. RFC 3546 page 10:
It is RECOMMENDED that clients include an extension of type
"server_name" in the client hello whenever they locate a server by a
supported name type.
A server that receives a client hello containing the "server_name"
extension, MAY use the information contained in the extension to
guide its selection of an appropriate certificate to return to the
client, and/or other aspects of security policy.
> Clients MAY also elect to treat records with usage DANE-EE(3),
> selector Cert(0) and matching type Full(0) as compatible,
> provided they are willing and able to extract the public key
> from such a TLSA record for comparison with the server's bare
> out of band public key.
I think this is a bad idea. If the TLS server offers a raw public
key, it should not try to authenticate it via a TLSA record that
contains a PKIX certificate. The intent of raw public keys is to
allow simpler (need I say easier to debug and more secure) clients
that don't need to parse, let alone validate, a PKIX certificate.
This just complicates clients for no gain in interoperability.
There is no gain in interoperability because, if matching a raw public
key in a PKIX certificate is OPTIONAL, then clients can't be depended
upon to extract a key from a PKIX certificate in order to authenticate
the key. This means that server zones will have to publish a real raw
public key in a TLSA record anytime they want to have interoperability
with raw public key clients. Given that the server zone must in
practice publish a real raw key, suggesting that clients should
optionally match against a (second) TLSA record containing a
complicated PKIX certificate is a burden without any gain.
> 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 think that where the server's public key comes from is irrelevant to
the protocol. It could have been extracted from a PKIX certificate,
it could have been generated by rolling dice, it could have come from
divine inspiration, thermal noise, or the Linux filesystem. Why would
we suggest one particular method?
If the point is that the Server Name Indication option sent by the
client might affect the offered key, that's a point. But the same is
even more true of the offered PKIX certificate in traditional TLS, so
if we feel the need to say this, why aren't we already saying it about
PKIX certificates?
John
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
