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

From: Alberto Bertogli <[email-masked]>
Date: Wed, 4 Jan 2017 17:16:17 +0000

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?

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

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

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

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/febad008f38c9ac980a4c0a6179a7681fed7f125/
(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.

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.

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 5 Jan 2017 05:29:44 -0700

Inline:

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

>   include domain patterns in their U form (e.g. "*.ñaca.com
> <http://xn--aca-6ma.com>"), A form

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.

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

>   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"?

> reporting yet; I will add them later, but thought these questions are

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

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

---

From: Alberto Bertogli <[email-masked]>
Date: Thu, 5 Jan 2017 17:44:59 +0000

> prevent DNS injection, so it's of relatively little value.)

Ack, thanks for clarifying!

> I proably can make a quick change to clarify this if it seems reasonable to

FWIW, I'm fine with any of the options.

I think allowing both forms makes it easier to deploy, so I'd be
slightly in favour of that.  Obviously that implies that the MTAs
normalize the domains before doing the comparison, but that's not that
big of a burden, I hope.

Given the idempotency of the forms, normalizing inconditionally will
always work regardless.

But as long as it's clear, I don't feel very strongly about it :)

> https://www.ietf.org/mail-archive/web/uta/current/msg01524.html.

Interesting, I didn't know underscores in domains were not HTTP
friendly, thanks for the reference.

Why not unify them both under the "mta-sts" domain then? I see the
appeal of the similarity with things like _dmarc, but is it worth it?

> changing to SHOULD? Better to keep a "MUST"?

I think is worth changing it to SHOULD because there's no technical
reason a client must do the lookup, and seeing it as MUST may be
confusing. As you say above, a client can skip the lookup and still
behave nicely to the domains.

But it's mostly a formality, I think; I was mostly worried that there
was a strong reason behind the MUST that I wasn't seeing.

> Feel free to copy any code you like, of course, though it's a little late

Cool, I'll take a look and make sure I'm not missing anything!  The web
tool is quite handy as well, thanks for doing that :)

Thanks!
		Alberto

---

From: Daniel Margolis <[email-masked]>
Date: Fri, 6 Jan 2017 11:18:21 +0100

Thanks again for the feedback.

> But as long as it's clear, I don't feel very strongly about it :)

Right. Not a big deal either way, I agree. Your point I guess is that we
can instead just call out the possibility of IDN MXs and recommend that
everyone decode both the hostname and the "mx" property to ASCII before
comparing and we're good. I agree.

I have no complaints with adding this to the draft to make sure it's
explicit. https://github.com/mrisher/smtp-sts/issues/127 for now, and I
will try to batch this with any other changes needed.

> appeal of the similarity with things like _dmarc, but is it worth it?

*shrug*

It's fairly arbitrary. Maybe at most an issue of aesthetics.

> was a strong reason behind the MUST that I wasn't seeing.

Nope, nothing.

I'm open to feedback from anyone else reading this. As with the other
point, it's mostly aesthetic, I think (but a fair observation nonetheless).

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Jan 2017 13:08:19 +0000

> MTA would have to convert to the A form for checking. What do you think?

For domains that actually have MX records (not just implicit "domain.
IN MX 0 domain.") the MX records will already be in A-label form,
since they're the result of a DNS lookup.  Nobody should have to
convert these to U-labels just in case the domain owner's STS policy
uses unicode.  

Since domains for domains that actually receive email (not just
parked) lack of MX records is the exception and not the rule, the
same should apply to the implicit MX.  In any case the name needs
to be converted to A-label form in order to perform the lookup
that determines that there are no MX records.

So, bottom line, for simple and deterministic behaviour the mx
property must be in A-label (ASCII) form, the client must compare
A-label names against this property, and U-label forms, should not
match.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Fri, 6 Jan 2017 16:55:42 +0100

> convert these to U-labels just in case the domain owner's STS policy

The opposite, I assume--that you would convert the U-labels in the policy
to punycode before comparing to the MX records.

But as I said in my first reply, I think keeping everything A-form makes
everything easier. On the other hand, as Alberto says, simply converting
everything to A isn't that big a deal. *shrug*

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Jan 2017 16:24:19 +0000

> to punycode before comparing to the MX records.

I am suggesting that policies should not contain U-labels, and
therefore, there should be no conversion requirement.

> everything easier.

Exactly.  STS should require A-labels in the mx policy attribute.

> On the other hand, as Alberto says, simply converting

Unnecessary complexity.  The client will already have the A-label
forms of both the domain name and the MX hostnames, and should not
have to generate A-label encodings.  Nor should it have to compute
the A-label forms of the policy data.  Especially because wildcards
are not valid domain names, and U-to-A libraries may not directly
support converting these, making the code to do so a bit more complex.

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Fri, 06 Jan 2017 12:48:53 -0500

On the issue of mta-sts vs _mta-sts:

The TXT and A/AAAA records should be under the same label.

W/ or w/o an underscore *will* lead to implementors getting things wrong.

And the two always should be in the same zone, even where zone cuts exist.

It is not just aesthetics.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Alberto Bertogli <[email-masked]>
Date: Mon, 16 Jan 2017 21:59:47 +0000

> Thanks again for the feedback.

Sorry for the late reply, I was (almost) without internet the entire
week. Responses inline as usual!

> comparing and we're good. I agree.

What you're saying SGTM.

Whatever form is used (Viktor had some arguments towards A form in the
other sub thread), I think it's worth calling it out explicitly to make
it more clear to both software and policy writers, to avoid problems in
the future once policies start to appear in the wild :)

> It's fairly arbitrary. Maybe at most an issue of aesthetics.

Yes, I know it makes no functional difference, but having one record
instead of two may make some things simpler and reduce the chance of
confusion (even if it's easily detected).

Not a big deal, but just thought I'd ask.

Thanks again for being so patient and receptive to feedback!

		Alberto

---

From: Alberto Bertogli <[email-masked]>
Date: Mon, 16 Jan 2017 22:08:36 +0000

> support converting these, making the code to do so a bit more complex.

You'd be making the code more complex but the policy writing simpler, so
it wouldn't be entirely unnecessary.

Whether it is a worth tradeoff, I'm sure it's arguable :)

In any case, the main objective of my comment was to suggest that it's
worth picking an option (A/U/both) and making it explicit, to avoid
inconsistencies from appearing once implementations and policies start
to appear.

Thanks,
		Alberto