Subject: [Uta] REQUIRETLS and MX spoofing

From: Jim Fenton <[email-masked]>
Date: Wed, 17 Oct 2018 21:48:57 -0700

On 8/23/18 6:49 PM, Viktor Dukhovni wrote:
> This is recognized in the Security Considerations:
>     Another active attack involves the spoofing of DNS MX records of the
>     recipient domain.  An attacker having this capability could cause the
>     message to be redirected to a mail server under the attacker's own
>     control, which would presumably have a valid certificate.  REQUIRETLS
>     does not address this attack.
>
> Might it not make sense to close this hole and require one of MTA-STS
> or DANE?  This delays the practical deployment of REQUIRETLS (yes) to
> such time as at least of one MTA-STS or DANE is generally present, but
> I think this is better than leaving the above security gap unaddressed.
>

In my latest draft, I dismissed this comment, apparently after not 
reading it carefully enough. I considered requiring DANE for the 
destination server to be enough of a deployment hurdle that I thought it 
would fatally inhibit REQUIRETLS deployment. But I didn't consider the 
possibility of MTA-STS here.

The idea, of course, is that the MTA-STS policy specifies the 
hostname(s) of mail server(s) for the domain, and therefore a spoofed MX 
would be detected (and the mail would not be sent, as a result).

But I don't think DANE is necessary, except that it requires DNSSEC 
(although Viktor has pointed out to me, off-list, that DANE deployment 
is trivial compared with the effort to DNSSEC sign a domain). What we're 
trying to counter is MX spoofing for the destination domain, and DNSSEC 
is sufficient for that. Once we have found the correct MX hostname(s) to 
send the message to (which if course could be in a different domain), 
the certificate, verified using either DANE or the certificate chain, 
would be sufficient to authenticate the server to which the message is 
being sent.

How does the WG feel about this? Should I add a requirement for the 
destination to have either MTA-STS or DNSSEC, or leave the "MX hole" as 
is, documented?

-Jim

---

From: Daniel Margolis <[email-masked]>
Date: Fri, 19 Oct 2018 19:40:36 +0200

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

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.

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

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

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

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.

Dan

On Thu, Oct 18, 2018 at 6:49 AM Jim Fenton <[email-masked]> wrote:

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

-- 
How's my emailing? http://go/dan-email-slo

---

From: Jim Fenton <[email-masked]>
Date: Fri, 19 Oct 2018 11:44:19 -0700

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

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

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 22 Oct 2018 11:46:27 +0200

On Fri, Oct 19, 2018 at 8:44 PM Jim Fenton <[email-masked]> wrote:

> I've been too busy to follow along on REQUIRETLS closely, unfortunately,
> so I may be missing some context. Feel free to ignore:
>
> 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.
>
>
> 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.
>

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

True. So you could rephrase this as "(MTA-STS *or* DNSSEC on the MX
records) *and* (CA-signed certs *or* DANE on the MX hosts)". (MTA-STS also
requires CA-signed certs, of course.) But this feels like a somewhat weird
matrix for an admin to understand how to satisfy, no?

> non-expired/chains-to-a-trusted-CA *and* is valid *for the mailbox domain* (after
> requirement to MTA-STS or DANE; won't work for some scenarios (e..g. hosted
> mail).
>
>
> 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.
>
>
> REQUIRETLS could also imply either DANE or MTA-STS, but, in my opinion, not *merely
> *DNSSEC.
>
>

I guess you are proposing the modified version of #3 I described above?

It definitely solves the security problems you describe (assuming *both* DNSSEC
and the CA system are trustworthy), but it feels quite complex to me. I
don't have a real good solution for how to resolve that, though.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 22 Oct 2018 18:02:44 -0400

> matrix for an admin to understand how to satisfy, no?

After thinking this over, I too can live with a "REQUIRETLS=YES"
that uses:

    * DANE when the MX RRset is signed, and the MX host has
      TLSA records.  But otherwise,
    * Web PKI cert when the MX RRset is signed, but no
      DANE TLSA records are published.  But otherwise,
    * MTA-STS when the domain's MX RRset is unsigned.  Else,
    * Failure

The idea being that STARTTLS stripping is already addressed by
"REQUIRETLS=YES", and a DNSSEC-signed RRset addresses MX record
forgery, so that remains is authentication, and if TLSA records are
not published, if we're willing to accept with MTA-STS which only
protects the MX RRset after first contact, we should be willing to
accept WebPKI for DNSSEC-signed MX records.

This creates an asymmetry of policy mechanisms between TLS policy
from the server, and TLS policy from the client, slightly complicating
MTA implementations, but it looks manageable.

And yet, my preference would have been to not take this approach.
Rather each domain that wants to support "REQUIRETLS=YES", would
need to implement MTA-STS or DANE.  If they already have a signed
MX RRset, they could often just add TLSA records and have DANE for
little extra effort.

The "fly in the ointment" is that many domains are signed, but their
MX providers are not, and so they would then have to implement
MTA-STS, just to benefit from protection against MX record forgery
that they already have by virtue of DNSSEC.

Therefore, for now, perhaps Jim's compromise is about right.

There are ~9 million DNSSEC signed domains, but as yet only ~334
thousand have DANE MX hosts, but a large fraction are hosted by
providers with WebPKI certs (just ~1 million on redirect.ovh.net
alone...).

-- 
	Viktor.

---

From: Jim Fenton <[email-masked]>
Date: Tue, 23 Oct 2018 14:05:23 -0700

>      * MTA-STS when the domain's MX RRset is unsigned.  Else,

That's basically the idea, but I'd want to describe it in a way that 
makes it clearer when we're talking about the mailbox domain and when 
we're talking about the mail server (MX provider) domain.

> MTA implementations, but it looks manageable.

