DANE broken @ addons.mozilla.org?

Viktor Dukhovni ietf-dane at dukhovni.org
Tue Oct 27 05:52:20 CET 2015

On Mon, Oct 26, 2015 at 06:52:30PM -0400, Simson Garfinkel wrote:

> >
> > > Test #        Host    IP      Status  Test Description (§ Section)
> > > 103   addons.mozilla.org              FAILED  Service hostname must
> > have matching TLSA record
> > > Resolving TLSA records for hostname '_443._tcp.addons.mozilla.org'
> >
> > This one is merely misleading, "FAILED" should only apply when the
> > TLSA records don't match, or DNS lookups fail.  Not publishing TLSA
> > records is not a failure, it is rather a non-deployment (with some
> > neutral colour not "red").
> >
> I have changed test 103 to read "NON DEPLOYMENT" when there is no TLSA
> record for a given host. The background is now cyan. I personally feel that
> a domain fails the DANE test if it does not have a DANE TLSA record, but I
> will defer to Viktor.

Note that when the target is a CNAME, "non-deployment" means no
TLSA record at *either* end of the CNAME chain.  So if no TLSA RRs
are found at the (secure) expanded CNAME, but TLSA RRs are present
at the unexpanded original target name, then I would try to avoid
describing this is as a "non deployment".  

This makes the UI a bit more tricky.  "Non-deployment" is then I
think a "global" condition to report near the top of the page, and
the status of the original or expanded name is either "TLSA records
present" or "TLSA records not present".

> Following RFC7671, I
> will now do the following:
>    - Fully expand the CNAME to the final target.

Then if and only if "secure" at each stage:

>    - Get the TLSA record for the corresponding expanded, target domain
>    - If there is no TLSA record, try to initial, unexpanded, source domain.


>    - Document all DNS lookups that result in NO_NAME.  (Question: how do I
> tell from the getdns API if a NO_NAME response is DNSSEC authenticated?)

It turns out that you don't need to distinguish between "secure"
and "insecure" NXDOMAIN and NODATA.  Either the records don't exist,
or would not be trusted even if they existed, so the status is not
relevant.  The security status of negative replies is only needed
in order to fail when faced with "bogus" replies.  Provided the
library throws an exception or returns an error with "bogus" answers,
you don't need to know whether negative answers are "secure" or

> > This part is surely wrong, the "addons.mozilla.org" HTTPS service
> > has a valid EV cert.  I would expect it to PKIX verify given the
> > right trust anchor:
> >
> >     CN = DigiCert High Assurance EV Root CA
> >     OU = www.digicert.com
> >     O = DigiCert Inc
> >     C = US
> I'm not sure what was happening before. However, this is now reporting
> correct. Would it be useful to have the CN, OU, O and C fields from the
> certificate displayed?

Nor I, ordinary non-DANE PKIX validation reports success now.  As
for what to display from the certificate chain, your call.  If you
want to provide a chain summary, perhaps issuer/subject/dates of
each chain element?

> > This is not a DANE-TA(2) check, the domain has no TLSA records, so
> > the text is not applicable.
> This is interesting. Name checks are applicable because the certificate is
> served via HTTP.

HTTP is not the reason name checks are required.  Name checks are
also needed when doing mandatory authenticated TLS with SMTP for
example.  Name checks are not needed with unauthenticated (typically
opportunistic) TLS and with DANE-EE(3) where they are obviated by
the name to key binding in the TLSA record.

Here, you're doing RFC5280 PKIX with assocaited RFC6125 name checks,
so name checks are in scope.  If you had DANE-EE(3) TLSA RRs for
this TLS destination, you'd skip name checks when matching that
TLSA record.  It is even possible to have:

    _443._tcp.www.example.com. IN TLSA 3 1 1 <key digest>
    _443._tcp.www.example.com. IN TLSA 2 0 1 <issuer cert digest>

in which case you'd skip name checks if the "3 1 1" record matches,
but apply name checks to determine whether the "2 0 1" record
matches.  It is even possible for the "2 0 1" to match the issuer
and name checks to fail, but the connection is still valid if the
"3 1 1" record matches.

Thus the applicability of name checks is determine on a (TLSA)
record by record basis when deciding whether that particular record
authenticates the server or not.  Only DANE-EE(3) obviates name
checks, with all the other DANE certificate usages name checks are

Overall the report is substantially correct now.


More information about the dane-users mailing list