Subject: [dane] DANE Testing

From: Stephen Nightingale <[email-masked]>
Date: Fri, 21 Feb 2014 15:19:10 -0500

** This is posted to both UTA and DANE mailgroups. Apologies if you get 
it twice. I don't know the overlap of the two groups. **

Some improvements to the DANE Testing site at NIST since I posted to the 
dane mailgroup last November.

The site is at: https://www.had-pilot.com/dane/danelaw.html.

It is now possible to test from both TLSlite based and GnuTLS based 
clients. The Form structure of the site offers the options of connecting 
users' own identified DANE-enabled sites, connecting to the set of sites 
listed on Dan York's ISOC DANE 360 page, and getting results therefrom, 
or connecting to the NIST 'DANE Reference site' that explores all 0xx, 
1xx, 2xx and 3xx Certificate Usage permutations.

Mine was one of the 'DANE-in-the-App' sites that Viktor Dukhovni 
reviewed, and he kindly gave an extensive critique. Many of his points 
have been addressed. A few things still to clear up:
- I'm not checking for certificate revocation. That is on the list to fix.
- For 0xx and 1xx uses, it is hard to identify a single canonical CA 
list. I have overlapping, but different Root Cert sets from Mozilla, 
Fedora and Linux Mint. So when searching for an authority to build a 
verification chain I cycle through all of these until succeeding or 
exhaustion of the possibilities. Some of the DANE 360 listed sets 
(including some from members of this group) fail to authenticate because 
the root certs are not in my authorities.  A golden, canonical CA list 
would be nice to find. But I guess that its non-universal availability 
is one of the problems of the CA system that DANE is aiming squarely at.

The differences between TLSlite and GnuTLS clients highlight the fact 
that there are unresolved interoperability issues among TLS 
implementations. It seems reasonable that TLS interoperability testing 
be instituted as pre-requisite to DANE testing.  The development of a 
TLS Interoperability test suite is therefore on our 'to-do' list.  I 
look forward to seeing the newly upgraded OpenSSL client with added 
DANE. It is quite possible that as an interim step before its appearance 
I will add this DANE-in-the-App implementation to pyOpenSSL and/or Twisted.

If you find any glaring errors, I will be embarrassed but thankful.
If you find any subtle errors I will be impressed and thankful.

Cheers,

Stephen Nightingale, NIST.

-

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 21 Feb 2014 21:38:19 +0000

On Fri, Feb 21, 2014 at 03:19:10PM -0500, Stephen Nightingale wrote:

> clients.

The GnuTLS DANE implementation does not implement DANE-TA(2) or
correctly.  It may also IIRC not do PKIX-TA(0) right either.  The
issue is that the TA is incorrectly constrained to be the immediate
issuer of the leaf certificate.  There may be other problems, I
did not perform a comprehensive code review.

So results from GnuTLS DANE verification can be misleading.

> A golden, canonical CA list would be nice to find. But I guess that its
> non-universal availability is one of the problems of the CA system
> that DANE is aiming squarely at.

There is no such beast.  A form of Goedel's incompleteness theorem
applies: any list of CAs is either incomplete or untrustworthy (or
both).

> The differences between TLSlite and GnuTLS clients highlight the
> fact that there are unresolved interoperability issues among TLS
> implementations.

Default configurations of GnuTLS typically enforce unreasonable
minimum sizes on EDH primes.  Applications have to work around
these with policy overrides.

> I look forward to seeing the newly upgraded OpenSSL
> client with added DANE.  It is quite possible that as an interim step
> before its appearance I will add this DANE-in-the-App implementation
> to pyOpenSSL and/or Twisted.

Such a project should not be undertaken lightly, it is too easy to
get it wrong.

> If you find any subtle errors I will be impressed and thankful.

A code review is required to rule out subtle errors, glaring errors
may show up in tests if the test bed is sufficiently comprehensive.

-- 
	Viktor.

---

From: Stephen Nightingale <[email-masked]>
Date: Fri, 21 Feb 2014 16:54:04 -0500

> So results from GnuTLS DANE verification can be misleading.
I should point out that I am not using GnuTLS idea of DANE verification. 
I'm getting the cert chain passed up and doing my own DANE verification. 
For this purpose I had to modify the python-gnutls-1.2.5 interface to 
GnuTLS, to pass in a certificate chain, since in the download it only 
passes in a single end cert.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 21 Feb 2014 22:41:28 +0000

On Fri, Feb 21, 2014 at 04:54:04PM -0500, Stephen Nightingale wrote:

> I should point out that I am not using GnuTLS idea of DANE
> verification. I'm getting the cert chain passed up and doing my own
> DANE verification. For this purpose I had to modify the
> python-gnutls-1.2.5 interface to GnuTLS, to pass in a certificate
> chain, since in the download it only passes in a single end cert.

OK, but with DANE-TA(2) now you have the rather difficult task of
performing PKIX validation of a complete trust chain.  I forget
what your approach was for this.  Are you checking all the expiration
dates, signatures, basic constraints, name constraints, pathlength
constraints, performing name checks, ... That's a lot of difficult
code.

-- 
	Viktor.

---

From: Kurt Roeckx <[email-masked]>
Date: Fri, 21 Feb 2014 22:30:52 +0100

On Fri, Feb 21, 2014 at 03:19:10PM -0500, Stephen Nightingale wrote:
> (including some from members of this group) fail to authenticate
> because the root certs are not in my authorities.

I'm not really sure why you can't find the relevant CAs in your
root store.  It looks like you don't properly build the chain or
something?  Looking for instance at the fedoraproject.org results,
you try all 3 of them, but each time fail, where for all 3 you
actually seem to list the root CA as a relevant cert?

Kurt

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 22 Feb 2014 03:32:32 +0000

> actually seem to list the root CA as a relevant cert?

The handshake chain from fedoraproject.org is:

    subject=/serialNumber=GFaoFyCf99PHtAPDHLEBYfFi/1hePcED/C=US/ST=North Carolina/L=Raleigh/O=Red Hat Inc/OU=Fedora Infrastructure/CN=*.fedoraproject.org
    issuer=/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA

    subject=/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
    issuer=/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA

    subject=/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
    issuer=/C=US/O=Equifax/OU=Equifax Secure Certificate Authority

Per http://tools.ietf.org/html/rfc5246#page-48

   certificate_list
      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.  Because
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority MAY be omitted from the chain, under the
      assumption that the remote end must already possess it in order to
      validate it in any case.

and of course fedoraproject.org does not include the root cert in
the TLS handshake chain.  The chain needs to be augmented with the
relevant issuing root by the verifier.  In this case the Equifax
root CA.  Which is in many of the popular CA bundles.

The certificate that matches the TLSA record (CA constraint) is
the immediate issuer, but is not the root issuer and does not
appear in various CA bundles.

Perhaps the code incorrectly assumes that the CA matched by a "0
0 1" TLSA record, needs to be the root CA.

-- 
	Viktor.