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

[Jim Fenton <[e-mail]>]

Thanks for your review, Chris:


On 4/9/18 6:08 PM, Chris Newman wrote:
> On 6 Apr 2018, at 16:20, Jim Fenton wrote:
>> 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.
>
> 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.

>
> 2. There should be an example showing the SMTP protocol used with the
> 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
> registration fields described in RFC 5321 for an SMTP extension. IANA
> considerations are not typically removed during publication.
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?

>
>
> 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.

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