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

[Viktor Dukhovni <[e-mail]>]

On Thu, Jun 05, 2014 at 12:47:58PM +0100, Simon Arlott wrote:

> On Wed, June 4, 2014 03:55, Viktor Dukhovni wrote:
> > On Tue, Jun 03, 2014 at 10:23:39PM -0400, James Cloos wrote:
> > The onus to get this corner case avoided needs to be either on the
> > client or on the server.  The client-side solution is simpler:
> >
> >     * Avoid "oob public key" negotiation when authentication is
> >       via DANE and TLSA records may require a full certificate.
> 
> If at least one TLSA record is DANE-EE(3) then a full certificate
> is not required for that record.

This is false.  Firstly because one cannot match a public key
against a "3 0 [12]" record.  Secondly, because during transitions
between old and new keys which don't preserve the U/S/M combinations
used (old key "3 0 1", new key "3 1 1" not yet deployed) some of the
TLSA records don't match the server's change, and this may be true
for all records with a particular U/S/M combination (until the new
key is deployed).

Due to DNS caching, keys rollover and TLSA record updates are not
synchronized.

> Why do you need to restrict the client behaviour when the other
> currently defined record types are also present?

Because I've written an i's dotted/t's crossed DANE implementation
and have thought through the details that many folks are glossing
over.  Some are with me on the fine details but suggest that the
client should instead fail and retry.  But then, clients need to
know that they should be prepared to retry without oob if they
prefer that for some reason to suppressing oob.

The text can offer clients a choice.

   * Suppress oob public keys when it might well lead to authentication
     failure with servers rolling over keys and the client can handle full
     cert chains.

  * Otherwise, be prepared for authentication to fail, and retry without
    "oob".

Predicated on the existence of "usable" records other than "3 1 X"
and possibly "3 0 0" if the client is prepared to use that with
oob.

Finally, the WG could decide that servers which publish U/S/M
combinations in their TLSA RRset that contain only future or only
past keys are "misconfigured", and that servers SHOULD NOT do that.
In that case arguably the burden to get this right is on the server
and the client can be let off the hook.

I will also add language to the ops draft explaining how servers
can avoid such problem TLSA records and that they SHOULD do so.
(or at least at that it is strongly RECOMMENDED that they do so).

The rationale is that servers have no knowledge of which combinations
of usages, selectors or matching types are unsupported, administratively
disabled or otherwise unavailable/ignored by the client.  The safest
assumption is that each U/S/M combination might be the only one
supported by a given client, and therefore should always match
current (not future or past) server keys.

Still, I am not sure that server operators will reliably "get the
memo".  And thus client caution is approriate where there is little
to lose by suppressing a minor TLS optimization.

> What is the intended behaviour of the oob-capable client when new
> TLSA record types are defined? Do those records also cause it to
> refuse to do OOB or does it ignore them?

No, "unusable" TLSA records (not recognized by the client that could
never be used for matching whether a full cert chain or a bare key
is negotiated) are ignored first.  The language in the ops draft
will spell this out.

-- 
	Viktor.