SMTP Require TLS Option
draft-ietf-uta-smtp-require-tls-09

All DISCUSSes were cleared and this is now ready to be approved.

There is one incorrect substitution in the document that I corrected with an RFC Editor note.

[Ballot comment]
Thank you for resolving my Discuss points!

I do think the added text in Section 4.2.1 about DNS-ID/CN-ID should
probably be clarified that it only applies to the RFC 6125 procedures and
not the RFC 7672 ones.

[Ballot discuss]
I'm glad that we were able to come to consensus to rename the header
field to "TLS-Required"; that addresses a key concern of mine.

I  also appreciate the addition of the "Policy Conflicts" section that portrays
a fairly clear picture of the interaction between this mechanism, DANE, and
MTA-STS.  I still wish that we were able to bring the technologies into greater
alignment and not need to convey the sense that standards-track mechanisms
are in conflict with each other, but cannot justify blocking publication based
solely on that desire.
In this space, though, I do request an additional wording tweak in Appendix A.2,
which currently states "The TLS-Required header field is used when the sender
of the message wants to override the default policy of the recipient domain to
require TLS." which uses the "override" terminology without couching it as a
request.  Can we reword to include "request" here as well?

The following paragraph (unchanged from my ballot on -07) received only minimal
discussion so far:
I'm also concerned about the apparent new burden placed on senders in
Section 4.3 to actively decide whether every outgoing message requires
end-to-end TLS protection or is safe to forward without TLS ("when TLS
is to be required, [...].  When TLS is not to be required, [...]"), where both
"[...]" require new behavior not present in a client that does not implement
this specification.  To some extent this is an editorial matter of how the
new mechanisms are portrayed, but I don't see much in this document to justify
the stance that the default "don't care" option should be removed (for clients
that implement this specification at all).

It seems that we are in agreement that it's okay to have a "don't care" option,
which is indicated by not using the extension at all.  That said, I still think that
the specific text of Section 4.3 conveys an impression that there is a requirement
to actively decide, with the language about "has the authority to decide whether to
require TLS", "when TLS is  to be required", "when TLS is not to be required", and
"in either case, the decision [...] MAY be done based on [...]".  Perhaps I'm just misreading
the text, but I haven't seen any signals to that effect yet.  I'd suggest (but am open
to further refinement" changing to "has the option to decide whether to require TLS"
and "if one of these cases is selected, the decision [...]" as a way to clarify the language used.

[discussion of "de facto part of the core SMTP spec" removed, on  indications
that this is not the intent]

We had some good discussion about the three potential cases for authenticating
the TLS connection:
(1) Dane per RFC 7672
(2) MTA-STS per RFC 8461
(3) DNSSEC-validated MX records + WebPKI authentication of the MX hosts

I think a little more specificity is needed for the (3) case; we do say to use
the RFC 6125 procedures but still need to specify (e.g.) that the DNS-ID name
type is used and (IIRC) that the hostname resulting from the MX lookup is
used as the DNS-ID to be validated.

[Ballot comment]
[original comment section unchanged; contents likely to be stale]

Section 2

  o  The certificate presented by the SMTP server MUST either verify
      successfully in a trust chain leading to a certificate trusted by
      the SMTP client or it MUST verify successfully using DANE as
      specified in RFC 7672 [RFC7672].  For trust chains, the choice of
      trusted (root) certificates is at the discretion of the SMTP
      client.

I don't see how this requirement restricts the presented end-entity
certificate so as to eliminate the attacks that exploit "the lack of server
authentication by the client".  What does certificate have to name in order
to be trusted by the client?

Section 4.1

  Upon receipt of the REQUIRETLS option on a MAIL FROM command during
  the receipt of a message for which the return-path is not empty
  (indicating a bounce message), an SMTP server MUST tag that message
  as needing REQUIRETLS handling.

What processing should happen when REQUIRETLS is received and the
return-path *is* empty?

          If the REQUIRETLS MAIL FROM parameter is specified, the
  RequireTLS header field MUST be ignored but MAY be included in onward
  relay of the message.

How could this scenario arise?  (Why is it not a user error to attempt to
use both -- isn't one requiring TLS and the other disclaiming its use,
making them mutually incompatible?)

Section 4.2.1

  2.  If the server lookup is accomplished via the recipient domain's
      MX record (the usual case) and is not accompanied by a valid
      DNSSEC signature, the client MUST also validate the SMTP server
      name using MTA-STS as described in RFC 8461 [RFC8461]
      Section 4.1.

What happens if this validation fails?  Perhaps the below text "If any of
the above fails" could include "(including MTA-STS validation)" for extra
clarity.

  3.  Open an SMTP session with the peer SMTP server using the EHLO
      verb.

  4.  Establish a TLS-protected SMTP session with its peer SMTP server
      and authenticate the server's certificate as specified in
      [RFC6125] or [RFC7672] as applicable.

"STARTTLS" does not appear in here anywhere.
Separately, is this combination of steps going to preclude any setups that
(e.g., via preconfiguration) go straight to TLS with no STARTTLS
negotiation?

What name is used as input to certificate validation (for the 6125 branch)?
Is Appendix B.4 therein supposed to be normative?  (The Appendix B header
indicates that the content is non-normative.)

Section 4.2.2

  Some SMTP servers may be configured to require STARTTLS connections
  as a matter of policy and not accept messages in the absence of
  STARTTLS.  A non-delivery notification MUST be returned to the sender
  if message relay fails due to an inability to negotiate STARTTLS when
  required by the server.

This is an "inability to negotiate" combined with a rejection of
non-STARTTLS, right?

Section 5

  The path from the origination of an error bounce message back to the
  MAIL FROM address may not share the same REQUIRETLS support as the
  forward path.  Therefore, users requiring TLS are advised to make
  sure that they are capable of receiving mail using REQUIRETLS as

nit: "requiring TLS for outgoing mail"?

  If a REQUIRETLS message is bounced, the server MUST behave as if
  RET=HDRS was present as described in [RFC3461].  If both RET=FULL and
  REQUIRETLS are present, the RET=FULL MUST be disregarded and MAY be
  transformed to RET=HDRS on relay.  The SMTP client for a REQUIRETLS

If the MAY is not taken, will the next hop be obligated to detect that this
is a bounce and apply the preceding MUSTs?  If not, perhaps this also
should be a MUST?

  bounce message uses an empty MAIL FROM return-path as required by
  [RFC5321].  When the MAIL FROM return-path is empty, the REQUIRETLS
  parameter SHOULD NOT cause a bounce message to be discarded even if
  the next-hop relay does not advertise REQUIRETLS.

Perhaps an internal cross-reference up to Section 4.2.1 is in order?

  Senders of messages requiring TLS are advised to consider the
  possibility that bounce messages will be lost as a result of
  REQUIRETLS return path failure, and that some information could be
  leaked if a bounce message is not able to be transmitted with
  REQUIRETLS.

It's not really clear how actionable this is.  If you have a message
that you want to send, you're either going to send it or not send it.
What would you change about the message based on whether or not you
could get a bounce, or whether or not the bounce would leak the message
contents?

Section 6

  Mailing lists, upon receipt of a message, originate new messages to
  list addresses.  This is distinct from an aliasing operation that
  redirects the original message, in some cases to multiple recipients.

I'm not entirely sure how universally acknowledged this claim is; at
MIT, we have lots of "mailing lists" implemented via the central Moira
management database, but the actual implementation on the mailhubs is
more like the aliasing operation described in the second sentence.
Is there a need to make this distinction in order to support the
following points, or could they stand on their own without this?

  The requirement to preserve the REQUIRETLS tag therefore does not
  necessarily extend to mailing lists, although the inclusion of the
  RequireTLS header field MAY cause messages sent to mailing lists to
  inherit this characteristic.  [...]

Maybe I'm confused, but doesn't the REQUIRETLS tag and the RequireTLS
header field have very different characteristics?  I don't understand
which one "this characteristic" is supposed to refer to.

  Mailing list operators MAY apply REQUIRETLS requirements in incoming
  messages to the resulting messages they originate.  If this is done,
  they SHOULD also apply these requirements to administrative traffic,
  such as messages to moderators requesting approval of messages.

Maybe note that such administrative traffic can include message contents
intended for the list?

Section 8.2

  clear, where they can be intercepted.  REQUIRETLS detects the failure
  of STARTTLS and declines to send the message rather than send it
  insecurely.

nit: I'd say that REQUIRETLS requires the detection and declining,
rather than doing so itself.

                                                    REQUIRETLS requires
  successful certificate validation before sending the message.

(As mentioned above, we need greater clarity about what the validation
specifically entails.)

                REQUIRETLS requires that the recipient domain's MX
  record lookup be validated either using DNSSEC or via a published
  MTA-STS policy that specifies the acceptable SMTP server hostname(s)
  for the recipient domain.

Are we then required to use those server hostname(s) in the certificate
validation portion of the TLS connection?

Section A.1

In light of https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ please
consider using IPv6 examples.

[Ballot discuss]
I'm pretty sad to see that the "RequireTLS: no" header field has the
name "require TLS" and the opposite semantics.  It seems like the
positvie signal that we are trying to indicate is "Ignore TLS" or "TLS
optional" or similar; why does the header field need to be named
"Require TLS" -- isn't that confusing to users, as opposed to, say,
"TLS-Required"?

While I understand that there can be cases where it is desired to ignore
recipient-domain indications to use TLS, such as to report problems with
the TLS capabilities of those domains, I have strong qualms about
describing this protocol as an "override" for DANE and MTA-STS, or that
such recipient-domain signals should be "ignored".  In effect, by
attempting to do so, this document is fundamentally modifying the
protocol semantics for (SMTP) DANE and MTA-STS, something that can only
properly be done by clearly calling out the behavior change and an
Updates: relationship with the documents whose semantics are being
modified (i.e., the DANE and MTA-STS specifications).
Alternately, it could also be reasonable to remove claims of
"override" or "ignore" and to leave the semantics of the header field as
being that the sender requests one behavior, and the MTA can balance the
requests of the sender and recipient at their own discretion. This is
still not a great option, though, as it would seem to put multiple IETF
proposed standards at odds with each other.

I'm also concerned about the apparent new burden placed on senders in
Section 4.3 to actively decide whether every outgoing message requires
end-to-end TLS protection or is safe to forward without TLS ("when TLS
is to be required, [...].  When TLS is not to be required, [...]"), where both
"[...]" require new behavior not present in a client that does not implement
this specification.  To some extent this is an editorial matter of how the
new mechanisms are portrayed, but I don't see much in this document to justify
the stance that the default "don't care" option should be removed (for clients
that implement this specification at all).

[discussion of "de facto part of the core SMTP spec" removed, on  indications
that this is not the intent]

I'm also unsure exactly how tightly nailed down the (non-DANE) TLS
certificate validation process is supposed to be as a result of this
document; more in the COMMENT section.  It seems that without some form
of strict certificate (host)name validation, this mechanism does not
actually mitigate the lack of server authentication by the client that's
described as a goal.  That is, while the referenced DANE procedures for
validating a TLS connection for SMTP are pretty clear and exhaustive,
the non-DANE case does not seem to have thorough instructions for
how to validate the TLS connection, whether in this document or an
external reference.

I'd also like to discuss whether it's safe to require that the tag and
header be mutually exclusive.  (As per the COMMENT section,) I don't have
a great picture on what scenarios could cause that to arise, how common
they are, and what the impact would be for strict enforcement, but there
doesn't seem to be much reason to actively allow conflicting indications,
even when we say which one takes precedence.

[Ballot comment]
Apologies if this has been answered elsewhere, but as someone who send mail to mailing lists, I'm trying to figure out what:
"REQUIRETLS users SHOULD be made aware
  of this limitation so that they use caution when sending to mailing
  lists and do not assume that REQUIRETLS applies to messages from the
  list operator to list members." actually means to me, and who is supposed to be making me aware of this.

(actually, all my mail to lists goes to public lists, and so I personally don't care, but if I submitted mail to i_like_to_slather_myself_in_peanutbutter@unusualhobbies.org I might feel differently).

[Ballot discuss]
I support Benjamin's DISCUSS.

To elaborate on one point a bit: it seems to me that it's harmful to
security to allow the sender to unilaterally override the recipient's
preferences that something be encrypted. To forestall one argument,
yes, the sender knows the contents of the message, but the recipient
knows their own circumstances, and they may be at particular risk


      The choices of key lengths and algorithms change over time, so a
      specific requirement is not presented here.
     
This is not a verifiable conformance requirement. You
either need to not have a 8174 SHOULD here, or actually specify what
"meaningfully secure" means.

[Ballot comment]
  email by giving the originator of a message an expectation that it
  will be transmitted in an encrypted form "over the wire".  When used,
  REQUIRETLS changes the traditional behavior of email transmission,

This does not seem to accurately describe "RequireTLS: NO"

[Ballot comment]
I support Benjamin's first three DISCUSS points.

I feel like there are some fairly significant UI implications of adding this option to the mix of other tools for transport-level encryption support, given that this is supposed to operate on a message-by-message basis. Can you explain how this is expected to work? I have this concern generally but also in relation to this:

"REQUIRETLS users SHOULD be made aware
  of this limitation so that they use caution when sending to mailing
  lists and do not assume that REQUIRETLS applies to messages from the
  list operator to list members."
 
I can't figure out how this requirement is expected to be met in practice.

[Ballot discuss]
I'm pretty sad to see that the "RequireTLS: no" header field has the
name "require TLS" and the opposite semantics.  It seems like the
positvie signal that we are trying to indicate is "Ignore TLS" or "TLS
optional" or similar; why does the header field need to be named
"Require TLS" -- isn't that confusing to users?

While I understand that there can be cases where it is desired to ignore
recipient-domain indications to use TLS, such as to report problems with
the TLS capabilities of those domains, I have strong qualms about
describing this protocol as an "override" for DANE and MTA-STS, or that
such recipient-domain signals should be "ignored".  In effect, by
attempting to do so, this document is fundamentally modifying the
protocol semantics for (SMTP) DANE and MTA-STS, something that can only
properly be done by clearly calling out the behavior change and an
Updates: relationship with the documents whose semantics are being
modified.  Alternately, it could also be reasonable to remove claims of
"override" or "ignore" and to leave the semantics of the header field as
being that the sender requests one behavior, and the MTA can balance the
requests of the sender and recipient at their own discretion. This is
still not a great option, though, as it would seem to put multiple IETF
proposed standards at odds with each other.

I'm also concerned about the apparent new burden placed on senders to
actively decide whether every outgoing message requires end-to-end TLS
protection or is safe to forward without TLS, especially in light of the
apparent goal (see next paragraph) of quickly achieving (near-)universal
deployment.  There doesn't seem to be much in this document to justify
the stance that the default "don't care" option should be removed.

The "must chain forward to final delivery" property for the REQUIRETLS
option seems to present some incremental deployment difficulties, in that
it will be nigh-impossible to successfully deliver such a message until
there is fairly significant deployment coverage.  E.g., if any major email
hosting provider does not implement, then it will forever remain a niche
technology.  What indication to we have that this technology can succeed as
specified?  If we anticipate it becoming a part of the de facto core,
mandatory, SMTP feature set, should we not indicate that by an Updates:
relationship?

I'm also unsure exactly how tightly nailed down the (non-DANE) TLS
certificate validation process is supposed to be as a result of this
document; more in the COMMENT section.  It seems that without some form
of strict certificate (host)name validation, this mechanism does not
actually mitigate the lack of server authentication by the client that's
described as a goal.

I'd also like to discuss whether it's safe to require that the tag and
header be mutually exclusive.  (As per the COMMENT section,) I don't have
a great picture on what scenarios could cause that to arise, how common
they are, and what the impact would be for strict enforcement.

[Ballot comment]
Section 2

  o  The certificate presented by the SMTP server MUST either verify
      successfully in a trust chain leading to a certificate trusted by
      the SMTP client or it MUST verify successfully using DANE as
      specified in RFC 7672 [RFC7672].  For trust chains, the choice of
      trusted (root) certificates is at the discretion of the SMTP
      client.

I don't see how this requirement restricts the presented end-entity
certificate so as to eliminate the attacks that exploit "the lack of server
authentication by the client".  What does certificate have to name in order
to be trusted by the client?

Section 4.1

  Upon receipt of the REQUIRETLS option on a MAIL FROM command during
  the receipt of a message for which the return-path is not empty
  (indicating a bounce message), an SMTP server MUST tag that message
  as needing REQUIRETLS handling.

What processing should happen when REQUIRETLS is received and the
return-path *is* empty?

          If the REQUIRETLS MAIL FROM parameter is specified, the
  RequireTLS header field MUST be ignored but MAY be included in onward
  relay of the message.

How could this scenario arise?  (Why is it not a user error to attempt to
use both -- isn't one requiring TLS and the other disclaiming its use,
making them mutually incompatible?)

Section 4.2.1

  2.  If the server lookup is accomplished via the recipient domain's
      MX record (the usual case) and is not accompanied by a valid
      DNSSEC signature, the client MUST also validate the SMTP server
      name using MTA-STS as described in RFC 8461 [RFC8461]
      Section 4.1.

What happens if this validation fails?  Perhaps the below text "If any of
the above fails" could include "(including MTA-STS validation)" for extra
clarity.

  3.  Open an SMTP session with the peer SMTP server using the EHLO
      verb.

  4.  Establish a TLS-protected SMTP session with its peer SMTP server
      and authenticate the server's certificate as specified in
      [RFC6125] or [RFC7672] as applicable.

"STARTTLS" does not appear in here anywhere.
Separately, is this combination of steps going to preclude any setups that
(e.g., via preconfiguration) go straight to TLS with no STARTTLS
negotiation?

What name is used as input to certificate validation (for the 6125 branch)?
Is Appendix B.4 therein supposed to be normative?  (The Appendix B header
indicates that the content is non-normative.)

Section 4.2.2

  Some SMTP servers may be configured to require STARTTLS connections
  as a matter of policy and not accept messages in the absence of
  STARTTLS.  A non-delivery notification MUST be returned to the sender
  if message relay fails due to an inability to negotiate STARTTLS when
  required by the server.

This is an "inability to negotiate" combined with a rejection of
non-STARTTLS, right?

Section 5

  The path from the origination of an error bounce message back to the
  MAIL FROM address may not share the same REQUIRETLS support as the
  forward path.  Therefore, users requiring TLS are advised to make
  sure that they are capable of receiving mail using REQUIRETLS as

nit: "requiring TLS for outgoing mail"?

  If a REQUIRETLS message is bounced, the server MUST behave as if
  RET=HDRS was present as described in [RFC3461].  If both RET=FULL and
  REQUIRETLS are present, the RET=FULL MUST be disregarded and MAY be
  transformed to RET=HDRS on relay.  The SMTP client for a REQUIRETLS

If the MAY is not taken, will the next hop be obligated to detect that this
is a bounce and apply the preceding MUSTs?  If not, perhaps this also
should be a MUST?

  bounce message uses an empty MAIL FROM return-path as required by
  [RFC5321].  When the MAIL FROM return-path is empty, the REQUIRETLS
  parameter SHOULD NOT cause a bounce message to be discarded even if
  the next-hop relay does not advertise REQUIRETLS.

Perhaps an internal cross-reference up to Section 4.2.1 is in order?

  Senders of messages requiring TLS are advised to consider the
  possibility that bounce messages will be lost as a result of
  REQUIRETLS return path failure, and that some information could be
  leaked if a bounce message is not able to be transmitted with
  REQUIRETLS.

It's not really clear how actionable this is.  If you have a message
that you want to send, you're either going to send it or not send it.
What would you change about the message based on whether or not you
could get a bounce, or whether or not the bounce would leak the message
contents?

Section 6

  Mailing lists, upon receipt of a message, originate new messages to
  list addresses.  This is distinct from an aliasing operation that
  redirects the original message, in some cases to multiple recipients.

I'm not entirely sure how universally acknowledged this claim is; at
MIT, we have lots of "mailing lists" implemented via the central Moira
management database, but the actual implementation on the mailhubs is
more like the aliasing operation described in the second sentence.
Is there a need to make this distinction in order to support the
following points, or could they stand on their own without this?

  The requirement to preserve the REQUIRETLS tag therefore does not
  necessarily extend to mailing lists, although the inclusion of the
  RequireTLS header field MAY cause messages sent to mailing lists to
  inherit this characteristic.  [...]

Maybe I'm confused, but doesn't the REQUIRETLS tag and the RequireTLS
header field have very different characteristics?  I don't understand
which one "this characteristic" is supposed to refer to.

  Mailing list operators MAY apply REQUIRETLS requirements in incoming
  messages to the resulting messages they originate.  If this is done,
  they SHOULD also apply these requirements to administrative traffic,
  such as messages to moderators requesting approval of messages.

Maybe note that such administrative traffic can include message contents
intended for the list?

Section 8.2

  clear, where they can be intercepted.  REQUIRETLS detects the failure
  of STARTTLS and declines to send the message rather than send it
  insecurely.

nit: I'd say that REQUIRETLS requires the detection and declining,
rather than doing so itself.

                                                    REQUIRETLS requires
  successful certificate validation before sending the message.

(As mentioned above, we need greater clarity about what the validation
specifically entails.)

                REQUIRETLS requires that the recipient domain's MX
  record lookup be validated either using DNSSEC or via a published
  MTA-STS policy that specifies the acceptable SMTP server hostname(s)
  for the recipient domain.

Are we then required to use those server hostname(s) in the certificate
validation portion of the TLS connection?

Section A.1

In light of https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ please
consider using IPv6 examples.

[Ballot comment]
Thanks for this. I am balloting "yes", but I have a couple of questions. (The first would border on a DISCUSS, but I suspect I am reading something wrong):

- I am confused about the handling of bounce messages. §4.1 says the following:

"Upon receipt of the REQUIRETLS option on a MAIL FROM command during
the receipt of a message for which the return-path is not empty
(indicating a bounce message), an SMTP server MUST tag that message
as needing REQUIRETLS handling."

... which seems to exempt bounce messages from REQUIRETLS tagging. But §5 says:

"Non-delivery ("bounce") messages usually contain important metadata
about the message to which they refer, including the original message
header. They therefore MUST be protected in the same manner as the
original message. All non-delivery messages resulting from messages
with the REQUIRETLS SMTP option, whether resulting from a REQUIRETLS
error or some other, MUST also specify the REQUIRETLS SMTP option
unless redacted as described below."

... which seems to require bounce messages to _not_ be exempt from tagging.

What am I missing?

§6: "REQUIRETLS users SHOULD be made aware
of this limitation so that they use caution when sending to mailing
lists and do not assume that REQUIRETLS applies to messages from the
list operator to list members."

Does this mean a user agent needs to know if a message destination is a list so that it can make the user aware?

[Ballot comment]
Thanks for the work everyone did on this specification. I'm happy to see the
state-of-the-art for email security continuing to move forward. I noticed one
minor inconsistency in the document that you probably want to address.

§2 specifies:

>  1.  The textual name of the extension is "Require TLS".

While §7 indicates:

>  Textual name:              RequireTLS

I belive you'll want to rationalize the presence/absence of a space between these
two sections.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-uta-smtp-require-tls-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the SMTP Service Extensions registry on the MAIL Parameters registry page located at:

https://www.iana.org/assignments/mail-parameters/

a single, new keyword is to be registered as follows:

EHLO Keyword: REQUIRETLS
Description: REQUIRETLS parameter on MAIL
Reference: [ RFC-to-be ]
Note:

Second, in the Enumerated Status Codes registry on the Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry page located at:

https://www.iana.org/assignments/smtp-enhanced-status-codes/

a single, new code will be registered as follows:

Code: [ TBD-at-Registration ]
Sample Text: REQUIRETLS support required
Associated basic status code: 530
Description: This indicates that the message was notable to be forwarded because it was received with a REQUIRETLS requirement and none of the SMTP servers to which the message should be forwarded provide this support
Reference: [ RFC-to-be ]
Submitter: J. Fenton
Change Controller: IESG

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, in the Permanent Message Header Field Names registry on the Message Headers registry page located at:

https://www.iana.org/assignments/message-headers/

a single, new registration is to be made as follows:

Header Field Name: RequireTLS
Template:
Protocol: mail
Status: standard
Reference: [ RFC-to-be ]

As this also requests a registration in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-02-08):

From: The IESG
To: IETF-Announce
CC: uta-chairs@ietf.org, valery@smyslov.net, draft-ietf-uta-smtp-require-tls@ietf.org, uta@ietf.org, Valery Smyslov , alexey.melnikov@isode.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (SMTP Require TLS Option) to Proposed Standard


The IESG has received a request from the Using TLS in Applications WG (uta)
to consider the following document: - 'SMTP Require TLS Option'
  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
ietf@ietf.org mailing lists by 2019-02-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The SMTP STARTTLS option, used in negotiating transport-level
  encryption of SMTP connections, is not as useful from a security
  standpoint as it might be because of its opportunistic nature;
  message delivery is, by default, prioritized over security.  This
  document describes an SMTP service extension, REQUIRETLS, and message
  header field, RequireTLS.  If the REQUIRETLS option or RequireTLS
  message header field is used when sending a message, it asserts a
  request on the part of the message sender to override the default
  negotiation of TLS, either by requiring that TLS be negotiated when
  the message is relayed, or by requesting that recipient-side policy
  mechanisms such as MTA-STS and DANE be ignored when relaying a
  message for which security is unimportant.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-require-tls/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-require-tls/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Proposed Standard as indicated on the title page header and in the
  datatracker.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The SMTP STARTTLS option, used in negotiating transport-level
  encryption of SMTP connections, is not as useful from a security
  standpoint as it might be because of its opportunistic nature;
  message delivery is, by default, prioritized over security.  This
  document describes an SMTP service extension, REQUIRETLS, and message
  header field, RequireTLS. If the REQUIRETLS option or RequireTLS
  message header field is used when sending a message, it asserts a
  request on the part of the message sender to override the default
  negotiation of TLS, either by requiring that TLS be negotiated when
  the message is relayed, or by requesting that recipient-side policy
  mechanisms such as MTA-STS and DANE be ignored when relaying a
  message for which security is unimportant.

Working Group Summary

  The WG consensus for adoption this draft was clear. The draft was
  well discussed in the WG and has undergone significant changes
  during this discussion. At some point there was a strong consideration
  to split the draft into two, separating SMTP service extension
  and mail header field, but the final consensus was that
  it's better to define them in a single document.

Document Quality

  There are at least two implementations of the early version of the draft.
  A few major vendors and operators express an interest in this technology
  and have indicated that they evaluate a possibility to implement (or use) it.

Personnel

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

  Valery Smyslov (shepherd)
  Alexey Melnikov (AD)

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  I have reviewed the document and found it ready.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No. The document was a subject of several reviews
  by experienced WG members.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  None.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosure has been filed that reference this document.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  The WG consensus is solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  No ID nits were found by idnits tool.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  None are applicable.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  A new item "RequireTLS" is added to the "SMTP Service Extensions" registry.
  Another new item "RequireTLS" is added to the "Permanent Message Header Field Names"
  registry. In addition a new status code is defined in the "Simple Mail Transfer Protocol
  (SMTP) Enhanced Status Codes" registry. The requirements for all three registries
  are fulfilled.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No new registries are defined.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No automated checks are applicable.