Re: [Uta] Uta Digest, Vol 28, Issue 16

I think your thought exercise has brought you to the same place I arrived
at. ;)

Note in particular, regarding domains "too big to do DANE", that this seems
likely to be especially true for big hosting providers. In particular, as
written STS can be deployed in a DNSSEC-signed zone of customer.com to
require MXs with valid certs for host.com.

A secondary problem with in-band validation is that it may increase the
risk of an attacker turning a temporary MITM into a perma-DoS, because you
now can't require that the policy be delivered from a server who's
certificate SAN matches the email domain. In the above example, you have to
accept a policy for customer.com's email set by the MX at host.com--how do
you know host.com isn't a temporary MITM who's trying to dos customer.com?

Anyway, this is a bit of a tangent, I think, because I think we're all on
the same page, but I've been sort of meaning to write up a list of
motivating design concerns describing these sorts of corner cases that we
discovered in alternate proposals; otherwise it's easy to forget *why* X
wasn't likely to work.

Dan

On Thu, Mar 24, 2016 at 5:53 PM, Viktor Dukhovni <ietf-dane@dukhovni.org>
wrote:

>
> > On Mar 24, 2016, at 12:16 PM, uta-request@ietf.org wrote:
> >
> > In addition to the possible difficulty in migrating a domain off
> > a server (particularly in a multi-tenant config), we also felt
> > that introducing a new SMTP verb might be dramatically more complicated
> > than deploying in parallel, because at least the DNS/webpki reporting
> > can be added offline without changes to the core MTA.
> >
> > Was that not a concern in DEEP? Or simply unavoidable?
>
> Implementing a new SMTP verb is easier than parsing new DNS records
> or adding an HTTPS stack to a sending MTA.
>
> That said, an out-of-band protocol might possibly be supported via
> a mostly "generic" policy lookup interface that allows the sending MTA
> to fetch TLS policy for a delivery and report results, while
> in-band signalling might require somewhat more mechanism-specific code
> in the MTA.
>
> The key difficulty is of course doing policy revocation in-band, it is
> not obvious how to do that.  If STS is defined more narrowly as a protocol
> for sending mail to just the domains "too large to implement DNSSEC" (such
> as those of the draft's authors), then the hosting issue goes away, and
> in-band signalling works.  If STS is to cater to smaller hosted domains,
> then signalling that securely signalling that SMTP to one's domain is no
> longer secure becomes difficult without a parallel out of band secure
> channel.
>
> If STS-enabled SMTP servers were required to be able to disavow support
> for a no-longer hosted domain in-band via SMTP, that might work.  The
> client would have to signal the domain to which it wants to deliver
> email before "MAIL FROM", and the server would respond with the policy
> for that domain, or an invalidation.
>
> This would mean that the cached data for a domain would include the
> most recently seen MX hosts (not just the wildcard patterns), and
> that when new MX hosts in DNS don't match any of the cached patterns,
> a connection is made the cached ones for the purpose of a policy revocation
> check.  This sounds a bit tricky... Will the "losing" provider have
> proper incentives to make the appropriate configuration changes in a timely
> manner?
>
> --
>         Viktor.
>
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta
>