Subject: [dane] An Update on Danelaw

From: Stephen Nightingale <[email-masked]>
Date: Fri, 4 Apr 2014 14:27:32 -0400

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.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 5 Apr 2014 04:03:26 +0000

On Fri, Apr 04, 2014 at 02:27:32PM -0400, Stephen Nightingale wrote:

> https://www.had-pilot.com/dane/danelaw.html.

> and return consistent - though not identical - results.

To be precise, currently each of these: connects, dumps the server
certificate chain to a PEM chain file, and invokes my DANE verification
code in an "offline" mode to validate the chain against each of
the TLSA records.  That way the verification code is independent
of the TLS toolkit used to complete the connection.

> - Dougbarton.us works with GnuTLS, but generates handshake failures with

Something is not right with the above, at least with OpenSSL 1.0.1
I get a working SSL connection with dougbarton.us.  Now this server
presents a chain with just the leaf certificate, even though the
issuing CA is an intermediate CA.  When I put both the intermediate
cert (attached) and its issuing root (attached) in a CAfile, I can
verify the dougbarton.us "1 0 2" TLSA record just fine.

> GnuTLS, but fail against OpenSSL.

OpenSSL succeeds for me with spodhuis.org.  Same StartCom root and
intermediate as dougbarton.us, but spodhuis actually presents a
full chain.

Likewise www.kumari.net works, and the "TLSA 1 0 1" record matches
with the PKIX root from Equifax.

Do connections to these sites work for you with "openssl s_client"?
This warrants further investigation.

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

That's an application layer issue, that is not really relevant for
testing DANE.  Once the TLS session is up, you can just disconnect,
without even sending an HTTP request.

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

That does not sound right, are you sure about that?  RFC 2246, 4346
and 5246 all require servers to present a chain with more than just
the leaf certificate unless directly issued by a root CA.  So  it
would be rather surprising of GnuTLS were not capable of presenting
a complete chain.  Almost certainly you just need to invoke it
differently to load a complete chain.

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

OpenSSL definitely supports presenting a complete chain.

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

I think the issues with the HTTP use case are not protocol-specific
and will crop up again with SMTP.  So they should be addressed.

-- 
	Viktor.

---

From: Warren Kumari <[email-masked]>
Date: Sun, 6 Apr 2014 07:31:25 +0800

> Do connections to these sites work for you with "openssl s_client"?

Works for me with OpenSSL 1.0.1.

> This warrants further investigation.

Yup.

>> a certificate.  I will be testing for bi-directional verification sometime

Actually the 403 was being returned because some stupid webscrawler
script kept DoSing me, so I denied anything that didn't include an
"accept: " header. I've now removed that and the TLSlite and GnuTLS
tests now show a page instead of the 403.

While looking into this I found:
[Sat Apr 05 19:12:50 2014] [error] [client 66.84.81.58] script not
found or unable to stat: /usr/lib/cgi-bin/dane, referer:
https://www.had-pilot.com/dane/yourdane.html
in my log, which made me giggle...

W

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>