DANE broken @ addons.mozilla.org?

Simson Garfinkel simsong at acm.org
Mon Oct 26 23:52:30 CET 2015


Thanks again to Viktor for his assistance in helping me clarify the tester
I am developing.

Viktor wrote:

> Finally, the test results below don't look right...
>
> > 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.



>
>
> > SECURE DNS CNAME lookup addons.mozilla.org = addons.dynect.mozilla.net.
> > 102                     PASSED  if at any stage of recursive expansion an
> > "insecure" CNAME record is encountered, then it and all subsequent
> results
> > (in particular, the final result) MUST be considered "insecure"
> regardless
> > of whether any earlier CNAME records leading to the "insecure" record
> were
> > "secure". (§2.1.3)
> > Expanding CNAME addons.mozilla.org to addons.dynect.mozilla.net.
> > INSECURE DNS A lookup addons.dynect.mozilla.net. = 63.245.216.132
>
> The CNAME record is "secure" but its target lies in a sub-zone that
> is not signed.  Therefore, the TLSA record should be obtained from
> the original name, not the CNAME expanded name (draft-ietf-dane-ops
> to become RFC7671 later this week I expect).
>

In fact, my tester was presenting the results of a test of
addons.mozilla.org *and *addons.dynect.mozilla.net. However this wasn't
exactly clear that I was doing this. I was getting the TLSA record for the
primary name, then seeing if there was a CNAME chain.Following RFC7671, I
will now do the following:

   - Fully expand the CNAME to the final target.
   - 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?)



> So _443._tcp.addons.mozilla.org is the TLSA RRset qname.  That
> lookup yields authenticated denial of existence (without an SOA
> record, so not cacheable).
>
> > Fetching EE Certificate for addons.mozilla.org from 63.245.216.132 port
> 443 via https
> > 306   a       63.245.216.132          Server EE Certificate does not
> PKIX Verify
>
> 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?



>
> > Checking EE Certificate 'addons.mozilla.org' against system anchors
> >
> > 307     a       63.245.216.132  FAILED  "When name checks are applicable
> > (certificate usage DANE-TA(2)), if the server certificate contains a
> > Subject Alternative Name extension ([RFC5280]), with at least one DNS-ID
> > ([RFC6125]) then only the DNS- IDs are matched against the client's
> > reference identifiers.... The server certificate is considered matched
> > when one of its presented identifiers ([RFC5280]) matches any of the
> > client's reference identifiers." (§3.2.3)
>
> 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. The only thing that makes the text not applicable is the
parenthetical (certificate usage DANE-TA(2)." I will therefore remove the
parenthetical and replace it with an ellipses .


>
> > Hostname addons.mozilla.org does not match EE Certificate Common Name '
> addons.mozilla.org'
>
> This does not look right, clear the names are identical.
> >
> > 403     addons.mozilla.org              FAILED  All IP addresses for a
> > host that is TLSA protected must TLSA verify Validating TLSA records for
> > 0 out of 1 IP addresses found for host addons.mozilla.org
>
> TLSA matching is not pertinent, this domain has no TLSA records.
>

A NON DEPLOYMENT message is now given if the domain does not have TLSA
records.It now reports how many relied on and how many are secure.  In this
case, Validating TLSA records are found for 0 out of 1 IP addresses for
host addons.mozilla.org



>
> > 405                   FAILED  All DNS lookups must be secured by DNSSEC
>
> That's not a failure, at most a non-deployment, and in any case
> not right.  In this case however, sufficiently many DNS records
> are "secure" to allow the domain to verify via DANE too, had they
> published a matching TLSA RRset at the above mentioned qname.
>

The tester determines if a DNS lookup is relied upon to reach a DANE TLSA
certificate.


>
> > 404                   FAILED  No HTTP DANE test may fail
> >               Were any DANE HTTP tests a hard fail?
>
> No DANE tests are in scope, for lack of TLSA records.
>

Now it reports "Total HTTP TLSA Records Present: 0"

To see the revised report, please visit:

http://arp.simson.net/dev/dane_check.cgi/https/addons.mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.sys4.de/mailman/private/dane-users/attachments/20151026/7577e997/attachment-0001.html>


More information about the dane-users mailing list