These are very interesting discussions! Last year I started thinking about email encryption policies and started writing a RFC; DTSP - Domain-based TLS SMTP Policy.
My thinking was to have a policy record (similar to DMARC) which specified encryption types for sending and receiving domains; enforcing STARTTLS basically. If anyone is interested I can share what I was working on. On 6 September 2013 13:35, Viktor Dukhovni <[email protected]> wrote: > 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 > -- Regards Andy
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
