Subject: [Uta] General question on draft-ietf-uta-mta-sts-03

From: <[email-masked]>
Date: Thu, 30 Mar 2017 09:22:04 +0000

After reading the MTA-STS drafts, and following the discussions, there's still a question that I do not fully understand.

Why using DNS to "announce" the use of MTA-STS but rely on HTTPS for publishing the policy? So far, the policy is not that complex.
Wouldn't a DNS TXT record suffice in many cases?
I understand that in some cases the policy may be longer, depending on how many MX records a domain may have.
Fetching the policy from an HTTPS service could be an option for those who require longer policy descriptions.
Another option for longer policies could be to add an 'include' parameter, like in SPF, therefore avoiding the need of another service (HTTPS) to deliver the policy.

It may not simplify the work for the implementation of MTA-STS (fetching from HTTPS would still have to be implemented), but it would make it easier to deploy (I think).

As example, the TXT records could look like:

MTA-STS just DNS:
_mta-sts.example.com IN TXT "v=STSv1; id=20173003110000Z; mode=enforce; mx=*.example.com; max_age=12345600"

MTA-STS with  DNS and HTTPS:
_mta-sts.example.com IN TXT "v=STSv1; id=20173003110000Z; use=https"

MTA-STS with  DNS and 'include':
_mta-sts.example.com IN TXT "v=STSv1; id=20173003110000Z; max_age=12345600 include=_mta-sts01,_mta-sts02;"
_mta-sts01.example.com IN TXT "mx=mx1.example.com,mx2.example.com;"
_mta-sts02.example.com IN TXT "mx=*.example1.com;"

Gerard Draper Gil

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 30 Mar 2017 14:45:14 +0200

Hi,

The point is not to allow larger policy bodies but rather to leverage
existing authentication of HTTPS server certificates. We want *some form* of
authentication for two reasons:

1. We want it to be relatively hard to induce a DoS (as discussed in
"Security Considerations"); requiring a policy to be authenticated helps
mitigate that risk slightly. (Otherwise we're creating a variant of the
inject-a-bad-MX-record DoS but with a really long TTL!)

2. More importantly, we want to allow recipient domains to update a policy
on demand, outside of expirations, so that they can signal a new MX is
trusted (and similar).

The authentication mechanism need not be HTTPs, and in fact when I started
drafting this originally I suggested we just stick the policy + signature +
cert chain in a DNS record--but that implies big DNS records, and that
people figure out how to fetch and validate them plus the whole cert chain,
and ultimately, using HTTPS just seemed a lot easier and well-understood
than that.

Hopefully that makes sense, but I will note that there are some slight
relevancies for the parallel thread going on about SAN vs MX host
matching--namely that the motivator for HTTPS (to leverage well-understood
existing protocols) is also an argument for host matching, as Alberto has
pointed out.

Dan

On Thu, Mar 30, 2017 at 11:22 AM, <[email-masked]> wrote:

> After reading the MTA-STS drafts, and following the discussions, there's
> still a question that I do not fully understand.
>
> Why using DNS to "announce" the use of MTA-STS but rely on HTTPS for
> publishing the policy? So far, the policy is not that complex.
> Another option for longer policies could be to add an 'include' parameter,
> like in SPF, therefore avoiding the need of another service (HTTPS) to
> deliver the policy.
>
> It may not simplify the work for the implementation of MTA-STS (fetching
> from HTTPS would still have to be implemented), but it would make it easier
> to deploy (I think).
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>
>