[dane] An Update on Danelaw

[Stephen Nightingale <[e-mail]>]

An update on the HAD-Pilot 'danelaw' test system at NIST seems 
appropriate: https://www.had-pilot.com/dane/danelaw.html.

The three DANE clients based on TLSlite 0.4.6, GnuTLS 3.1.16 and OpenSSL 
1.0.1e all now incorporate Viktor Dukhovni's 'C' language dane checker 
and return consistent - though not identical - results. The three https 
servers based on the TLS implementations are accessed in conjunction 
with TLSA records that serve the full range of certificate usages. There 
are, though one or two issues with these servers (discussed at the end 
of this report).

A useful function that this 3x3 configuration allows is to serve as the 
basis for a TLS interoperability exercise. Extended to include Firefox, 
Chrome and IE web browsers, and the set of DANE servers listed on Dan 
York's ISOC DANE 360 site, this allows a full 6 client X 15 server 
interoperability matrix. While TLS interoperability is not strictly the 
bailiwick of DANE, DANE is certainly affected by it, so I will summarize 
that exercise here.  Parameter setting in these three implementations is 
very limited, so the exercise proceeds with more or less out-of-the-box 
settings for their respective Python applications: TLSlite as native 
Python, GnuTLS with python-gnutls, and OpenSSL with Twisted.

The core of the investigation with the 3x3 interoperability matrix of 
TLSlite, GnuTLS and OpenSSL clients and servers is fully successful, and 
all clients complete a TLS handshake with all servers.  Extended to the 
ISOC DANE 360, plus additional sites announced on the DANE mailgroup, 
most interoperate, but a number of failures is seen:

- Dougbarton.us works with GnuTLS, but generates handshake failures with 
TLSlite and OpenSSL.
- Kumari.net and Spodhuis.org both complete handshakes with TLSlite and 
GnuTLS, but fail against OpenSSL.
- The verified.danetest.com and broken.danetest.com sites fail for the 
reason mentioned by Paul Wouters in his March 20th DANE group posting.

A fuller interoperability exercise awaits the development of an explicit 
TLS interoperability test suite, and associated extension of the clients 
and servers to facilitate parameter setting.

For the sites that get past TLS interoperability, there are three sites 
that fail DANE:

- bad-hash.verisign and bad-params.verisign are intentionally broken and 
designed to fail.
- Kumari.net returns 403 forbidden to TLSlite and GnuTLS, but works with 
the Browsers.  I am guessing the 403 is generated because my clients do 
not send a certificate.  I will be testing for bi-directional 
verification sometime in the future.

Now that Viktor's dane checker is incorporated in the three clients, the 
number of seriously wrong issues is hopefully minimized. Robust feedback 
is of course always welcome.  There are still some issues with the 
servers, though:

The TLSlite server is running all 2xx certificate uses, serving a 
certificate chain of length 2, with a wild card end certificate. However 
the process goes 'stale' after about 24 hours of up time, and so needs 
to be restarted daily.

GnuTLS is running all 0xx and 1xx certificate uses, serving a single end 
certificate per use. It runs 24/7 robustly.  It can only be configured 
to take a single end certificate for the server handshake. When 
presented with a concatenation of PEM certs, it will send only the end 
cert in the server side handshake. This is curious, because the GnuTLS 
client will retrieve the full cert chain in communication with, e.g., 
the TLSlite server. I will be seeking enlightenment on this issue on the 
gnutls-help mailgroup.

The OpenSSL DANE server is running all 3xx certificate uses, with a 
single wild card end certificate. Whether it can serve a full PEM 
concatenated certificate chain is a question still to be investigated.

The near-future course of the DANE project at NIST will now focus on 
SMTP uses, for both MUAs and MTAs.

Stephen Nightingale, NIST.