Subject: [Uta] Last Call: <draft-ietf-uta-mta-sts-15.txt> (SMTP MTA Strict Transport Security (MTA-STS)) to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 09 Apr 2018 08:03:11 -0700

The IESG has received a request from the Using TLS in Applications WG (uta)
to consider the following document: - 'SMTP MTA Strict Transport Security
(MTA-STS)'
  <draft-ietf-uta-mta-sts-15.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2018-04-23. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

   SMTP Mail Transfer Agent Strict Transport Security (MTA-STS) is a
   mechanism enabling mail service providers to declare their ability to
   receive Transport Layer Security (TLS) secure SMTP connections, and
   to specify whether sending SMTP servers should refuse to deliver to
   MX hosts that do not offer TLS with a trusted server certificate.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/ballot/

The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/2776/

---

From: [email-masked]
Date: Tue, 10 Apr 2018 17:30:45 -0700 (PDT)

I have finally found the time to work on my own implementation of MTA-STS.
As is often the case when actually implementing the specification, it
has turned up a number of issues of varying levels of severity, which
I'm listing in no particular order.

(1) Both RFC 7405 and RFC 5234 should be mentioned in the terminology section.

(2) The ABNF production field-delim appears in the definition of MTA-STS TXT
    records and policies, with different values. I suggesting renaming the
    former to sts-field-delim and the latter to sts-policy-field-delim,
    to match the naming conventions for other productions.

(3) Section 3.1 contains this example:

      "_mta-sts.example.com.  IN TXT "v=STSv1; id=20160831085700Z;""

    Do we really need/want the outer quotes here? (Note that this is not
    inlined in the text, where the quotes would be required.)

(4) Section 3.1 does not contain an explicit statement of what to do if the
    selected TXT record is syntactically invalid. I think this is another case
    where no policy should be assumed, so how about changing:

         If the number of resulting records is not one, senders MUST assume the
         recipient domain does not implement MTA-STS and skip the remaining
         steps of policy discovery. 

    to:

         If the number of resulting records is not one, or if the resulting
         record is syntactically invalid, senders MUST assume the recipient
         domain does not implement MTA-STS and skip the remaining
         steps of policy discovery. 

(5) The production:

    sts-ext-value   = 1*(%x21-3A / %x3C / %x3E-7E)
                         ; chars excluding "=", ";", and control chars

    refers to "control chars", which AFAIK is not a well-defined. RFC 5234
    defines CTL for this purpose, so this should be changed to "and CTLs".

    SP was removed from the list of prohibited stuff in this text in
    -15. Why? Space is still excluded by the actual production, and itbs
    not thought of as a control character.

    I hope the intent is not to allow stuff like:

      v=STSv1; id=20160831085700Z; foo=bar1 bar2;

    And if it is, the ABNF needs further work because there is now
    an ambiguity regarding trailing spaces and the *WSP thatbs allowed
    at the end of a parameter value.

(6) Section 3.2:

         Parsers MUST accept TXT records and policy files which are
         syntactically valid (i.e. valid key/value pairs separated by semi-
         colons for TXT records) and but containing additional key/value pairs
         not specified in this document, in which case unknown fields SHALL be
         ignored. 

    "records) and but containing" -> "records), possibly containing"

(7) Itbs probably too late to change this, but the "mx" key name is misleading
    at best: It has nothing whatsoever to do with MX records. Rather, it
    specifies a set of certificate identities SMTP servers for the domain
    are constrained to use. Indeed, nothing prevents mta-sts from being used
    with a domain whose server is identified by an A record - with no MX record
    in sight.

    And perhaps more to the point, therebs no alignment between MX record
    values and these key values, but this key name makes the reader think
    there is.

    At a minimum there needs to be a note making it clear that the MX
    host names are not involved in the policy check. It would probably
    also be good to say that "MX host" is simply a host designated to
    handle mail for a given domain, which may or may not be the result
    of MX record processing.

(8) The policy resource ABNF mandates CRLF as the line terminator.
    Unfortunately, this is just not HTTP reality - line terminators are
    going to be whatever was used in the file being served out, and I
    donbt think mandating that people use CRLFs in these files is realistic.
    As such, the ABNF needs to be changed to at least allow LF, and probably
    CR, terminators. Something like:

    sts-policy-term = CR / LF / CRLF

    And then use this throughout the rest of the ABNF instead of CRLF.

(9) The production:

    sts-policy-ext-value     = 1*(%x21-3A / %x3C / %x3E-7E)
                                ; chars, excluding "=", ";", SP, and
                                ; control chars

    has the same issue with "control chars" noted in (5). Additionally,
    whatbs the point of excluding ";" and "="? Unlike TXT records, they
    have no special meaning as delimiters here. If anything youbd want to
    exclude ":", but I see no point in doing that either.

    I also note that this production excludes SP (and unlike sts-ext-value,
    the language about it has been retained). This seems overly restrictive to
    me, so perhaps changing this to something like:

    sts-policy-ext-value = %x21-7E [*(%x20-7E) %x21-7E]
                            ; chars, excluding CTLs and no
                            ; leading/trailing spaces

    It also may be worth considering allowing UTF-8 in extension values.
    Once the syntax rules are set theybre very difficult to change.

(10) The production for mx values:

     sts-policy-mx-value      = 1*(ALPHA / DIGIT / "_" / "-" / ".")

     seems overly lax to me, especially since the DNS-ID fields being
     compared against are constrained to valid domain syntax. Rather
     than once again specifying productions for a domain, I would
     suggest importing the definition of Domain from RFC 5321. This
     then becomes:

     sts-policy-mx-value      = ["."] Domain
     Domain                   = <see RFC 5321 4.1.2>

(11) For completeness, section 3.4 should contain a note about the handling
     of domain literals. I suggest "this specification does not provide a
     means of associating policies with address that employ domain literals"
     or something stronger.

That's it for now. I should note that my implementation is incomplete, and
I expect I will have more comments once I've worked through the SMTP
client additions.

				Ned