Re: [Uta] Eric Rescorla's Discuss on draft-ietf-uta-mta-sts-17: (with DISCUSS and COMMENT)

[Daniel Margolis <[e-mail]>]

Hey Eric,

Thanks for the valuable comments. I've responded to most of them here:
https://mozphab-ietf.devsvcdev.mozaws.net/D4010. The revision containing
fixes can be seen at https://github.com/mrisher/smtp-sts/pull/220. (I will
let another author review my changes before merging and submitting a new
official draft.)

Comments I was unable to resolve:

* https://mozphab-ietf.devsvcdev.mozaws.net/D4010#inline-3713: How do you
suggest we clarify the terminology ("host" and "Policy Domain")?
* https://mozphab-ietf.devsvcdev.mozaws.net/D4010#inline-3716: Any
suggestions on clarifying that any max-age is valid?

I think there are two larger comments unresolved here, as well:

1. Certificate revocation (and "MAY"). My read on this is that revocation
is not widely mandated (e.g. popular Web browsers don't necessarily do it
using standard mechanisms!), some mechanisms (e.g. OCSP) don't provide the
security guarantees we would want, and so this is too muddied a space to
mandate specific behavior. As Viktor noted, some MTA developers may be very
opposed. My preference here is somewhat strongly to leave this as-is, for
those reasons.

2. Why is the "mx" pattern matched against the SANs and not the MX records
themselves? As Viktor noted and I commented briefly in passing, we debated
this a *lot* before. One point here is that this is only visible to MTA
implementors; sysadmins who mistakenly believe the "mx" field should match
the DNS records (which should themselves match the servers' certificates)
will end up making their configurations valid per the actual specification.
In other words, "match the policy against the SAN" matches a superset of
conditions which are valid in the alternative ("match the policy against
the MX records and match those records against the certificate").
Personally I would consider this edit to have been a compromise--it was not
and is still not my first choice--but, given it is the status quo, I am
fairly loath to change it.

On these points--especially #2--I continue to defer to the guidance of the
chairs on how best to resolve such issues.

Hope that helps. More feedback is welcome.

On Fri, May 4, 2018 at 3:14 AM Eric Rescorla <[e-mail]> wrote:

> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>