On Tue, Oct 13, 2015 at 08:02:35PM +0000, Viktor Dukhovni wrote:

On Tue, Oct 13, 2015 at 09:42:37PM +0200, Andreas Pothe wrote:

...

Can you confirm that addons.mozilla.org has a broken DANE entry?

No, not DANE, in fact no TLSA records published). Rather, they have DNS nameserver issues:

http://dnsviz.net/d/_443._tcp.addons.mozilla.net/dnssec/

The akamai nameservers are returning non-authoritative NXDOMAIN responses with no SOA record! The responses should be authoritative and have an SOA.

Mind you, the above is generally tolerated. The other issue reported by dnsviz is that one of the servers may have and EDNS0 UDP MTU issue.

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

http://dnsviz.net/d/_443._tcp.addons.mozilla.org/dnssec/

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

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

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.

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.

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.

Correct.

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

...

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

Overall the report is substantially correct now.