Let's say that you want to know a-priori if an email will be sent over TLS.
Three german companies are doing this already ("Email made in germany"
campaign between web.de, gmx, and t-online) where they show their users
distinguishing UI if the mail is being sent "securely". It's an interesting
to see how that would work out, and personally I find it a very difficult
UI challenge to communicate something meaningful that won't be
misinterpreted, but anyhow... (2) gives you a signal that you could
potentially pass on to a user, and then the user can potentially make a
decision about whether or not they want to send the email. I think it needs
a bit more thinking and UX studies as to whether or not this is a good
idea, but having a signal like that does enable such use cases.It also provides a signal that services can potentially cache as to whether the recipient believes their STARTTLS support is reliable or not. E.g. if we see such a record and don't see STARTTLS, we may decide to bounce (or hold) the message until we see STARTTLS again. If we've seen that record and it disappears as well as STARTTLS support disappearing, that might be a stronger signal that there's a potential MITM attack or strangeness than simply seeing STARTTLS disappear alone. Basically, it's extra information, which opens up a few possibilities, and although it doesn't itself prevent an active MITM who is capable of DNS cache poisoning, it does provide extra information for use in heuristics and doesn't "hurt". On Thu, Sep 5, 2013 at 2:29 PM, Andrew Sullivan <[email protected]>wrote: > On Thu, Sep 05, 2013 at 02:17:39PM -0700, Ian Fette (イアンフェッティ) wrote: > > > 1. Ignore it and do what you would have done had you not seen the TLSA > > record (per the DANE spec) > > 2. Ignore the fact that it's lacking DNSSEC and treat it as "I should > only > > send mail over TLS and expect the following cert" > > Why do you think (2) provides any advantage over (1)? If someone is > actually in a position to MITM your SMTP connections, surely spoofing > the odd TLSA record is going to be pretty easy, no? The only > protection you have in that case is DNSSEC, I think? > > Best, > > A > > > > -- > Andrew Sullivan > [email protected] > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane >
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
