Re: Last Call: <draft-ietf-uta-smtp-require-tls-07.txt> (SMTP Require TLS Option) to Proposed Standard

[Russ Housley <[e-mail]>]

I have no problem with the protocol itself, but I do not understand how this specification can not have a reference to TLS.

Russ


> On Jan 25, 2019, at 10:00 AM, The IESG <[e-mail]> wrote:
> 
> 
> The IESG has received a request from the Using TLS in Applications WG (uta)
> to consider the following document: - 'SMTP Require TLS Option'
>  <draft-ietf-uta-smtp-require-tls-07.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
> [e-mail] mailing lists by 2019-02-08. Exceptionally, comments may be
> sent to [e-mail] 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.
> 
> 
> 
>