I don't quite grasp the asymmetry. Perhaps in the situation where the 
mailbox domain has DNSSEC but not DANE and the mail server domain has DANE?

> that they already have by virtue of DNSSEC.

Let's think about that case more. If the mailbox domain is DNSSEC-signed 
(so we got the right MX host), shouldn't it be sufficient for the mail 
server to authenticate itself with a certificate that chains up to a 
trusted CA? I don't see why MTA-STS is needed in this case.
> providers with WebPKI certs (just ~1 million on redirect.ovh.net

Thanks, Viktor.

Chairs: Let me know when you determine that we have rough consensus and 
I'll revise the draft.

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 23 Oct 2018 17:09:41 -0400

> On Oct 23, 2018, at 5:05 PM, Jim Fenton <[email-masked]> wrote:
> 
> Let's think about that case more. If the mailbox domain is DNSSEC-signed (so we got the right MX host), shouldn't it be sufficient for the mail server to authenticate itself with a certificate that chains up to a trusted CA? I don't see why MTA-STS is needed in this case.

You've missed my point, we're in agreement.  What I was saying was
that *without* your proposal to let DNSSEC suffice, in the absence
of DANE for the hosting provider's MX host (if the MX host is in-house
the domain could easily also deploy DANE) a signed domain would then
need MTA-STS, but that's a silly requirement, because it just poorly
adds back what the domain already has, namely protection against MX
forgery.

-- 
	Viktor.

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 24 Oct 2018 08:50:42 +0300

Hi Jim,

> Chairs: Let me know when you determine that we have rough consensus and

I believe we're very close to consensus here. But the I-D submission window is already closed 
anyway. When it's already open we'll declare the consensus. So, if someone has different opinion
on the topic, please speak up until the window is open.

Regards,
Valery.

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 24 Oct 2018 14:59:51 +0200

I don't disagree with the points made here. If you know you need TLS from
REQUIRETLS, and you know the desired MX identity from DNSSEC on the MX
records, you don't need DANE or MTA-STS as long as you can validate the
presented certificates. But note now that there are three (??) ways a
recipient domain can be validated for a sender who honors REQUIRETLS. As a
result, "ability to satisfy REQUIRETLS" is no longer a property of the
mailbox domain; it depends on *both* the recipient and the sender. For
example--assuming everyone has implemented REQUIRETLS--users of Yahoo may
find that they can set REQUIRETLS on mail sent to Yandex, but users of Zoho
may find they cannot. This is a somewhat poor user experience, though
admittedly probably what the user wants.

I would call this out in the draft. I think the UX concerns here are worth
noting, and they are in fact magnified (a trade made for more widespread
compatibility, of course) but supporting multiple authn mechanisms.

---

From: Jim Fenton <[email-masked]>
Date: Wed, 24 Oct 2018 10:36:51 -0700

Let me make sure I have the issue straight: A user who uses REQUIRETLS 
from a location (or going through a downstream mail server) that doesn't 
do DNSSEC verification will not be able to send to domains that don't 
publish MTA-STS. Is that correct?

I agree, it makes sense to call this out. But also that this is probably 
what the user wants: in a way, not being able to send messages under 
some circumstances is a "feature" of REQUIRETLS.

-Jim

On 10/24/18 5:59 AM, Daniel Margolis wrote:
> I don't disagree with the points made here. If you know you need TLS 
> from REQUIRETLS, and you know the desired MX identity from DNSSEC on 
> the MX records, you don't need DANE or MTA-STS as long as you can 
> validate the presented certificates. But note now that there are three 
> (??) ways a recipient domain can be validated for a sender who honors 
> REQUIRETLS. As a result, "ability to satisfy REQUIRETLS" is no longer 
> a property of the mailbox domain; it depends on /both/ the recipient 
> and the sender. For example--assuming everyone has implemented 
> REQUIRETLS--users of Yahoo may find that they can set REQUIRETLS on 
> mail sent to Yandex, but users of Zoho may find they cannot. This is a 
> somewhat poor user experience, though admittedly probably what the 
> user wants.
>
> I would call this out in the draft. I think the UX concerns here are 
> worth noting, and they are in fact magnified (a trade made for more 
> widespread compatibility, of course) but supporting multiple authn 
> mechanisms.
>
> On Tue, Oct 23, 2018 at 11:09 PM Viktor Dukhovni 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     > On Oct 23, 2018, at 5:05 PM, Jim Fenton <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     > Let's think about that case more. If the mailbox domain is
>     DNSSEC-signed (so we got the right MX host), shouldn't it be
>     sufficient for the mail server to authenticate itself with a
>     certificate that chains up to a trusted CA? I don't see why
>     MTA-STS is needed in this case.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 24 Oct 2018 22:37:42 +0200

Exactly right on both counts. It's quite probably working as intended, but
it *is* a strange user experience. I think the only alternatives (similar
to my original email) would be to not do authn at all or to dictate one
specific mechanism for authn, neither of which are obviously better. So I
would personally support calling it out in the draft as something to be
aware of.

On Wed, Oct 24, 2018 at 7:37 PM Jim Fenton <[email-masked]> wrote:

> from a location (or going through a downstream mail server) that doesn't do
> DNSSEC verification will not be able to send to domains that don't publish
> MTA-STS. Is that correct?
>
> what the user wants: in a way, not being able to send messages under some
> circumstances is a "feature" of REQUIRETLS.
>
> -Jim
>
>> DNSSEC-signed (so we got the right MX host), shouldn't it be sufficient for
>> the mail server to authenticate itself with a certificate that chains up to
>> a trusted CA? I don't see why MTA-STS is needed in this case.
>>
> Uta mailing [email-masked]://www.ietf.org/mailman/listinfo/uta
>
>