DANE broken @ addons.mozilla.org?
ietf-dane at dukhovni.org
Wed Oct 14 18:54:16 CEST 2015
On Wed, Oct 14, 2015 at 12:25:20PM -0400, Simson Garfinkel wrote:
> > On Oct 13, 2015, at 3:42 PM, Andreas Pothe <mailinglisten+spamtrap at pothe.de> wrote:
> > Hi,
> > can you confirm that addons.mozilla.org has a broken DANE entry?
> > The DNSSEC Validator plugin in Firefox says "no DNSSEC at
> > addons.mozilla.org" but "invalid DNSSEC signature".
> Correct. There is no DNSSEC.
No, there is no outright DNSSEC problem for this domain.
the missing SOA record noted at that URL is optional. I'll ask
Casey to update the code to only object to "bogus" SOA records,
not missing SOA records.
The real problem is with _443._tcp.addons.mozilla.net, where the
nameservers return an invalid denial of existence, perhaps due the
presence of a "*.mozilla.net" wildcard. Someone at mozilla and
akamai needs to look into the nameserver problem.
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").
> 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. = 188.8.131.52
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).
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 184.108.40.206 port 443 via https
> 306 a 220.127.116.11 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
> Checking EE Certificate 'addons.mozilla.org' against system anchors
> 307 a 18.104.22.168 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.
> 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.
> 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.
> 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.
More information about the dane-users