Closed Bug 1479423 Opened 2 years ago Closed 2 years ago

support for DNSSEC/DANE/TLSA validation

Categories

(Thunderbird :: Security, enhancement)

enhancement
Not set
major

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 672600

People

(Reporter: vtol, Unassigned)

Details

core capabilites for DNSSEC/DANE/TLSA validation are absent from core and apparently not being developed by Mozilla bug #672600

This obviously impacts TB and thus lacking a major security (enhancement) feature.

There are various and viable pros for implementing DNSSEC/DANE/TLSA validation and perhaps the TB team would consider to develop such.
Version: 60 → Trunk
Is https://www.getdnsapi.net/releases/ in a state that it could be integrated?

I suspect we don't have staff to do this, and so we probably need to hang our hats on bug 672600.
Dup to bug 672600?
Flags: needinfo?(mkmelin+mozilla)
Summary: support for DNSSEC/DANE/TLSA validation → support for DNSSEC/DANE/TLSA chain stapling validation
Looks to me there is nothing Thunderbird specific here. It's all just bug 672600, and that nobody has yet implemented it for mozilla yet. ("not beeing developed by mozilla" - well afaikt, they would take a patch)
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Flags: needinfo?(mkmelin+mozilla)
Resolution: --- → DUPLICATE
Duplicate of bug: 672600
(Thanks to the patches for ESNI and DoH it should be easier to get support for regular TLSA records. Then you could rely on validation by the DoH server or of an own dns server.)
This is NOT a dupe, and retitling was wrong.  There's a massive difference between DANE validation and DANE _stapling_.

The former drastically increases security, making many forms of government-sponsored MitM impossible.  The latter merely removes the need for Let's Encrypt like CAs.

The former does a DNS query, the latter passes DNS-like data in the TLS stream.  An attacker who can subvert any of hundreds of roots or thousands of CAs can take over the SSL cert security theatre, and simply not pass any stapled DANE.  On the other hand, DNSSEC means that without a NSEC (ie, signed end of chain) the tampering is evident.
It's a dupe in that this is not the kind of thing Thunderbird does. We inherit all this kind of code from Firefox. If it gets into there, we may have minor modifications to do, but better file a bug at that time if needed.
A pity that -- unlike https, DANE for SMTP actually sees quite a bit of deployment, both among server software and installations.
I'm sure your help in bug 672600 will be appreciated
Summary: support for DNSSEC/DANE/TLSA chain stapling validation → support for DNSSEC/DANE/TLSA validation
bug 672600 is worse than OCSP. More complexity in the web server and another chunk of external C (legacy) code in Firefox.
Latency concerns led to that concept, but DNS-over-HTTPS and ESNI are worse, so there should be no problem to request regular TLSA records via DoH, and maybe even locally. Firefox shouldn't need to care about DNSSEC, the DoH server validates.

I filed bug 1450674 about it, but it was temporarily closed because of (clear) misunderstanding.
He mentioned bug 672239, but that was offtopic because Firefox shouldn't need to care about DNSSEC.

We might need to try to implement it by ourselves. Somewhere between OCSP checking and Safebrowsing.
Often they want to do other cool things like this, but haven't got the time for that. A good and working WIP patch might be enough.
You need to log in before you can comment on or make changes to this bug.