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

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 24 Mar 2016 12:53:12 -0400

> On Mar 24, 2016, at 12:16 PM, [email-masked] 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.

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 24 Mar 2016 18:06:25 +0100

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 <[email-masked]>
wrote:

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: "Orit Levin (CELA)" <[email-masked]>
Date: Thu, 24 Mar 2016 18:43:49 +0000

>... 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.

Yes, please, do that! It will be very helpful!
Thanks,
Orit.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 24 Mar 2016 19:16:31 +0000

On Thu, Mar 24, 2016 at 06:06:25PM +0100, Daniel Margolis wrote:

> likely to be especially true for big hosting providers.

[ As an side, udmedia.de, transip.nl and nederhost.nl are doing
fine with hosting lots of DNSSEC customer domains with DANE-enabled
MX hosts, so I don't understand the above, but I think it is off
topic, so we can move on... ]

> certificate SAN matches the email domain.

Indeed this is fatal.  It is the same issue that faces RFC 6186 in
the absense of DNSSEC.  There is no practical way to do WebPKI
authentication of target services in the presence of unvalidated
DNS-based indirection.  Alexey's recent email certs RFC suggests
SRV-ID, but I don't see substantial support for that as likely to
happen.

> discovered in alternate proposals; otherwise it's easy to forget *why* X

In this light the well-known HTTPS URI is the glue tying the STS
policy to the domain owner in a way that works with WebPKI and
avoids DNS indirection.  Instead the STS policy constrains the
targets of the DNS indirection.

This sure ain't pretty!  I sure wish you guys would hurry up and
do DANE, but wishing it won't make it so... :-(

-- 
	Viktor.

---

From: Neil Cook <[email-masked]>
Date: Thu, 24 Mar 2016 23:27:24 +0000

> On 24 Mar 2016, at 19:16, Viktor Dukhovni <[email-masked]> wrote:
> 

I’m also wondering why all this work on a new standard, and why not just do DANE…

Neil