Re: [dane] Servers which offer RPK but have no TLSA records for that key

[John Gilmore <[e-mail]>]

> But even for a tls client which likes to try oob, and which only uses
> dane to verify oob, it is not unreasonable to try oob and if it fails
> try normal tls.

The TLS Raw Public Keys (RPK) draft RFC does not require clients to
retry failed negotiations.  If it should, we had better fix it very
soon, because it is a single approval from publication.

It requires that servers only select RPK if they actively have a key
usable with RPK (they send that key in the same message where they
select RPK).  It currently does not require clients to do the same.

But let's look closer at the protocol negotiation to see where it's
easiest to fix this situation.

Clients that lack software support for PKIX should never offer the
PKIX server certificate type in the TLS negotiation.  Clients that
lack software support for RPK should never offer to negotiate RPK
server certificates in the TLS negotiation.  This is
non-controversial, and is required by RFC 7250.

Should clients that lack any Trust Anchors never propose PKIX server
certificates?  Currently, such clients *do* negotiate PKIX and then prompt
the user to validate the certificate that arrived during the PKIX
negotiation.  (You can verify this by emptying your browser's list of
trust anchors and then accessing an TLS website.)

Should clients that lack any way to validate a RPK never propose RPK?
Since we have no such clients as yet, we could decide this.  For
example, a client may not have a preconfigured public key for this
server, but it may have a DNSSEC resolver and DANE support.  But when
it starts the TLS session, it will probably not know whether there are
any TLSA records that support Raw Public Keys.  It sends its server
certificate format options in the very first message in the TLS
exchange.  So, to positively know whether TLSA records exist and
support RPK, it would have had to begin and finish a DNSSEC TLSA
lookup, and evaluate the results with an eye toward RPK, before
beginning *every* TLS exchange it initiates.  I think we want to avoid
that.

Restating, the situation in question is when the client supports
DNSSEC and DANE, has TLS software support for both PKIX and RPK, and so
does the server, but the published TLSA records may not offer a way to
verify the RPK that the server sends.

In such a situation, Viktor proposes (if I understand his messages)
that the client should offer support for PKIX and RPK server
certificates; that the server should select RPK and send an RPK; that
the client should then do the TLSA lookup, the client should notice
that there is no way to authenticate the RPK it received, and then the
client should terminate the TLS exchange and retry, offering only PKIX
support.  This proposal adds a retry requirement that currently does
not exist in either the TLS RFC or the TLS RPK RFC.

My proposal to handle this situation is that the client should offer
support for PKIX and RPK server certificates; that the server should
select PKIX and send a PKIX certificate chain, the client should then
do the TLSA lookup, and that then the client should then validate the
certificate chain using the TLSA records.

This proposal treats the situation as a server misconfiguration.  If
the server will choose to negotiate RPK but does not have a TLSA
record published that can validate RPK, it is misconfigured.  Clients
are not required to retry in order to attempt to bypass server
misconfiguration.  Persistent client failure will (eventually) alert
the server operator to their error, and they will either fix the
TLS server to not offer a RPK, or will fix the domain to include TLSA
records that authenticate the server's RPK.

	John