Right, I wasn't sure exactly why DANE requires DNSSEC.
DNSSEC provides assurance that the record isn't compromised.
But, SMTP works today without that assurance. If you can compromise DNS
for a host today, you can already send the mail to a compromised relay, or
one that doesn't have STARTTLS at all.
Maybe a poison DNS would allow you to not require TLS... but if it is
offered, you'd take it anyways. So, you'd have to poison DNS to remove the
DANE record and MITM the connection to remove the STARTTLS offer from the
EHLO response.... I guess this leaves "fewer" fingerprints than just
re-directing traffic? Anyone who care can log the TLS usage as easily as
the IP address, though maybe its less obvious.
Otherwise, you can provide a false DANE record which will cause a DoS
because the certs or status don't match, so the sender refuses to deliver
the message. Again, DNS compromise today can already do that by directing
the MX somewhere else or returning lookup failures.
DANE requiring DNSSEC seems to be the perfect being the enemy of the good.
The next problem with DANE is that it requires users to have an updated
enough DNS server/client that provides tools for the new RR-Type, as
opposed to the "overload the TXT record" mechanism that has been popular in
the email world recently. I know our code hasn't added support yet, though
it looks like its in recent BIND implementations. Of course, we're happy
to add support if we need it, I'm more concerned about the added
requirement for all hosts to update that... though, obviously folks would
have to update their MTA either way... well, it may be that some servers
have the ability via config to advertise things in EHLO response, but
clearly senders would need updating.
Brandon
On Mon, Jun 16, 2014 at 10:30 AM, Claus Assmann
<ietf-smtp(_at_)esmtp(_dot_)org> wrote:
On Mon, Jun 16, 2014, Tony Finch wrote:
Can't do DANE without DNSSEC. Yes there's a chicken-and-egg problem, so
Well, not according to the RFC.
However, it seems it should be possible to use the DNS records
(without DNSSEC) as additional check if so desired. Whether that
offers any value is of course a different question.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp