Eric Rescorla has entered the following ballot position for draft-ietf-uta-mta-sts-17: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4010 DETAIL S 3.3. > character '*' as the complete left-most label within the > identifier. > > The certificate MAY be checked for revocation via the Online > Certificate Status Protocol (OCSP) [RFC6960], certificate revocation > lists (CRLs), or some other mechanism. Why is revocation only MAY? S 4. > 1. That the recipient MX supports STARTTLS and offers a valid PKIX- > based TLS certificate. > > 2. That at least one of the policy's "mx" patterns matches at least > one of the identities presented in the MX's X.509 certificate, as > described in "MX Certificate Validation". This doesn't seem like quite what you want. Consider the case where the STS policy has: S 5. > as though it does not have any active policy; see Section 8.3, > "Removing MTA-STS", for use of this mode value. > > When a message fails to deliver due to an "enforce" policy, a > compliant MTA MUST NOT permanently fail to deliver messages before > checking for the presence of an updated policy at the Policy Domain. What exactly does this mean? That you have to do HTTPS or just do a new DNS resolution despite the TTL? S 8.2. > to the hosting organization. This can be done either by setting the > "mta-sts" record to an IP address or CNAME specified by the hosting > organization and by giving the hosting organization a TLS certificate > which is valid for that host, or by setting up a "reverse proxy" > (also known as a "gateway") server that serves as the Policy Domain's > policy the policy currently served by the hosting organization. What certificate do I expect in this case? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- S 1. > > o whether MTAs sending mail to this domain can expect PKIX- > authenticated TLS support > > o what a conforming client should do with messages when TLS cannot > be successfully negotiated It would be nice if you stated here that you publish them in the DNS. S 3.2. > > The policy itself is a set of key/value pairs (similar to [RFC5322] > header fields) served via the HTTPS GET method from the fixed > [RFC5785] "well-known" path of ".well-known/mta-sts.txt" served by > the "mta-sts" host at the Policy Domain. Thus for "example.com" the > path is "https://mta-sts.example.com/.well-known/mta-sts.txt";. This is slightly confusing text, because domains and hosts aren't distinguished categories. I'm not sure what the correct terminology is for DNS, but the point seems to be that you get it by prepending the mta-sts label to the policy domain. S 3.2. > path is "https://mta-sts.example.com/.well-known/mta-sts.txt";. > > When fetching a policy, senders SHOULD validate that the media type > is "text/plain" to guard against cases where webservers allow > untrusted users to host non-text content (typically, HTML or images) > at a user-defined path. All parameters other charset=utf-8 or Nit: "other than" S 3.2. > charset=us-ascii are ignored. Additional "Content-Type" parameters > are also ignored. > > This resource contains the following CRLF-separated key/value pairs: > > o "version": (plain-text). Currently only "STSv1" is supported. What does "plain-text" mean? I don't see a definition, S 3.2. > o "max_age": Max lifetime of the policy (plain-text non-negative > integer seconds, maximum value of 31557600). Well-behaved clients > SHOULD cache a policy for up to this value from last policy fetch > time. To mitigate the risks of attacks at policy refresh time, it > is expected that this value typically be in the range of weeks or > greater. What if I receive a policy with a lifetime less than that remaining in the previously received policy S 3.2. > > indicates that mail for this domain might be handled by any MX with a > certificate valid for a host at "mail.example.com" or "example.net". > Valid patterns can be either fully specified names ("example.com") or > suffixes (".example.net") matching the right-hand parts of a server's > identity; the latter case are distinguished by a leading period. If How many labels can be prepended here. Is "a.b.c.example.net" valid? S 3.3. > is duplicated, all entries except for the first SHALL be ignored. If > any field is not specified, the policy SHALL be treated as invalid. > > 3.3. HTTPS Policy Fetching > > When fetching a new policy or updating a policy, the HTTPS endpoint You probably need a 2818 citation here. S 4.1. > The certificate presented by the receiving MX MUST chain to a root CA > that is trusted by the sending MTA and be non-expired. The > certificate MUST have a subject alternative name (SAN, [RFC5280]) > with a DNS-ID ([RFC6125]) matching the "mx" pattern. The MX's > certificate MAY also be checked for revocation via OCSP [RFC6960], > CRLs [RFC6818], or some other mechanism. Why isn't this required? S 4.1. > identical to other common cases of X.509 certificate authentication > (as described, for example, in [RFC6125]). Consider the example > policy given above, with an "mx" pattern containing ".example.com". > In this case, if the MX server's X.509 certificate contains a SAN > matching "*.example.com", we are required to implement "wildcard-to- > wildcard" matching. If you follow my advice above, this will not be necessary. S 8.1. > may be unable to discover that a new policy exists until the DNS TTL > has passed. Recipients should therefore ensure that old policies > continue to work for message delivery during this period of time, or > risk message delays. > > Recipients should also prefer to update the HTTPS policy body before Do you mean SHOULD? S 8.1. > continue to work for message delivery during this period of time, or > risk message delays. > > Recipients should also prefer to update the HTTPS policy body before > updating the TXT record; this ordering avoids the risk that senders, > seeing a new TXT record, mistakenly cache the old policy from HTTPS. Wouldn't it be easier to just to version the policies? S 10.2. > mode, to allow clean MTA-STS removal, as described in Section 8.3.) > > Resistance to downgrade attacks of this nature--due to the ability to > authoritatively determine "lack of a record" even for non- > participating recipients--is a feature of DANE, due to its use of > DNSSEC for policy discovery. I'm surprised that you don't note that if you use DNSSEC (and the client validates), you are in general resistant to this form of attack. _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
