Thanks for your response, Dan. Comments inline.
On 10/19/18 10:40 AM, Daniel Margolis wrote:
Hey Jim,
I've been too busy to follow along on REQUIRETLS closely,
unfortunately, so I may be missing some context. Feel free to ignore:
One caveat on your last statement is that, /alone/, you cannot assume
the certificate will validate the MX. A significant number (some data
points here:
https://static.googleusercontent.com/media/research.google.com/de//pubs/archive/43962.pdf
<https://static.googleusercontent.com/media/research..google.com/de//pubs/archive/43962.pdf>)
of MXs present certs that do not match their hostname.
So it sounds like what you are proposing is that if REQUIRETLS is
true, the MX MUST present a cert which is non-expired/chains to a
trusted CA/is valid /for the hostname in the MX/, which will fail a
meaningful amount of time in the wild. That may or may not be desired
behavior.
Yes, or alternatively the certificate MUST be validated by DANE for that
hostname. That is desired behavior, and I realize that it currently
fails a meaningful amount of time in the wild. Not long ago, email
STARTTLS negotiation failed a meaningful amount of time as well.
At the risk of derailing the conversation, I can think of the
following broad options on /authentication:/
1.. Specify nothing, as in the status quo. REQUIRETLS only means
"STARTTLS" and says nothing about checking MX authentication. Upside:
simplicity; punts on the (already complex) question of authentication.
Downside: risk of active MITM.
Given that a lot of the attacks on STARTTLS are active attacks
(interfering with STARTTLS negotiation), an active MITM seems like it
should be part of our threat model.
2. REQUIRETLS also means the MX records must have DNSSEC and the
hostnames must match the identity presented by the (valid,
signed-by-a-trusted-CA) MX. Upside: authenticates the MX. Downside:
yet another specification on MX identity (though one which is
compatible with MTA-STS, which imposes the same constraint on
certificates); imposes requirements additional to both MTA-STS
(requires DNSSEC) and DANE (requires a CA).
If the destination domain has MTA-STS, DNSSEC isn't required because the
MTA-STS policy (which in turn is served by an authenticated server) can
be used to confirm that the MX record hasn't been forged. The MX record
needs DNSSEC if MTA-STS isn't available.
3. REQUIRETLS also means MTA-STS /or/ DANE. Upside: compatible with
existing protocols, authenticates the MX. Downside: maybe complexity
(requires sending MTAs--optionally?--support both protocols).
Close, but this conflates two issues: (1) making sure that the MX record
hasn't been forged (which MTA-STS or DNSSEC in the mailbox domain will
do) and authenticating the mail server (which the certificate chain or
DANE in the mail server's domain will do).
4. REQUIRETLS also means the MX MUST present a cert which is
non-expired/chains-to-a-trusted-CA /and/ is valid /for the mailbox
domain/ (after the @). Upside: Super simple and authenticates the MX;
pushes the ecosystem in a (IMO) mostly sane direction. Downside: sort
of an additional requirement to MTA-STS or DANE; won't work for some
scenarios (e..g. hosted mail).
This represents a large change to legacy behavior. The identity the
certificate matches always represents the hostname of the mail server,
not that of the mailbox domain. As you point out, this doesn't scale for
hosted mail, which I consider to be a showstopper.
4 seems to me to be the simplest to reason about ("validate my MTA!")
but the least realistic. 3 seems reasonable enough to me. 2 seems
pretty barbaric (force MX admins to understand three protocols?!). 1
seems reasonable to me.
tl;dr: I'd probably keep the status quo. At risk of overengineering,
REQUIRETLS could also imply either DANE or MTA-STS, but, in my
opinion, not /merely /DNSSEC.
Hopefully my answers to each of your options clarifies what I think we
want to do here, but feel free to follow up if I'm not being clear enough.
-Jim
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
