Subject: [Uta] I-D Action: draft-ietf-uta-smtp-require-tls-02.txt

From: [email-masked]
Date: Fri, 06 Apr 2018 16:13:02 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Using TLS in Applications WG of the IETF.

        Title           : SMTP Require TLS Option
        Author          : Jim Fenton
	Filename        : draft-ietf-uta-smtp-require-tls-02.txt
	Pages           : 14
	Date            : 2018-04-06

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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-require-tls/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-uta-smtp-require-tls-02
https://datatracker.ietf.org/doc/html/draft-ietf-uta-smtp-require-tls-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-smtp-require-tls-02

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Jim Fenton <[email-masked]>
Date: Fri, 6 Apr 2018 16:20:31 -0700

The major change in this version is the removal of the options (CHAIN,
DANE, and DNSSEC) from the REQUIRETLS SMTP option as discussed in
London. There were also inconsistencies in the header field name
(Require-TLS vs. RequireTLS) so I chose the latter.

Source code (.xml) is at https://github.com/jimfenton/requiretls

-Jim

On 4/6/18 4:13 PM, [email-masked] wrote:
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta

---

From: "Chris Newman" <[email-masked]>
Date: Mon, 09 Apr 2018 18:08:00 -0700

> (Require-TLS vs. RequireTLS) so I chose the latter.

Although I don't intend to implement this because I don't foresee a use 
case, I reviewed it out of curiosity:

1. Section 4.3 needs to allow use of implicit TLS (RFC 8314) in addition 
to STARTTLS. The submission client would verify the TLS certificate of 
the submission server as documented in RFC 8314.

2. There should be an example showing the SMTP protocol used with the 
REQUIRETLS mail from parameter.

3. The IANA considerations are incomplete. For example, they are missing 
fields required to register in the SMTP mail system response codes 
registry. See RFC 5248. I'm not sure this specifies all the IANA 
registration fields described in RFC 5321 for an SMTP extension. IANA 
considerations are not typically removed during publication.

Architecturally, I see "RequireTLS: No" as potentially useful to work 
around MTA-STS deployment bugs.

I think the text related to bouncing a REQUIRETLS message is highly 
problematic. Metadata related to email is not private due to laws in 
certain jurisdictions and pretending it can be more private than it is 
does a disservice to implementers and users. The mail bounce 
infrastructure is already problematic and this makes that infrastructure 
more complicated; if this were implemented it would increase the chances 
of lost mail and/or the cost of mail system operations. I find both of 
those outcomes objectionable. Even if I decided to implement REQUIRETLS, 
I'd deliberately choose not to implement the entire section about bounce 
processing as presently written (and document that choice as both an 
intentional choice and a good one).

If you want to say something about bounce processing, I believe this is 
the best you can do without making the bounce processing unduly complex:

If a REQUIRETLS message is bounced, the server MUST behave as if 
RET=HDRS was present as described in RFC 3461. 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 
bounce message MUST use an empty MAIL FROM return-path as required by 
RFC 5321. 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.

		- Chris

---

From: Jim Fenton <[email-masked]>
Date: Wed, 11 Apr 2018 14:29:00 -0700

Thanks for your review, Chris:

On 4/9/18 6:08 PM, Chris Newman wrote:
> Although I don't intend to implement this because I don't foresee a
> use case, I reviewed it out of curiosity:
>
> 1. Section 4.3 needs to allow use of implicit TLS (RFC 8314) in
> addition to STARTTLS. The submission client would verify the TLS
> certificate of the submission server as documented in RFC 8314.

Agreed. I was somewhat focused on message relay (since submission is the
first hop, and the sender can directly control what happens there). But
submission is also SMTP, and the REQUIRETLS should handle all uses of
SMTP consistently.

> REQUIRETLS mail from parameter.

Good idea.

>
> 3. The IANA considerations are incomplete. For example, they are
> missing fields required to register in the SMTP mail system response
> codes registry. See RFC 5248. I'm not sure this specifies all the IANA
I'll fix this section; it does appear to be incomplete. I should have
said that the IANA Considerations are updated at publication, right?

I'm not entirely clear on how the status codes (specifically the detail
sub-code) are assigned. Do I leave it as .X in the draft, to be changed
into an actual value at publication?

> infrastructure is already problematic and this makes that
> infrastructure more complicated; if this were implemented it would
> increase the chances of lost mail and/or the cost of mail system
> operations. I find both of those outcomes objectionable. Even if I
> decided to implement REQUIRETLS, I'd deliberately choose not to
> implement the entire section about bounce processing as presently
> written (and document that choice as both an intentional choice and a
> good one).
>
> If you want to say something about bounce processing, I believe this
> is the best you can do without making the bounce processing unduly
> complex:
>
> parameter SHOULD NOT cause a bounce message to be discarded even if
> the next-hop relay does not advertise REQUIRETLS.

Part of the point of REQUIRETLS is that end-to-end encryption doesn't
cover everything -- specifically not the message header and envelope
information. While that information is not private to the MTAs handling
the message and potentially the jurisdictions in which they reside, TLS
prevents that information from being available to the jurisdictions
through which the message merely passes. The point of the bounce
language is to make sure that is still the case for a message bounce.
I'm still concerned about metadata leakage on these bounce messages.

I do see a problem that the current text (section 5 paragraph 3) assumes
that the sender of a bounce would get feedback about whether the bounce
delivery failed, which doesn't work because the envelope-from address
would be empty as required by RFC 5321. So what I would have it say
there is that bounce messages resulting from REQUIRETLS should always be
redacted. Unfortunately, this means that the bounce is only delivered to
the postmaster, which isn't particularly useful. So then we're back to
sending bounces to REQUIRETLS messages with REQUIRETLS also, and not
doing any special redaction, other than noting that some bounces may be
discarded by the mail system as a result.

I really don't see the value in changing RET=FULL into RET=HDRS. In many
cases, who's sending mail to whom is as (or more) interesting to an
eavesdropper as the message content.

-Jim

---

From: "Chris Newman" <[email-masked]>
Date: Wed, 11 Apr 2018 16:12:17 -0700

> into an actual value at publication?

Yes.

> discarded by the mail system as a result.

The consequence of that is REQUIRETLS results in silent delivery 
failures. To the extent that happens, people will stop using the 
feature. I expect some implementers will consider passing the bounce 
forward without TLS a lesser evil compared to silently losing email.

> eavesdropper as the message content.

A number of MTAs ignore RET=FULL and always use RET=HDRS anyway. So this 
is free for those MTAs, easy to implement for others, won't break 
anything (the way a more extensive redaction would), and when an 
implementer chooses to ignore the spec's guidance about using REQUIRETLS 
with an empty envelope from, this at least protects the content. Yes, 
metadata is quite valuable but sometimes content is more valuable so no 
need to leak it when it's this easy to protect.

		- Chris