Protocol Action: 'SMTP MTA Strict Transport Security (MTA-STS)' to Proposed Standard (draft-ietf-uta-mta-sts-21.txt)

The IESG <iesg-secretary@ietf.org> Mon, 18 June 2018 03:17 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Protocol Action: 'SMTP MTA Strict Transport Security (MTA-STS)' to Proposed Standard (draft-ietf-uta-mta-sts-21.txt)
Auto-Submitted: auto-generated
Precedence: bulk
Cc: draft-ietf-uta-mta-sts@ietf.org, The IESG <iesg@ietf.org>, uta-chairs@ietf.org, uta@ietf.org, Leif Johansson <leifj@sunet.se>, alexey.melnikov@isode.com, leifj@sunet.se, rfc-editor@rfc-editor.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <152929187137.2060.10326188122221250679.idtracker@ietfa.amsl.com>
Date: Sun, 17 Jun 2018 20:17:51 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-announce/1wSP3QSgym5L-sgjgkfPPQu_SeQ>

The IESG has approved the following document:
- 'SMTP MTA Strict Transport Security (MTA-STS)'
  (draft-ietf-uta-mta-sts-21.txt) as Proposed Standard

This document is the product of the Using TLS in Applications Working Group.

The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/




Technical Summary

   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.

Working Group Summary

   The WG had a hard time aligning on the format of MTA-STS policy
   and initially had chosen JSON as the format. Strong push-back from
   parts of the opensource community led to a change to key-value text
   based format. The consensus is strong on the new format but the path
   there was a bit rough. There is still too little understanding of 
   how SNI is deployed in the email domain to warrant clear normative
   language on the use of SNI. Security directorate review may change
   this a bit but probably not much. The WG consensus is to leave the
   language as is in the draft.

Document Quality

   There are multiple implementations on the protocol and major email-
   providers (eg google) are already deploying the protocol as specified.  
   There are indications that major opensource implementations of MTAs
   will implement the protocol.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

  Leif Johansson (document shepherd)
  Alexei Melnikov (AD)


RFC Editor Note

In Section 3.2, in the ABNF:

sts-policy-field         = sts-policy-version /      ; required once
                           sts-policy-mode    /      ; required once
                           sts-policy-max-age /      ; required once

                           sts-policy-term /
                           ; required at least once, except when
                           ; mode is "none"

                           sts-policy-extension      ; other fields


Please change "sts-policy-term" to "sts-policy-mx"

In the same section, also change:

OLD:

sts-policy-mx-value      = ["."] Domain

NEW:

sts-policy-mx-value      = ["*."] Domain


In Section 3.4:

OLD:  This specification does not provide a means of associating
      policies with addresses that employ Address Literals [RFC5321].

NEW: s/with addresses/with email addresses/

Protocol Action: 'SMTP MTA Strict Transport Secur… The IESG