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