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

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

Hi,

I thought I would point out this draft on the perpass list, because its
primary purpose is to give email senders some degree of control over
whether their messages are sent between MTAs using TLS -- and therefore
how susceptible messages are to pervasive passive surveillance.

Discussion of this draft has thus far been on the ietf-smtp list.

-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: Yakov Shafranovich <[email-masked]>
Date: Wed, 17 Feb 2016 17:13:40 -0500

Some minor comments:

Section 1:
"It also requires that the SMTP server advertise
   that it also supports REQUIRETLS, in effect promising that it will
   honor the requirement to require STARTTLS and REQUIRETLS for all
   onward transmissions of messages specifying that requirement."
"

The part about "promising" does not seem to go together with the
optional parameter in section 2 about onward transmission.

Section 3.1 - tagging:
I am wondering if an email header should be defined to carry this
data, which would also allow for auditing by the receiver. Sort of
similar to the SPF/DKIM headers used today.

Section 3.4 - delivery:
It is unclear what "delivery" means here, especially considering that
SMTP may relay messages to another server, perhaps reference RFC 5598?
Also, the parts in section 1 and the optional parameter in section 2
should play together with this, perhaps by requiring TLS in IMAP, etc.
or not. Either way, this may need clarification.

Section 5:
What are the actual added codes? I believe 5.7.10 already exists.

Section 6:
Maybe reference RFC 4949 for terminology?

One other comment - perhaps some sort of limiting digital signatures
for headers only like DKIM can be employed by the receiving MTA to
certify that the receipt and transmission was effective? I am thinking
along the lines of Received headers or DKIM headers, which would allow
traceability.

Yakov

On Sun, Feb 14, 2016 at 2:55 PM, Jim Fenton <[email-masked]> wrote:
> primary purpose is to give email senders some degree of control over whether
> their messages are sent between MTAs using TLS -- and therefore how
> susceptible messages are to pervasive passive surveillance.
>
> 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/
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-fenton-smtp-require-tls-01
>
> Abstract:
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>

---

From: Jim Fenton <[email-masked]>
Date: Wed, 17 Feb 2016 19:42:59 -0800

> optional parameter in section 2 about onward transmission.

If you are saying that the statement in Section 1 is incomplete because
it does not say that the server must honor the requirements of the
optional (server authentication) parameter as well, I agree.

> similar to the SPF/DKIM headers used today.

One could be defined, but that would be a message format extension (RFC
5322) rather than a mail transport extension (RFC 5321). It would then
be necessary to define under what circumstances the new header field
would be moved into the transport realm.  I thought it to be more
straightforward to consider REQUIRETLS to be an aspect of the message
envelope (like the envelope-to and envelope-from addresses) rather than
a header field.
> or not. Either way, this may need clarification.

I have been trying to void "boiling the ocean" by constraining this
feature to SMTP. From the context, it should be clear that by delivery I
was referring to protocols such as IMAP and POP, although webmail
applies here as well. Are you suggesting that this requirement should be
a MUST rather than the SHOULD I proposed?
> What are the actual added codes? I believe 5.7.10 already exists.

5.7.10 does exist, but seems to have the right semantics ("Encryption
needed"). The others will need to be allocated and since they are
numeric codes I didn't presume to define them myself.

> Maybe reference RFC 4949 for terminology?

I'll have a look at 4949.
> along the lines of Received headers or DKIM headers, which would allow

This seems to be a separate feature - authenticated return receipts.
This might be useful, but I don't think it belongs here.  I would hope
that MTAs would add information about REQUIRETLS to their Received:
header fields, much as they do about the use of TLS for messages they
receive, but I haven't worked out quite how to specify that yet.
> Yakov

Thanks for your review!

-Jim

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 17 Feb 2016 22:47:07 -0500

> a MUST rather than the SHOULD I proposed?

Maybe a MUST for SMTP relays following this one, and SHOULD for non-SMTP?

> receive, but I haven't worked out quite how to specify that yet.

+1 on the received headers.

Thanks