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

Wed, 11 Apr 2018 16:13:01 -0700 

On 11 Apr 2018, at 14:29, Jim Fenton wrote:

Thanks for your review, Chris:

On 4/9/18 6:08 PM, Chris Newman wrote:

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?


Yes.


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

_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta

Reply via email to