Please reopen.

It was not fair to close this bug because Bug 672239 was WONTFIXED. Bug 672239 asked to "implement DNSSEC TLS" in the browser. But once you have DNS-over-HTTPS, you do not need to "implement DNSSEC TLS" (in the browser) in order to "check TLSA records".

It is up to DNS-over-HTTPS servers to implement DNSSEC TLS. Once they start doing that, they will deliver TLSA records to DoH clients (browsers) via DNS-over-HTTPS channel.

I assume I filed it in the wrong component.

• TLSA _443._tcp.www.example.com should be requested via DoH, like ESNI is requested via DoH.
  DoH seems required because Firefox doesn't seem to be able to make TLSA requests on its own.
• If an entry was received,
  • http://www.example.com should be forcibly upgraded to https.
    This solves the problem that the address bar defaults to http and that HSTS Preloading takes time and does not work for outdated browser versions.
  • the certificate of https://www.example.com must match the TLSA record and fail otherwise. It should work like HPKP.

• If an entry was received,
  • http://www.example.com should be forcibly upgraded to https.
    This solves the problem that the address bar defaults to http and that HSTS Preloading takes time and does not work for outdated browser versions.
  • the certificate of https://www.example.com must match the TLSA record and fail otherwise. It should work like HPKP.

This enhancement is essentially DANE for HTTP, but relying on DNS-over-HTTPS instead of DNSSEC.

For other applications of TLSA records checks, see: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities#Certificate_usage

Importantly, one of the use cases of TLSA records is validation of self-signed certificates (DANE-EE) or validation of certificates with a root of trust unknown to the client (DANE-TA).

