Re: [Uta] New proposal: SMTP Strict Transport Security

[Daniel Margolis <[e-mail]>]

Hi Viktor,

Thanks for all the thoughtful comments. I'll respond to what (at a glance)
seems to be the most significant three first.

On Tue, Mar 22, 2016 at 7:35 AM, Viktor Dukhovni <[e-mail]>
wrote:

>     A significant obstacle to a successful roll-out of WebPKI with
>     SMTP is not such much that obtaining and deploying CA certs is
>     onerous (enabling DNSSEC is likely more difficult at present),
>     but rather that there is no single set of CAs that sending and
>     receiving systems can (or perhaps should) reasonably agree on.
>     On the one hand, because MTAs employing STS are non-interactive
>     background processes with no human-operator in the loop to
>     "click OK" for each exception, the set of CAs a sending system
>     that employs STS would need to trust would need to be "comprehensive
>     enough" to include all the CAs used by all the domains one
>     might need to send email to.


This is of course a big topic, but I don't think we should assume that in
common deployment web browsers *do* rely upon a user to make some sound
human decision about whether to trust a CA. For example, here's the
multi-stage process to get Chrome to accept an untrusted certificate:
https://docs.oracle.com/cd/E24628_01/install.121/e39876/img/scrnshot_advanced.gif.
It's not insignificant to me that Oracle felt the need to document this
process for the users with screenshots: we *don't* expect the common
browser user to make a personal determination of what CAs to accept, so the
"background process" argument is, I think, based on a false premise.

In truth, we expect browser users to defer to their platform vendors to
make sane decisions for them, and we expect the owners of large websites to
be able to pick a CA that is widely trusted. With the rise of Let's Encrypt
and other free CAs, this doesn't seem overly burdensome.


    This requires domains that publish STS records to duplicate
>     their MX records in the STS RRset.  It is not clear why that's
>     useful.  If the STS record itself is not DNSSEC-validated, the
>     payload is not more secure than the MX RRset.  If the payload
>     is DNSSEC-validated, then the MX RRset in the same zone would
>     (barring unexpected zone cuts) be equally secure.  I posit that
>     this field is both onerous and superfluous.


There are two differences with the MX records here:

1. A (most likely) longer TTL on the STS policy versus the MX record
2. The option for wildcard's or broader patterns than merely a list of
valid hosts

This permits the publishing domain to declare that "for the next year, I
plan to always host my mail at example.com" without publishing specific MX
records that have a 1-year TTL (which of course could be brittle).


    It would be expensive for MTAs to attempt repeated HTTPS
>     connections that timeout trying to connect to port 443 at
>     the majority of domains which have not deployed STS.
>
>     All that's needed in DNS to support a pure WebPKI STS is a
>     boolean value to signal the existence of the STS resource URI.
>     This data can be obtained efficiently.  If the "_smtp-sts" RR
>     exists (pick a suitable RRtype and fixed short payload) then
>     the HTTPS URI should be consulted, otherwise the HTTPS URI is
>     not consulted (at first contact), or is consulted asynchronously,
>     in parallel with the first mail delivery (with appropriate spacing
>     between probes, ...).
>
>     Thus some MTAs might compress the STS DNS record to zero bits,
>     and just use asynchronous suitably spaced HTTPS probes to the
>     domains for which no policy is presently known.  However the
>     1-bit encoding is likely better.
>

I also dislike the copying of the policy into two places, for the reasons
Dave noted here:
https://mailarchive.ietf.org/arch/msg/ietf-smtp/nqWeUTe03mxJLltC-wHOsVvfbKo
.

The only real reason to do this is to allow MTAs to cheaply see if the
policy has been updated. This seems like a silly thing, since in normal
usage they never need to check as long as they have a cached policy, but
it's exactly that asymmetry that worries me: Since in normal usage the
traffic to the HTTPS endpoint will be minuscule compared to the SMTP
traffic to the domain, hosts are likely to dramatically underprovision the
former versus the latter. Unfortunately, then, in the case of a validation
*failure*, the HTTPS endpoint would (absent some other policy TTL separate,
and shorter from, the expiration lifetime) be bombarded with an HTTP GET
*once* *per* email.

So all we're really doing here (in the webpki case) is leveraging DNS as a
sort of caching layer. An alternative solution would be what I hinted at
above: to simply embed a short "TTL" in the policy. Or to say we don't care
and encourage the use of HEAD.

If we are willing to force the webpki validation method (as you assumed, I
think, above) and don't mind making senders handle this short-term TTL
logic,  I think we could make the publishing process simpler, with the
advantage Dave noted in the above-linked thread (i.e. an easier deployment
for customers of hosted mail services).

I'm somewhat on the fence about this trade-off myself, but I don't think
it's unreasonable. Thoughts?