Re: [dane] An Update on Danelaw

[Viktor Dukhovni <[e-mail]>]

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

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

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
>   TLSlite and OpenSSL.

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.

> - Kumari.net and Spodhuis.org both complete handshakes with TLSlite and
> 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.

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

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.