
Real world DNSSEC+DANE for secure inter-domain mail transport [pdf] - fanf2
https://static.ptbl.co/static/attachments/169319/1520904692.pdf
======
colmmacc
Standing reminder that friends don't let friends use DNSSEC, because it is
crazy and provides no real security. With that in mind, it's fun to dive in
and see where the problems are ...

Fundamentally this DANE idea swaps out the problems of a PKI CA hierarchy, the
kind your browser is using when you actually log into gmail to read and send
your e-mail, with the problems of DNSSEC.

The biggest problems with PKI are that there are too many CAs, who can each go
rogue, and that X509 is a horrifically awful format that takes a gigantic TCB
to parse. Mitigations include browsers firing CAs and severely impacting their
business (so effectively, there is regulation), certificate transparency and
more and more testing. Either way you pretty much have to deal with these
problems today though, an awful lot of e-mail is sent/received over HTTPS.

The biggest problems with DNSSEC are that DNSSEC doesn't actually protect DNS
queries at their most vulnerable points, that you have to trust your TLD
provider, and the root operators completely, with no effective means to fire
them, and finally that they almost certainly are using embarrassingly stupid
crypto that even most ICOs could avoid. This very deck has several 1024-bit
RSA keys, right there on a slide with a February 2018 timestamp, as if it's
not an incredibly obviously stupid thing to do since the LogJam paper was
published, or you know, when everyone stopped using them for TLS years ago.

Actually wait, there's even a 512-bit key on another slide, using alg-5.
That's RSA + SHA1!! What's the point of using all of those SHA256 MACs at the
TLS Layer if everything depends on utterly breakable RSA plus SHA1 anyway?
It's hard to take this seriously.

PS. Yes, this is also my best impression of tptacek

~~~
swiley
It's still an improvement over the way things where before (nothing at all,
and complete blind faith in every part of the DNS and internet routing) and
arguably better than CA which isn't that useful for email.

Furthermore, the browsers replace the TLD in who you trust with CAs and in
many cases it's practically difficult (or impossible) to "fire" your browser.

I will agree that no one seems to use good crypto with DNSSEC though. The only
people I know using it are using 512 bit RSA which is pretty horrifying.

~~~
gruez
>it's practically difficult (or impossible) to "fire" your browser.

You can reconfigure your trust store, and you can distrust a CA in a few
clicks.

~~~
tptacek
Not only that, but Firefox and Chrome have "fired" some of the largest, "most
important" CAs on the Internet. We know there's no TBTF problem with the Web
PKI. But there is literally no way to fire a DNS TLD operator. In this scheme,
they are _prêt-à-porter_ TBTF.

~~~
Nullabillity
> We know there's no TBTF problem with the Web PKI.

Hardly.

Comodo is still around, and Symantec took years to be gradually distrusted.
Hell, even the WoSign/StartSSL debacle started in Jan 2015, and they weren't
removed before Jan 2017.

~~~
jcranmer
The WoSign issues became public around early September 2016 (maybe last week
of August):
[https://wiki.mozilla.org/index.php?title=CA:WoSign_Issues&ac...](https://wiki.mozilla.org/index.php?title=CA:WoSign_Issues&action=history)

~~~
gruez
not to mention that wosign came out in early 2015.
[https://news.ycombinator.com/item?id=8982013](https://news.ycombinator.com/item?id=8982013)

------
zokier
Would adopting web-style security model really be that horrific for email too.
By that I mean that the servers would have private keys & certificates
matching the domains of recipient addresses[1] and using SNI to solve
vhosting. Sure, most mail providers might not be equipped to do so right now,
but it is hardly an impossible thing to ask for.

[1] Heck, if you are really clever then you could also ask sending server to
present a (client) certificate matching the sender address domain.

~~~
ietf-dane
Why is SMTP not like the web:
[https://tools.ietf.org/html/rfc7672#section-1.3](https://tools.ietf.org/html/rfc7672#section-1.3)

~~~
zokier
Yes, I've read that and disputing if the things mentioned there are really
such blockers. I was specifically referring to the point 1.3.2 in my
suggestion to use "envelope recipient domain" for verification as I really do
not see it as impractical as the RFC supposes

