Subject: [Uta] Suggestion for minor MTA-STS improvement

From: Alice Wonder <[email-masked]>
Date: Tue, 6 Nov 2018 07:51:50 -0800

Hi,

I know MTA-STS provides an alternative to DANE for SMTP and does not 
require DNSSEC.

However when the zone is protected by DNSSEC there could be an improvement.

All the specification of mode and ttl in DNS - could be done in existing 
TXT record or an additional TXT record.

This would allow discovery of MTA policy even if the web server was 
unavailable due to DDoS or server mis-configuration.

The premise being the MX record can be trusted in DNSSEC signed zones if 
the sending MTA uses a DNSSEC enforcing resolver (as many do, that's the 
default for unbound)

The web server component should obviously still be required for a 
receiving domain to be MTA-STS compliant because not all sending clients 
have the ability to validate DNSSEC but it would add some robustness to 
MTA clients that do, as well as saving them a https request if the 
MTA-STS policy mode and ttl is specified in DNS.

I apologize if this suggestion has already been discussed and rejected. 
My intent is not to rehash old discussions.

Alice Wonder

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 6 Nov 2018 14:24:36 -0500

> On Nov 6, 2018, at 10:51 AM, Alice Wonder <[email-masked]> wrote:
> 

I think you're trying to say that the presence of a DNSSEC-validated
_mta-sts.example.com TXT record all by itself could obviate the need
for an MTA-STS policy, because the MX RRset at "example.com" will
then also be DNSSEC-validated, and does not require out-of-band
HTTPS security, and the TXT record can signal a commitment to
WebPKI-verifiable certificates at the MX hosts.

Is that right?

If so, I don't recall this being discussed, it is of course too late
to add this to the already published RFC.  If this idea has support,
it could become a separate draft.  The main obstacle is that "testing"
in the HTTPS policy would no longer be seen.  If that remains important
to publishers, we'd need an additional (otherwise optional)
"mode=testing|enforce" in the TXT record too, that would be used only
if the TXT record is DNSSEC-validated, but otherwise ignored.

Basically, this would move the substance of the policy from HTTPS
to DNSSEC, and caching, ... become unnecessary, because DNSSEC reliably
delivers fresh data.

For DNSSEC-signed domains that self-host mail, publishing DANE TLSA
records is an even better option, but many DNSSEC-signed domains
have third-party MX hosts in unsigned domains.

-- 
	Viktor.

---

From: Alice Wonder <[email-masked]>
Date: Tue, 6 Nov 2018 14:49:59 -0800

> WebPKI-verifiable certificates at the MX hosts.

Yes. If I understand MTA-STS correctly, the purpose of the https 
component is to mitigate fraudulent MX records, policy mode, and time to 
live. Using DNSSEC to mitigate shouldn't be required, I respect the 
right for some system administrators to choose not to trust it, but I 
think it simplifies MTA-STS for system administrators who do trust it.

> to DNSSEC, and caching, ... become unnecessary, because DNSSEC reliably

I think caching may still be a good idea in case a the records are 
modified resulting in validation error.

> have third-party MX hosts in unsigned domains.

Yes, AFAIK google doesn't publish TLSA records (gmail anyway shows as 
untrusted in postfix log unless I specify a smtp_tls_CApath) and 
provides MX for a lot of companies.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 6 Nov 2018 17:58:30 -0500

> On Nov 6, 2018, at 5:49 PM, Alice Wonder <[email-masked]> wrote:
> 
> Yes. If I understand MTA-STS correctly, the purpose of the https component is to mitigate fraudulent MX records, policy mode, and time to live. Using DNSSEC to mitigate shouldn't be required, I respect the right for some system administrators to choose not to trust it, but I think it simplifies MTA-STS for system administrators who do trust it.

This proposal makes some sense.  Don't know whether it can get broader support,
but I for one am not opposed.  It even aligns with Jim Fenton's REQUIRETLS
draft, which combines DNSSEC + WebPKI authenticated MX hosts under similar
conditions, but the policy is triggered by sender request, not a signal
from the receiving domain.

