On Thu, Sep 05, 2013 at 06:17:55PM -0700, Ian Fette (????????) wrote:
> However, I've yet to hear a good argument for why one
> would ignore information not protected by DNSSEC. In the case of a TLSA
> record for HTTPS/443 I understand, I don't understand why one would ignore
> that information for SMTP/25.
As an MTA developer, I can't think of anything useful I can do with
an unauthenticated TLSA record, that I don't already get with
STARTTLS.
Recall that TLSA records for SMTP are published for the MX hosts
only, not the domain. Some of the MX hosts for a domain may support
DANE TLSA, others might not. SMTP is very different from HTTP.
So even if see long TTL TLSA RRs for a domain's MX hosts one day,
a different MX RRset the next day (e.g. cutting over to an MX
provider) gives no reason to expect TLS on the new MX hosts.
HTTP security is *not* dependent on DNS in the same way, if you
trust the public CA PKI, the DNS just provides IP addresses, which
must land on a TCP service with the right certificate. This is
simply not the case with SMTP.
If I am conveying his views correctly, of the things Ben Laurie
likes about HTTP with certificate transparency, is that it is in
fact largely immune to attacks on DNS. With SMTP, once DNS is
compromised there's not much one can do.
Sure, companies with known high value business partners can configure
static policy enforcing TLS for those destinations, and the current
Postfix TLS policy engine is in large part in support of that model.
The DANE support in Postfix aims to get beyond that scale, to the
Internet at large. Predicated on the assumption that DNSSEC is
not a dead-end, and will over the next few years see broad adoption,
as management tools and client to registry/registrar interfaces
mature.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
