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.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
