Subject: [ietf-smtp] Fwd: New Version Notification for draft-fenton-smtp-require-tls-01.txt

From: Jim Fenton <[email-masked]>
Date: Sat, 13 Feb 2016 15:43:11 -0800

Hi,

I have submitted an update to this draft. Thanks to several of you for
excellent comments. Significant changes are:

- Conversion of REQUIRETLS from an SMTP verb to a MAIL FROM parameter to
better associate REQUIRETLS requirements with transmission of individual
messages.

- Addition of an option to require DNSSEC lookup of the remote mail
server, since this affects the common name of the certificate that is
presented.

- Clarified the wording to more clearly state that TLS sessions must be
established and not simply that STARTTLS is negotiated.

- Introduced need for minimum encryption standards (key lengths and
algorithms)

- Substantially rewritten Security Considerations section

Further comments are of course appreciated.

-Jim

-------- Forwarded Message --------
Subject: 	New Version Notification for draft-fenton-smtp-require-tls-01.txt
Date: 	Sat, 13 Feb 2016 15:36:57 -0800
From: 	[email-masked]
To: 	Jim Fenton <[email-masked]>

A new version of I-D, draft-fenton-smtp-require-tls-01.txt
has been successfully submitted by Jim Fenton and posted to the
IETF repository.

Name:		draft-fenton-smtp-require-tls
Revision:	01
Title:		SMTP Require TLS Option
Document date:	2016-02-13
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/internet-drafts/draft-fenton-smtp-require-tls-01.txt
Status:         https://datatracker.ietf.org/doc/draft-fenton-smtp-require-tls/
Htmlized:       https://tools.ietf.org/html/draft-fenton-smtp-require-tls-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-fenton-smtp-require-tls-01

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 prioritized over security.  This document
   describes a complementary SMTP service extension, REQUIRETLS.  If the
   REQUIRETLS option is used when sending a message, it causes message
   delivery to fail if a TLS connection with the required security
   characteristics cannot be completed with the next hop MTA or if that
   MTA does not also advertise that it supports REQUIRETLS.  Message
   originators may therefore expect transport security to be used for
   messages sent with this option.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "John Levine" <[email-masked]>
Date: 14 Feb 2016 01:54:10 -0000

>Further comments are of course appreciated.

I still don't get it.  If a sender wants to talk only to MTAs that
support STARTTLS, it can just do so, and on today's Internet that
covers the vast majority of mail.

As soon as you try to get clever, you quickly run into perverse
effects.  Here's an example:

You send a message to a mailing list with the SMTP required flag.
Does that mean that the list should preserve the flag so its outbound
MTA applies the rule to the message when it's sent out the recipients?
If not, seems pretty ineffective.

If so, you're going to have a bunch of bounces from mail to
subscribers whose MTAs don't support TLS, and history suggests that
the list software will do what it does and those subscribers will get
bounced off the list.  (DMARC fans will find this scenario familiar.)
So what's the list supposed to do?

R's,
John

PS: I know what I'd do, but you already knew that.

---

From: Jim Fenton <[email-masked]>
Date: Sun, 14 Feb 2016 11:35:57 -0800

> covers the vast majority of mail.

In the draft, I use "sender" to refer to the originator of a mail
message, the person or entity that writes it. Perhaps that wasn't clear.
Very often the sender will submit that message to an MTA they have a
relationship with, which will then send it onward. The sender rarely
controls that MTA, and currently there is no way for the sender to
signal the MTA that they want to ensure that TLS is used when the
message is sent onward. This draft addresses that issue.

Even if STARTTLS is supported by both sides, it is possible for an
intermediary to interfere with it, by simply garbling the command. There
are commercial products that do this, as described at
http://www.cisco.com/c/en/us/about/security-center/intelligence/asa-esmtp-starttls.html
. This is also addressed by REQUIRETLS.
> If not, seems pretty ineffective.

My first inclination is that it's up to the mailing list manager what to
do in this case since it's generating a new message to the mailing list
subscribers. I don't think that makes REQUIRETLS ineffective at all; I
would think twice before sending sensitive information to a mailing list
anyway.

-Jim