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

[Viktor Dukhovni <[e-mail]>]

On Mon, Jun 02, 2014 at 01:41:56PM -0700, John Gilmore wrote:

> TLS servers that offer raw public keys should not restrict their TLSA
> records to only those that match raw public keys.

There are no such records.  Records of the form "3 1 X" also match
leaf certificates.

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

This is not compatible with key rotation or other transitions
between past/present/future TLSA records which result in a subset
of the TLSA records being "active" (matching the server's actual
keys) and another subset being "inactive" (matching either past or
future keys).

Clients MUST be willing to process all TLSA records, or else should
not expect DANE authentication to work.

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

That's fine "3 1 X" records are compatible with both, but the
presence of records with any other known certificate usage or "3
0 X" records (with the possible exception of X == 0) needs to
suppress client use of oob public keys when the client's "oob"
authentication strategy is DANE.

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

That's what "3 1 X" records do.  Other records only work with PKIX,
and since these may be the only "active" ones (the mythical
[Rationale] in short form) the client should assume the worst and
not negotiate its way into a dead-end whereby authentication fails.

> The TLS server itself should always be free to offer any kind of
> authentication that it supports.

Yep, that's fine.

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

Some mention of interaction with SNI is perhaps redundant, but IMHO
useful.  Mentioned only because some might think that SNI is only
for certificates and is obviated by "oob" keys, but it is not.


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

["it" is the client here]

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

Clients MAY decide whether they are willing to transform "3 0 0"
into the contained "3 1 0".  If the WG feel that contrary to the
observation by James Cloose this is a bad idea, I am not particularly
fixated on this corner case.  However, if clients don't map "3 0 0"
to "3 1 0", then the presence of "3 0 0" in the TLSA RRset should
also suppress use of "oob" keys.

> There is no gain in interoperability [...]

Indeed, it is only a gain in opportunities to use the oob extension,
and thereby make the TLS handshake smaller.

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

We are already stating that DANE clients need to use SNI in other
contexts.  I just carried this over to "oob" keys too.  The
observation is inessential if it is considered obvious/redundant.

-- 
	Viktor.