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

[Paul Wouters <[e-mail]>]

On Thu, 29 May 2014, Viktor Dukhovni wrote:

>>> I think there is an obvious format, that should be spelled out
>>> explicitly in some suitable document.  Namely the same format as
>>> for the SPKI of a leaf certificate with any supported matching
>>> type:
>>>
>>>   ; Match SPKI of a certificate or just the bare public key
>>>   _25._tcp.mx1.example.com IN TLSA DANE-EE(3) SPKI(1) ? {blob}
>>
>> Where is this not clear in the existing DANE RFCs?
>
> Per John's note, the existing RFCs specifically exclude bare SPKI,

I think that's still up for discussion. But your above comment made it
appear you thought something else was missing, something about leaf
certificates and selector SPI?

>>> DANE TLS clients that also support the new TLS oob public key
>>> extension can include it in their client HELLO, provided every RR
>>> in the TLSA RRset is a "3 1 X" RR (they must perform the DNS lookup
>>> before client HELLO).  If any of the RRs have a different usage,
>>> then a full leaf certificate may be required, and the client MUST
>>> NOT signal oob public key support (since the client would potentially
>>> be unable to match a subset of the TLSA records, which may the
>>> currently active configuration).
>>
>> Can you explain why that is needed? I would envison people to migrate
>> from full certs to bare keys to have both available in their TLS server
>> and in their TLSA record set.
>
> The server will indeed have full certs and corresponding or
> independent bare keys.  However all the TLSA RRs MUST be "3 1 X"
> RRs (matching all the deployed certificates and public keys),
> or else clients MUST NOT indicate support for "oob public key".

A client can indicate support for oob public key that is not based on
DANE.

> The point being that the client does not know which TLSA RRs are
> "live" and which are "legacy" as a result of key rotation.

Why does that matter? the client receives either the server's full
certificate or its 'bare key certificate'. It looks throug the list of
obtained TLSA records and looks if anything matches. It does not need
to prove every TLSA record is valid.

Also, all TLSA records are "live", and I don't understand your
terminology of "live" versus "legacy" at all.

>  If all
> the "3 1 X" records are legacy, and only "3 0 1" or "2 0 1" RRs
> are "live", the client will fail to authenticate the server if it
> learns only the public key of the live leaf certificate.

If the client only has a bare public key of the server and the TLSA record
is only "2 x x" the setup is broken. sure. Don't do that? If there is a
"3 x x" TLSA record, there is no issue.

If the client has the full public cert of the server, then any of the
certificate usage TLSA types could be used, and there is no issue.

> A client that negotiates "oob public key" can only learn the
> server's leaf SPKI, so this needs to be sufficient to perform
> authentication, which is only true when *all* the authentication
> records are "3 1 X".

Why isn't only _one_ TLSA record of type "3 1 x"  good enough? Why can't
the admin publish a "3 1 x" and a "1 x x" or "2 x x" ?

So you brought up John's point (which all centers around "can we call a
ASN.1 SPKI a 'certificate'") and a new issue which I completely don't
understand why it is an issue.

Paul