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

[Viktor Dukhovni <[e-mail]>]

On Thu, Jun 05, 2014 at 03:27:14PM -0700, John Gilmore wrote:

> 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.

I think that's OK.  It is just DANE authentication "RPK" clients
that need to be aware of the potential reduction in "usable" TLSA
RRs when negotiating "RPK" and either avoid negotiating "RPK" when
authentication might fail, or be willing to retry without "RPK".

Therefore, this seems like a rather DANE-specific issue, to be
defined in a DANE document for interoperability with "RPK", so it
is not obvious that the DANE-specific issues need to be explicitly
stated in the "oob mechanism" independent RPK docuemnt.

There are also timing subtleties, are TLSA records located before
the TLSA handshake or during the handshake once the server provides
key material.  If the latter (which I don't recommend for reasons
that are TMI for this thread), then the client can only retry, it
is too late to suppress RPK in the TLS HELLO.  The short version
is of course that for clients capable of X.509 server gymnastics,
if the TLSA lookup is delayed, then the client might discover
complete lack of any "3 1 X" (or whatever compatible U/S/M applies)
RRs, and will have to retry without RPK simply because the lookup
is too late.

Assuming clients that support both certs and RPK are not silly
about TLSA record lookup timing, the issue becomes moot if there
is a new published requirement on servers to ensure that every
U/S/M combination contains some record that matches the server's
current chain.  I assume there'll be some further discussion about
the merits and sufficiency of such a requirement on servers to
obviate complications for clients.

> Should clients that lack any Trust Anchors never propose PKIX server
> certificates?

No, because with DANE server certificates are not necessarily PKIX.
Usages 2/3 don't require any TAs on the client side.  The default
Postfix configuration ignores all system provided TAs, and the TA
list is empty, and yet we do DANE with "PKIX" certificate chains
validated via DANE-TA(2) or DANE-EE(3) TLSA RRs.

> 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.)

With DANE, authentication of cert chains is possible without any
PKIX CAs.

> Should clients that lack any way to validate a RPK never propose RPK?

DANE makes it possible to validate RPK via DANE-EE(3)/SPKI(1)
associations.  However, there are some subtleties we need not
repeat the details of when the server TLSA RRset is "mixed".

> 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.

The tentative consensus here (DANE WG) appears to be that there is no
new TLSA RR type that represents an RPK-specific association.  Rather,

	DANE-EE(3) SPKI(1) MTYPE(0|1|2)

is equally usable to match a public key embedded in a certificate
or a raw public key.

> 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.

The DNS lookup is necessary, but the results can be cached for the
TTL in any local resolver, or the application, or both.  Postfix
caches TLSA RRs in the application (for the shorter of the TTL,
100 seconds, or the lifetime of the SMTP delivery agent).

> 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.

[ Or in some corner cases, the client might not be able to tell
whether the server can be authenticated with RPK, unless we place
new requirements on the server.  We can for now collapse this into
the above case. ]

> In such a situation, Viktor proposes (if I understand his messages)
> that the client should offer support for PKIX and RPK server
> certificates;

No, that's not my proposal.

I am proposing that the client should have the TLSA records on hand
*before* the handshake, it will always need them after, and doing
the lookup (with whatever caching is applicable) earlier makes
things much easier.  Therefore, I am also proposing that the client
in fact NOT offer RPK to the server, if success to authenticate
the servers TLSA RRset with RPK is a proper subset of case in which
it succeeds had it negotiated PKIX certs instead.

Alternatively, (don't know why this is attractive) the client might
be willing to reconnect and retry.  Finally, if we define server
TLSA RRsets that put clients into this position as "misconfiguration",
then perhaps we can relieve clients of the burden.

> This proposal adds a retry requirement that currently does
> not exist in either the TLS RFC or the TLS RPK RFC.

I am not at all fond of retries.  I am guessing you're not either.

> 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.

You're saying that the server should know the sorry state of its
DNS TLSA RRs as seen by the client.  This is likely impractical.
Servers just have key material and do TLS handshakes they are
DNSSEC/DANE agnostic.  They have no idea what mechanism if any the
client is planning to use to authenticate the server's keys/certs.

> If
> the server will choose to negotiate RPK but does not have a TLSA
> record published that can validate RPK, it is misconfigured.

The sentiment is well motivated, but this is likely rather impractical.

> Clients
> are not required to retry in order to attempt to bypass server
> misconfiguration.

Again, at the moment, the problem cases are NOT server misconfiguration,
we'd have to define new server configuration requirements to make
it so.  Requirements that burden the server with knowing what
authentication mechanisms clients might be using and with knowing
how their DANE TLSA records are configured, ... are I think not realistic.

Requirements on the content of the TLSA RRs as published are an
option.  I am planning to write up said server requirements as
strong recommendations, but for the moment at least, also publish
client recommendations that scale back "opportunistic RPK" (use of
RPK when either RPK or PKIX are options) when it doubt.  This avoids
retries, and has little impact on use of RPK (in most cases servers
will have either no or only RPK-compatible TLSA RRs).

"Opportunistic RPK" clients should perform TLSA lookups before the
handshake.

> 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.

Perhaps, though initially the volume of clients failing will be
rather low, and server operators will blame the bleeding-edge
clients (it works for everyone else).

-- 
	Viktor.