Closed
Bug 1479423
Opened 6 years ago
Closed 6 years ago
support for DNSSEC/DANE/TLSA validation
Categories
(Thunderbird :: Security, enhancement)
Thunderbird
Security
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.
Comment 1•6 years ago
|
||
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
Comment 2•6 years ago
|
||
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: 6 years ago
Flags: needinfo?(mkmelin+mozilla)
Resolution: --- → DUPLICATE
Comment 3•6 years ago
|
||
(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.)
Comment 4•6 years ago
|
||
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.
Comment 5•6 years ago
|
||
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.
Comment 6•6 years ago
|
||
A pity that -- unlike https, DANE for SMTP actually sees quite a bit of deployment, both among server software and installations.
Comment 7•6 years ago
|
||
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
Comment 8•6 years ago
|
||
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.
Description
•