Date: Fri, 02 Feb 2018 07:12:55 +0000
From: Daniel Margolis <dmargolis@google.com>
To: khm@sciops.net
Cc: draft-ietf-uta-mta-sts@ietf.org
Subject: Re: draft-ietf-uta-mta-sts
    
[-- OpenSSL output follows (current time: Thu Jun 23 17:11:17 2022) --]
[-- End of OpenSSL output --]

[-- The following data is signed --]

On Thu, Feb 1, 2018 at 7:28 PM Kurt H Maier <khm@sciops.net> wrote:

> On Thu, Feb 01, 2018 at 06:05:42PM +0000, Daniel Margolis wrote:
> >
> > I may be misunderstanding you, but absent DNSSEC, it *is* necessary to
> > establish that mx.isp.net is the correct MX for example.com. Merely
> > authenticating the MX for its hostname is insufficient to prevent a
> > man-in-the-middle attack, since injecting fake MX records is a trivial
> > workaround, right?
> >
> 
> Yes, absent DNSSEC, DNS is not secured.  The objection here is that
> instead of recommending the security features of the already-involved
> DNS services, you're recommending a secondary (tertiary?) protocol that
> also does not solve the problem.  If you can inject a fake MX record,
> you can inject a fake A record, and authenticate on bad well-known data.
>

To be clear, if you inject a fake A record, the MTA-STS client will reject
the policy served because the "policy.example.com" MITM won't have a valid  
certificate for example.com. (Assuming, of course, that they don't have a  
valid certificate.) So instead of authenticating the MX records directly, 
we are in fact authenticating (via the CA signedness) the "acceptable
identities" of the MX hosts (which are themselves also required to be CA
signed).

So STS does not require trusted DNS, which is really a significant
motivator here. Any changes that did not have those same security 
properties in the absence of DNSSEC would be undesirable.

>
> > But I don't have a great answer for you beyond that, and I agree that
> it's
> > feasible to do it all with DNS, at least in concept.
>
> I beg you to consider reintroducing this as an option, even if it's just
> to serve the policy tuples.  That way we can fix the implicit TLS
> situation with SMTP and have a proper, complete solution.
>
> > Zoomed out a bit, I think the big challenge with all of this is
> > retrofitting. HTTP is in some sense easier, because it's (usually) an
> > interactive user-agent. So if you fall back to insecure (or encounter
> cert
> > problems) you can tell the user and ask them what to do. For decades, the
> > "proper functioning" of HTTPS has been basically to show the user in the
> > event of a downgrade attack (and, like, hope the user notices, which is
> > often futile).
>
> Yes, and machines are much more reliable about rejecting situations
> they've been programmed to reject.  But in this case they're not really
> being given the opportunity here; it's just getting offloaded to a
> client protocol in another stack.  SMTP already has error reporting
> mechanisms and extending with a 'needs tls' error message is trivial and
> simple.
>
> Thanks,
> khm
>

[-- End of signed data --]