> I think caching may still be a good idea in case a the records are modified
> resulting in validation error.

Here I disagree, or misunderstand your point.  With a fresh DNSSEC-validated
TXT record, there seems to be little reason to cache, and you even get
downgrade protection on first contact.  What you don't get is defense from
compromise of any of the all too many WebPKI CAs, and the weak DV domain
verification they perform.  But if that's all that's available, it is better
than nothing.

-- 
	Viktor.

---

From: Alice Wonder <[email-masked]>
Date: Tue, 6 Nov 2018 15:05:15 -0800

> verification they perform.  But if that's all that's available, it is better

Okay, I defer to your expertise and better grasp of the issues.

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 7 Nov 2018 10:41:29 +0100

I don't think we discussed exactly that issue. We did entertain early on
the idea of having the policy in a TXT record instead of via HTTPS, but
moved to HTTPS for the obvious reasons.

I do think the observation that you don't really even need the policy
(except for the "mode" switch) in the event of DNSSEC validation is cool.
But I'm not sure what to do with it. A new draft, as Viktor says?

Sorry. Not a very constructive response. I think you have a very good
point. I don't know if I would pursue it simply due to the additional
complexity, however. In particular, it seems to only apply in the case
where the MX is on a zone that can't/won't do DNSSEC but the mailbox domain
does do DNSSEC (thus DANE doesn't work). This isn't necessarily uncommon
(as small domains hosting their mail on e.g. GSuite may be in exactly such
a situation), but if that's the primary application, maybe the "reverse
proxy" method is in fact just as easy, no?

On Wed, Nov 7, 2018 at 12:05 AM Alice Wonder <[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: Viktor Dukhovni <[email-masked]>
Date: Wed, 7 Nov 2018 10:36:05 -0500

On Wed, Nov 07, 2018 at 10:41:29AM +0100, Daniel Margolis wrote:

> In particular, it seems to only apply in the case
> does do DNSSEC (thus DANE doesn't work).

Yes, and there are millions of domains in this bucket.

> This isn't necessarily uncommon

Well, the reverse proxy still imposes a small burden on the receiving
domain, but perhaps the main benefit would be for sending MTAs,
which could get both stateless MTA-STS functionality (no cache to
maintain for the DNSSEC-signed domains that include a "mode" in
ther signed text record) and downgrade protection on first contact.
The WebPKI vs. DANE/DNSSEC roots of trust are then the final
distinction between this hypothetical model and DANE.

Not sure whether this half-way point between MTA-STS and DANE
warrants standardizing with a view to broad implementation.  It
rather depends on whether the dominant MX-hosting providers will
over the next 5-10 years gradually also get DNSSEC signed and enable
DANE or not.
 
-- 
	Viktor.

---

From: Alice Wonder <[email-masked]>
Date: Wed, 7 Nov 2018 08:07:46 -0800

On 11/07/2018 01:41 AM, Daniel Margolis wrote:

> where the MX is on a zone that can't/won't do DNSSEC but the mailbox 
> domain does do DNSSEC (thus DANE doesn't work).

It may also be of benefit to zones that use DNSSEC but who want to 
automate Let's Encrypt certificate renewal. Automation of LE renewal is 
tricky when the private key changes so often because you have to have a 
new fingerprint in TLSA before it goes into service.

It's possible to script LE to not change the private key, but then you 
end up with a private key that isn't rotated as often as it should be.

So they may simply not want to publish the TLSA records that DANE 
requires even if they theoretically could. But MTA-STS would work fine 
with them, it doesn't break with automated cert renewal including fresh 
private key.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 7 Nov 2018 11:13:24 -0500

> new fingerprint in TLSA before it goes into service.

FWIW, I've reached out to the certbot maintainers, and we may see
some improvement in that space before too long.  That is, certbot
may get updated to explicitly support TLSA records, by automatically
rotating keys in a TLSA-safe manner.  This is already possible with
some local scripting, but the goal is to make that a built-in feature
of certbot.

-- 
	Viktor.