[Last-Call] Re: [Emailcore] Re: Re: [secdir] draft-ietf-emailcore-as-28 ietf last call Secdir review

[John C Klensin <[e-mail]>]

First, my apologies for the delay in responding.  Was offline
until a short time ago for reasons unrelated to the IETF.
Inline below...

--On Sunday, 03 May, 2026 04:41 +1000 Viktor Dukhovni
<[e-mail]> wrote:

> On Sat, May 02, 2026 at 12:45:08PM -0400, John C Klensin wrote:
> 
>> In an odd way, trying to insist on encryption over the whole
>> store and forward path might weaken the ability of the final
>> delivery system to know whether the message was confidential
>> on all prior links ...
> 
> That's not correct, nor is there generally a pressing case for
> a recipient to check whether all transit hops employed TLS,
> especially with TLS not nearly as important on interior hops
> inside the sending and receiving networks, and much more
> relevant on the public network in the middle (though some
> internal networks with WAN links are still a concern).

I'm sorry I brought that up and you are, of course, correct that
it is generally not the case, at least among those of us in
developed countries with good Internet service.  Apologies to
all for doing so.

That said, the subject, including both your comments and
Richard's a few minutes later, identifies another issue that the
A/S does not discuss and possibly should.  It is not clear to me
that it is worth reopening it (or possibly reopening
draft-ietf-emailcore-rfc5321bis (identified just as "5321bis"
below)) for the purpose of developing text and getting it in,
but a review and partial tutorial may be in order.  Apologies in
advance, for those from whom the discussion that follows is
obvious; some of the recent discussions such it may not be
obvious to everyone participating in the discussion.

At the time the current email protocols were defined, and even
with store and forward, they assumed a strong, host oriented,
peer-to-peer, end-to-end model. Mail would move from a machine
under the control of the originator, potentially through
friendly intermediate relays, and then to a host under the
control of the recipient. There were no email providers of much
larger scale than a university or company providing for its own
members or employees. The language of thee standards, and, to a
considerable extent, the protocols themselves are still tied to
that model.

In subsequent years, things evolved. We now talk more about the
administrative domains of sender and receiver. For anyone who
does not know (or remember) the change in what we meant by
end-to-end, there is a good summary, with references to more
fundamental discussions, by the IAB in RFC 3724. While those
changes are reflected in 5321bis with the use of
"administrative domain" terminology in the discussion of the
VRFY and EXPN commands, the protocol definition generally does
not call out the distinction between hosts and administrative
domains.

That change is of practical importance to the present
discussion because, in the current situation in which a very
large fraction of the world's email traffic moves within the
administrative domain of a single large mail provider
("internal hops" in Victor's message) or between the
administrative domains of a pair of such providers, whatever we
have to say about link-level confidentiality is, at once,
important and irrelevant. When mail moves within the
administrative domain of a provider, between two user mailboxes
or relays supported by the provider, confidentiality is the
problem of that provider and most, if not all, providers are
responsible about it. While I gather most use TLS/SSL, as far
as the definitions of SMTP for mail transfers on the public
Interent are concerned, that is just Not Our Problem: not only
are we not involved in whether TLS is used, we are not even
involved with whether SMTP or some other protocol is used for
the transfers.

>From a user standpoint, this can be an advantage especially
when mail moves between two users of the same provider. Those
messages are generally secure and confidential with the largest
threats to that confidentiality coming, not from technical
considerations, but from, e.g., law enforcement or other
governmental demands to provide messages and message content.
If such demands, in the form of subpoenas or otherwise, occur,
the only protection of message content available to the mail
sender or receiver lies in message-level encryption (as now
discussed in the I-D) for which the mail provider does not have
access to the private keys.

Messages sent from a user of one large mail provider to a user
or a different one are not much different. Mail moving between
the administrative domains of the two providers will go over a
direct link between the two, one typically under the control of
the recipient administrative domain. Unless one provider or the
other is constrained by regulations or careless and stupid,
traffic over that link will be protected by TLS or
equivalent... and because they are generally not careless or
stupid, we don't need to tell them to do that (although it
can't hurt and might be symbolically useful).

In a way, that is what Richard's and Victor's recent comments
are about.  By extension of their comments and the ones above,
security and confidentiality will take care of themselves and
we are spending a lot of energy on arguments that make no
difference.

They do make a difference in what, from the standpoint of large
email providerss and their customers, are edge cases. Those
cases include mailboxes that are not provided by large
providers (including mailboxes whose use and confidentiality
arrangements may be restricted by government action)l some
sending systems that are embedded in other applications and
that use email for notifications and for which option
negotiation may be too much overhead or too fragile; and
mailboxes for which delivery paths (specified in MX records)
may involve third parties, not just direct transfers between
two mail administrative domains. Those are the cases where our
specifying the importance of TLS (as the I-D does) is most
valuable. They also include the cases in which our seeming to
encourage or authorize rejection or dropping of messages that
lack adequate confidentiality provisions can be most harmful
(unless we just don't care about those messages being
delivered).

The harm is especially obvious when messages originators
recognize the risks associated with lack of confidentiality
over the various links through which the message might pass,
accept disclosure of cleartext envelope information (if one
thinks about the "postcard" analogy, that is information on the
outside of even a sealed envelope) because there is little
choice in the SMTP framework, and consequently resort to
message-level encryption.  With message-level encryption,
link-level encryption is probably still desirable but
provides little marginal protection.
 
> And when the trace headers are not spammer fiction, they in
> fact often distinguish between clertext and TLS delivery (with
> ESMTP, vs. with ESMTPS, vs. with ESMTPSA).

Spammer fiction or tampered with (for whatever reason) on relay
systems.  And the three protocols mentioned above are out of
scope for the WG and this document.  If people feel that their
being out of scope is not a good decision, let's discuss that
rather than attacking SMTP without mentioning them.

>> If, on the other hand, we add strong language mandating TLS
>> where possible (and, again, I'm heard no one arguing against
>> that), if the relay communicating with the final delivery
>> server receives the message without confidentiality
>> protection, 
> 
> This is not a compelling argument.  Let's not go there.

As I said above, apologies for raising it.

   john