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

[Daniel Margolis <[e-mail]>]

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, <[e-mail]> 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.
> 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
>
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>
>