(VB from comment #4)

Importantly, one of the use cases of TLSA records is validation of self-signed certificates (DANE-EE) or validation of certificates with a root of trust unknown to the client (DANE-TA).

I explicitly did not suggest that. TLSA should definitely not be used as trust anchor as it would circumvent certificate transparency. Demanding it would likely cause wontfixing this bug.

Using TLSA like HPKP is the least invasive and most safe change.
While CAA is just a wish, TLSA would allow a domain to pin to Let's Encrypt (or to leaf certificates) while enforcing https.
It should be fetched the moment the connection is established and initially have an enforced maximum TTL of 1 day, for example. Or don't cache it at all.

For other applications of TLSA records checks, see: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities#Certificate_usage

2 as 0 => let a domain pin itself to let's encrypt (like HPKP. Do not use it as non-WebPKI trust anchor.)
3 as 1 => let a domain pin its leaf ceritifcates (like HPKP)

Selector: Do not support 0 (certificate: ignore it), only support 1 (public key).
Matching type: Do not support 0 (the whole public key: ignore it), only support 1 (SHA256) and 2 (SHA512).

OK. If I understand it correctly, you propose:

implement:
PKIX-TA (0): in effect can be used as a "mandatory CAA". While CAA can not be enforced, PKIX-TA will be enforced.
PKIX-EE (1): in effect certificate pinning (HPKP)

ignore (at least for now):
DANE-TA (2)
DANE-EE (3)

Better something than nothing at all.... PKIX-TA and PKIX-EE are still big improvements over CAA and HPKP.

If tracking is a concern: Due to CSP hashes it should be possible [to add a pref] to check first party only.

(In reply to VB from comment #2)

Please reopen.

It was not fair to close this bug because Bug 672239 was WONTFIXED. Bug 672239 asked to "implement DNSSEC TLS" in the browser. But once you have DNS-over-HTTPS, you do not need to "implement DNSSEC TLS" (in the browser) in order to "check TLSA records".

It is up to DNS-over-HTTPS servers to implement DNSSEC TLS. Once they start doing that, they will deliver TLSA records to DoH clients (browsers) via DNS-over-HTTPS channel.

But the browser still needs to validate the TLSA records received over DoH with DNSSEC, so Firefox would still have to implement DNSSEC. Looking at this situation as a whole, it doesn't seem that anything has changed regarding the reasoning in comment 1 (or, more generally, that we have no plans to implement DANE).

(In reply to Dana Keeler (she/her) (use needinfo) (:keeler for reviews) from comment #8)

But the browser still needs to validate the TLSA records received over DoH with DNSSEC, so Firefox would still have to implement DNSSEC.

That's the same misunderstanding as above. It's incorrect: Cloudflare's DoH server validates DNSSEC, it's not the task of Firefox:
TLSA depends as much on correct DNS as ESNI (bug 1590863) does.
If custom DoH servers did not validate DNSSEC, a tampared A, AAAA, ESNI or TLSA record could only make a website inaccessible, but does not impose a risk as TLSA should not be used as trust anchor.

Looking at this situation as a whole, it doesn't seem that anything has changed regarding the reasoning in comment 1

I am unsure how to understand this and to learn from it:
Comment 1

• incorrectly states

  The checking of TLSA records is completely independent from DNS-over-HTTPS.

  while Firefox either needs to be able to verify DNSSEC by itself (bug 1077323/bug 1500289) or to use Cloudflare's DNSSEC-validating DoH (this bug). It missed the point what this bug was filed about.

• quoted an obsolete bug:

  Bug 672239 was WONTFIXED, and based on that I think it is fair to close this bug as well.

  bug 672600 was the last attempt to circumvent DNS by transmitting all DNSSEC material via TLS extension. This unneeded complexity was thankfully not adopted. (Nginx does not even properly support OCSP - an obstacle to must-staple.) $25,000 were burned for a technically undesirable solution.

• Firefox 57 broke https://dnssec-validator.cz/:

  I haven't checked in depth, but there shouldn't be any major problems in making the chrome extension run in Firefox as well.

  I had the same assumption, but its authors (the CZ tld) say "After struggling and failing to implement the DNSSEC/TLSA Validator extension for Firefox Quantum (57+) we've decided to stop the development and support of the extension.", so I didn't try it by myself.

(or, more generally, that we have no plans to implement DANE).

Thanks for having a look at this. That's a legitimate engineering decision for the time. I anyway assumed it would become P5.

(In reply to Dana Keeler (she/her) (use needinfo) (:keeler for reviews) from comment #8)

But the browser still needs to validate the TLSA records received over DoH with DNSSEC, so Firefox would still have to implement DNSSEC.

This is not correct. I think that real-life example is better than a thousand words. Cloudflare already does DNSSEC validation and replies to TLSA requests. You can try it yourself.

request:
curl -s -H 'Accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=_443._tcp.www.nic.cz.&type=TLSA'

reply:
{"Status":0,"TC":false,"RD":true,"RA":true,"AD":true,"CD":false,"Question":[{"name":"_443._tcp.www.nic.cz","type":52}],"Answer":[{"name":"_443._tcp.www.nic.cz","type":52,"TTL":1761,"data":"\# 35 01 01 01 a1 c4 42 88 0e b3 fd f5 ea 99 78 c3 82 1b 80 65 20 d3 97 35 cf a9 fd fb 0f c7 b5 c2 7c 67 9d b4"}]}

Please note that the TLSA record provided by www.nic.cz is PKIX-EE (not a DANE TLSA). As such it must be validated against webPKI trust anchor.

Please note that Cloudflare also sent the "AD":true flag. The Authentic Data (AD) = true flag explicitly says that the Cloudflare DoH server validated the DNSSEC records and the client (curl, Firefox, etc.) does not have to repeat the check. See this document: https://www.sidn.nl/en/knowledge-bank/centralised-dnssec-validation-on-closed-networks

Yes, "centralised DNSSEC validation" - this is what Cloudflare is doing for you. This document is pretty old, so does not mention DoH, but obviously DoH can and will be used as a solution to the "last-mile security problem" - securing exchange between the DNSSEC-validating DNS server and a client.

Just for fun, I tried to use Firefox itself for the TLSA request from Cloudflare (using console in order to modify request's headers). Of course I received the valid response, including the AD:true flag.

Bug WONTFIXED for invalid reason.
Reopening.

There is no need to implement DNSSEC validation in order to implement DANE validation.
Just need to ensure that a validating Trusted Recursive Resolver (TRR) (e.g. DoT, DoH, DoQ) is being used which does all the DNSSEC heavy lifting.
We already have TRR interface for DoH implemented, just need to use it for DANE.

To implement DANE:

1. Ensure TRR is used for DNS queries
2. Check that the TLS server FQDN DNS records are DNSSEC-valid by checking that the DNS response received from TRR has either:
   • AD bit set (see RFC 4035), or
   • AA bit set
3. Check if TLSA records exist
4. Check if TLSA records are also DNSSEC valid (check for AD/AA bit)
5. If TLS server certificate validates against any one of the returned TLSA records - pass cert validation and don't do PKIX (unless matching TLSA wants PKIX as well).

if TRR
   if FQDN is valid
      Check for TLSA over TRR
      if TLSA is valid
          validate TLS server cert against TLSA

To speed things up could do TLS ClientHello and TLSA DNS query in parallel.

In terms of complexity, this would be the easiest to implement.
Implementing this bug is a lot easier than implementing bug 672600 which actually does require DNSSEC validation code.

This bug was closed because we had no plans to implement the requested feature. We still have no plans to implement the requested feature.

Bugzilla is a tool for tracking the work we are doing or intend to do in the relatively near future. We may close bugs as WONTFIX for a number of reasons, including but not limited to insufficient applicability or utility to users and the web at large, particularly when balanced against implementation and maintenance effort. Disagreeing with these reasons or considering them invalid will not change our decision.

Also, closing a bug as WONTFIX doesn't necessarily mean it will never get fixed or has no merit. If we ever determine that a particular feature should be implemented, we may reopen a bug to track that effort.

Furthermore, bugzilla is not a discussion forum. It is not the place to discuss at length the merits of a feature. You can avail yourself to a discussion forum if you feel the need to continue arguing for this feature, but do not continue to re-open this bug.