Subject: [Uta] SMTP STS Draft feedback

From: Ángel González <[email-masked]>
Date: Thu, 12 May 2016 03:27:00 +0200

Hello everyone

I had been meaning to study these drafts and provide feedback on them
to the group, but didn't get to it until today.

It's possible that I missed something that had already been discussed,
since I did not read the whole archive, only the mails for last weeks.

Here are the issues/proposals I identified about brotman-mta-sts-00
draft:

Section 3 shows an example pattern of «["_.example.com",
"_.example.net"]», but it is not allowed by the grammar of 3.1.2.
Similarly for ["*.mail.example.com"] of section 9.1

I suppose the "_.example.com" were actually intended to be
"*.example.com", as I see no use of such underscores in rfc6125. The
grammar should be amended accordingly.
Additionally, I would make the 6.4.3.3 MAY of rfc6125 a MUST wrt the mx
policy. Many mx hostnames use a naming with variable parts inside the
label, and specifying an optional matching here helps noone.

Additionally, per Postel's law I'd add text akin to
«A lenient parser SHOUlD accept a policy file which is valid json<ref>
implementing a superset of this specification, in which case unknown
values SHALL be ignored.» just for being future-proof on the file
format.

Section 3.2.1 says «Recipients thus can expect a policy to be used…» I
propose changing it to «Recipients should thus expect that the policy
will continue to be used by senders until both…»

On section 3.3, please uppercase both words: s/MUST not/MUST NOT/

On section 6 I would change "by redirecting client connections to
the legitimate recipient server" to "by redirecting client connections 
that were meant to the legitimate recipient server" in order to 
make it less ambiguous.

Currently, the spec requires the generation of a report in "report"
mode whenever the policy is changed (eg. changing your mx in
report mode means that every -sts conforming- server that knows you
will sent you a report telling you that, even though it'd be ok in
enforce mode).

Actually, I miss the ability of having both enforce and report enabled 
for a domain. (Albeit you _could_ have tlsrpt records to receive
aggregate records, this glueing is still not clear, awaiting section
4). report mode is actually like an extra verbose reporting mode, but
is probably better put in an orthogonal way.

Also related to section 4 I dislike that after trying so hard to have a
secure policy (based on caching, etc), as the reporting is defered to
tlsrpt, it could be MITM again. It would be appropriate to
(optionally?) store the record in the policy, too. But then we'd be
duplicating the record.

Going back to the main sts content, I also miss at least a
justification in the document about the choice of the subdomain for
"policy._mta_sts.example.com".
In addition to the point that "it is not a hostname" raised by John,
the usage of a fourth-level domain would probably cause issues:

1) With dns panels that don't allow creating subsubdomains. I have seen
several instances of this, not allowinjg them at all or requiring
kludges like hosting a website in the subdomain then removing it (and
given the special nature of _mta_sts.example.com, that's probably not
available).

2) It requires a specific certificate just for this subdomain. This
involves approval for the expenditure, that your CA supports the new
label, etc. Just a subdomain would allow simply using your wildcard
certificate.

Thus, for this I would settle on connecting to _mta_sts.example.com,
even if that's not strictly "legal", it's similar enough it should
work. The risk of delegated subdomains is too high IMHO.

Best regards

PS: You probably have alread noticed, but there seem to be two lines
joined on line 214 of tlsrpt

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 12 May 2016 00:47:36 -0400

> On May 11, 2016, at 9:27 PM, Ángel González <[email-masked]> wrote:
> 

Yes, there is inconsistent editing, the draft is in flux.

> grammar should be amended accordingly.

"*.example.com" would not be a good syntax to use, it is too easily
confused with the wildcard syntax on the server-certificate side.
This is a client-side wildcard that is semantically different.

A better syntax would be ".example.com" to indicate any proper
sub-domain of example.com.  No leading "*" or "_".

-- 
	Viktor.

---

From: Ángel González <[email-masked]>
Date: Thu, 12 May 2016 09:50:27 +0200

> sub-domain of example.com.  No leading "*" or "_".

As long as the optional part of rfc6125 is changed to compulsory, I see
no problem. We would be using the same rules as certificates (actually
a superset than what is implemented in webpki), and I don't think
anyone would be misled by what the * really means (except perhaps for
the can't-cross-dots rule). Much easier than underscores in fact.
I see value in allowing a restricted wildcard of mx*.dyndns.com rather
than *.dyndns.com
Of course, some examples should be added so implementors don't forget
about these cases (from which they would hopefully find their way into
testsuites).

Best

---

From: Daniel Margolis <[email-masked]>
Date: Fri, 13 May 2016 13:59:45 -0700

Thanks!

> grammar should be amended accordingly.

Yep, this was a bug in the Markdown input we are using to generate the XML
(which interpreted the '*' as emphasis, apparently). Good catch!

> label, and specifying an optional matching here helps noone.

Hmm, that's a bit funny. I dislike having to specify behavior that deviates
from 6125. Why is that a MAY in the original?

> values SHALL be ignored.» just for being future-proof on the file

Agreed.

> will continue to be used by senders until both…»

That's a nice wording. Thanks.

> On section 3.3, please uppercase both words: s/MUST not/MUST NOT/
Done.

> that were meant to the legitimate recipient server" in order to

Done.

> the usage of a fourth-level domain would probably cause issues:

Yes, I've removed the underscores in the github copy. The reason we wanted
to make it a subdomain was to make it a bit harder for cases like tumblr,
wix, dyndns, etc, to be abused. But this may outweight the downsides you
describe; I'm not really wedded to this.

We could change this in the WG redrafting.

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

---

From: Vladimir Dubrovin <[email-masked]>
Date: Sat, 14 May 2016 00:25:37 +0300

Daniel Margolis пишет:
> Thanks!
>
> On Wed, May 11, 2016 at 6:27 PM, Ángel González <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Section 3 shows an example pattern of «["_.example.com
>     <http://example.com>",
>     "_.example.net <http://example.net>"]», but it is not allowed by
>     the grammar of 3.1.2.
>     Similarly for ["*.mail.example.com <http://mail.example.com>"] of
>     section 9.1
>
>     I suppose the "_.example.com <http://example.com>" were actually
>     intended to be
>     "*.example.com <http://example.com>", as I see no use of such
>     underscores in rfc6125. The
> Yep, this was a bug in the Markdown input we are using to generate the
> XML (which interpreted the '*' as emphasis, apparently). Good catch!
>  

Same issue is with all sections names, e.g.

_Future_ _Work_
_Security_ _Considerations_

-- 
Vladimir Dubrovin
@Mail.Ru