On Thu, Sep 05, 2013 at 02:57:24PM -0700, Ian Fette (????????) wrote:
> 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".
I am reconsidering this issue, see below:
On Sat, Apr 26, 2014 at 03:56:50AM +0000, Viktor Dukhovni wrote:
> For common vocabulary it may be helpful to read:
>
> http://tools.ietf.org/html/draft-ogud-dane-vocabulary-02
>
> Attempting to do DANE post insecurely obtained DNS Navigation (NS,
> CNAME, DNAME) or Service Specification Records (MX, SRV, ...) seems
> futile. In such a scenario is largely sufficient to just do
> unauthenticated opportunistic TLS. If there is no MiTM the outcome
> is the same, and if there is an active attack, you've likely lost
> by the time you've followed the insecure MX records.
>
> Yes, if the MX hostname is a secure zone and TLSA records exist,
> you're arguably "half-secure" if you use them, in that if the MX
> record was not forged, then DANE TLSA closes the rest of the gap.
>
> [...]
>
> About the most compelling use-case for this would be various unsigned
> mom/pop domains hosted by a large provider (say Gmail). If Gmail's
> MX RRset is some day in a signed zone, and TLSA records exist, is
> there sufficient value in enforced authentication of connections
> to Gmail when delivering email to a domain whose MX records are
> not signed?
So given that with SMTP we have an "opportunistic DANE TLS" protocol,
and that opportunistic security strives to connect to each peer
with at the advertised security capabilities of that peer, perhaps
indeed opportunistic DANE TLS with SMTP should attemt to pick up
the pieces and perform DANE authenticated delivery to MX hosts with
DNSSEC validated TLSA records, even when the MX (SSR) records were
"insecure". We don't have enough operational experience with
opportunistic DANE TLS to determine whether such a policy would
be a net gain.
We could add a "SHOULD" to encourage implementations to employ DANE
with MX hosts that "happen to have" signed TLSA RRs, even after
"insecure" MX RRs. Provided we state that this should be configurable,
and may be revised if operational experience proves it to be a mistake.
The resulting connection should not be represented as a secure
delivery to the next-hop domain, but may be *unambiguously*
represented as a secure connection to the MX host in question.
Anyone wish to support or oppose such a change in draft?
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
