Re: [Uta] MTA-STS - Questions on implementing the latest (02) draft

[Daniel Margolis <[e-mail]>]

Inline:

On Wed, Jan 4, 2017 at 10:16 AM, Alberto Bertogli <[e-mail]>
wrote:

>
> Hi! Happy new year!
>
> I had some time during the holidays and started to do a basic
> implementation of the latest MTA-STS draft.
>
> While doing so, there were a couple of things I wasn't sure about so I'd
> thought I'd ask:
>
> - What happens if the "mx" field is missing from the policy?
>   Should the MTA skip checking the field but honour the rest of the policy,
>   treat the policy as invalid, or assume no MX is valid?
>

The "mx" field is required, so if it is missing, the policy is invalid and
should not be honored. (It doesn't make sense to honor the policy anyway, I
would say, since a policy without allowed MXs is essentially a way of
saying, "There should be TLS and the server identity should match the MX,
whatever the MX is." I guess this prevents SSL stripping, but doesn't
prevent DNS injection, so it's of relatively little value.)


> - For the case of an internationalized domain name, the "mx" field should
>   include domain patterns in their U form (e.g. "*.ñaca.com
> <http://xn--aca-6ma.com>"), A form
>   ("*.*.xn--aca-6ma.com"), or both can be present?
>

I suppose this is underspecified in the draft!

I would say based on https://tools.ietf.org/html/rfc6125#section-6.4.2 that
it makes the most sense for this to be in the A-form, since otherwise the
MTA would have to convert to the A form for checking. What do you think?

I proably can make a quick change to clarify this if it seems reasonable to
those on this list.


> - The TXT record is on "_mta-sts" but the policy is on "mta-sts". Is that
>   intentional? Why not putting both on the same domain, to simplify things?
>

Yes, this is intentional. The underscore in "_mta-sts" was kept to be
similar to that in (e.g.) _dmarc TXT records, but for the HTTP host this
seemed inadvisable:
https://www.ietf.org/mail-archive/web/uta/current/msg01524.html.


>
> - The draft says that clients MUST check the TXT record, but it seems to me
>   it's totaly possible to make a reasonable implementation without doing
> so.
>   Is it worth using "MUST" for this?
>   I imagine this is related to the previous discussion we had, but
>   forcing MTAs to check seemed quite strong so I was wondering if
>   there was something else.
>

I think there's some utility in specifying this as at least a SHOULD so as
to ensure common behavior--otherwise, a recipient domain that updates its
HTTP but not TXT will work some of the time for some senders, I guess? That
seems risky.

But need it be a MUST? Probably not. The truth of the matter is, as you
say, that nobody would really know (except from slightly higher request
rates) if your implementation did HTTP-only. ;)

I'm open to making this a SHOULD, but it's not something I have a strong
feeling about one way or another. What do you (and others) think--worth
changing to SHOULD? Better to keep a "MUST"?


>
>
> Thanks!
>                 Alberto
>
>
> In case you're curious, the implementation I have so far is at
> https://blitiri.com.ar/git/r/chasquid/b/sts/, in particular
> https://blitiri.com.ar/git/r/chasquid/c/febad008f38c9ac980a4c0a6179a76
> 81fed7f125/
> (patch and branch are subject to rebasing).
>
> It's mostly fetching, parsing and checking. It has no caching or
> reporting yet; I will add them later, but thought these questions are
> independent anyway.
>

I feel slightly bad for not having shared this earlier, but I wrote a toy
implementation here: https://github.com/danmarg/smtp-sts. As with yours, it
does not do caching or reporting; I wrote it merely to power this:
http://sts.x.af0.net.

Feel free to copy any code you like, of course, though it's a little late
for that. ;)


>
> The integration into the MTA itself will come later too, but I expect it
> to be roughly similar to the integration into the smtp-check tool, which
> is included.
>
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>