Re: [TLS] DANE & TLS 1.3 (was Re: Deprecate SHA1 for signatures in TLS 1.3)

[Viktor Dukhovni <[e-mail]>]

On Tue, Jul 14, 2015 at 12:38:51AM -0400, Dave Garrett wrote:

> > Furthermore, DANE-EE(3) clients and certificate pinning clients
> > cannot use anon_DH, they still a recognizable certificate from the
> > server, they just often don't need a recognizable signature.  Even
> > DANE-TA(2) clients might be able to stop part-way up the chain
> > before the objectionable signature appears.
> 
> Generic open-ended question: Is there anything else with regard to getting
> DANE working more smoothly that needs addressing?

>From a TLS standards perspective, we're in reasonably good shape.

The main remaining friction point is server software that is
incapable of including self-signed root CAs in the server's wire
certificate chain.

With DANE-TA(2), the trust-anchor certificate MUST be in the
server's certificate message (wire chain) even if it is a
self-signed "root".  So if a site wants to designate a self-signed
DANE trust anchor, it must find a way to include it in server
chains.

This is not a protocol problem as such.  Rather, the fact that the
specification says that server MAY omit root CA certs with a
"traditional" X.509 PKI means that some software stacks provide no
means for the server administrator to force inclusion.

With TLS 1.3, perhaps updated text could reference the imminent
RFC 6698 update (draft-ietf-dane-ops, scheduled for the IESG telechat
on Aug 6th) and mention that a mechanism needs to exist for servers
to request inclusion of root trust anchor certificates (when the
library constructs the chain on the fly by augmenting the application
provided leaf certificate with the requisite intermediate CA certs,
but at present by default leaves out the root CA cert).

In addition, with DANE-EE(3) TLS libraries are expected to accept
end-entity certificates that are expired or bear the wrong server
name, provided the certificate or enclosed public key matches the
TLSA record.  Thus (again not a protocol issue), it would be nice
if TLS libraries did not get in the way of that, but presumably
this gets fixed when the library adds DANE support.

Speaking of DANE support in libraries, there are as yet no mainstream
libraries that offer correct and complete DANE support.  I expect
to remediate this for one or two open source libraries.

Last I looked GnuTLS DANE support was rather incomplete, "ldns"
was insecure and libval was fragile.  Neither OpenSSL nor mTLS (aka
PolarSSL) at present support DANE.

In general don't trust DANE "addons" that are not core parts of
the underlying TLS library, this is very difficult to get right.
DANE support needs to be "baked in" as part of the core chain
construction and validation logic of the TLS library.  The application
can provide the validated TLSA RRset, the TLSA base domain and zero
or more additional reference identifiers (with DANE there can be
multiple valid hostnames for the server end of a client's TLS
connection), and the library should then do the rest.

I'd like to see DANE support in the not too distant future in at
least:

	* OpenSSL
	* mTLS
	* GnuTLS
	* NSS
	* Schannel
	* Java

-- 
	Viktor.