[Last-Call] Re: A different look (was: Re: [Emailcore] Re: Re: draft-ietf-emailcore-as-28 ietf last call Secdir revie

[Bron Gondwana <[e-mail]>]

I am onboard for an SMTP-BIS activity with a chance of real success if there's another other interest.  

This windmill has been tilted at many times, but maybe we're ready to try again?

Meanwhile, I don't see precisely how that solves the current issue, because we still have to release this document. Maybe a "we'll work on an new protocol which requires TLS" promise will mollify the TLS maximalists, but I wouldn't want to delay publishing this document until such protocol was finished.

Bron.

On Mon, Jun 1, 2026, at 17:42, John C Klensin wrote:
> Hi.
> At least as I see it, the discussion of the Secdir review and
> proposals to either more clearly require TLS or to eliminate the
> requirement for being prepared to accept cleartext have been going
> around in circles, with no real progress despite several explanations
> of the situation and constraints. 
> 
> Let me suggest a different way to think about the problem in the hope
> that it will lead to some sort of agreement.  While it might look
> like one, what follows is not a proposal.  Such a proposal would be
> out of scope for EMAILCORE and inappropriate for the Last Call list.
> IMO, it might also be impractical given the installed base.  However,
> and with thanks to those who have tried to draw analogies to the
> HTTP/HTTPS transition...
> 
> Many details, some of them important, aside, the fundamental problems
> with creating a strong requirement for confidentiality (or, borrowing
> from another thread, new rules for interpreting the local-parts of
> email addresses) are a combination of:
> 
> (i) the installed base, including (depending on how one
> counts) 40 or 50 years of entrenched experience with email
> with strong assumptions that messages should be delivered
> whenever possible, letting the final destination systems sort
> out any issues
> (ii) the hop-by-hop mechanism that is at the core of the SMTP
> design.  That model allows messages to be delivered, via
> intermediate relays and gateways, from sender locations to
> receiver ones for which direct connections in real time may
> not be possible.  It also does not require that those
> intermediaries be under the direct control of either the
> sending systems or the destination ones.  Those provisions
> are far less important to the well-connected Internet of
> today than they were to the network of the early 1980s, but
> remain important in less-well-connected parts of the world
> and are likely to become more important as delay-tolerant
> networks (including ones with nodes off-planet) become more
> significant.   However, a hop-by-hop design presents a
> security challenge as every child who has played a telephone
> relay game can explain: every hop, even set of virtual hands
> (or ears) through which the messages passes is an opportunity
> for distortion and compromised confidentiality (accidental or
>   intentional).
> (iii) the decision, around 1992, to allow extensions to, and
> protocol variations of, SMTP by embedding the extension
> mechanism in the protocol itself rather than saying "new
> protocol, new port".  That decision was made to preserve
> interoperability, including delivery whenever possible, and
> minimize transition difficulties.  As as been pointed out,
> that mechanism has the unfortunate side effect of disclosing
> important information before a TLS connection can be set up.  
> 
> Probably the best way to look at that combination of factors -- a
> combination that makes real confidentiality of both the messages and
> the envelop transition information impossible for some set of cases
> -- is to accept that they are fundamentally incompatible with SMTP as
> established in 1982 (RFC 821) and modified in significant ways in
> 1986 (RFC 974), and 1993 (RFC 1425).  For the reasons identified
> above, we can't tweak our way out of that.  What is needed is a new,
> CMTP (Confidential Mail Transport Protocol) with a new port and a
> protocol architecture that differs from SMTP (probably more than
> HTTPS differs from HTTP).  I assume the difference would include:
> 
> (1) Establishment of an encrypted (and possibly
> authenticated) connection at initial connection time, rather
> than after some handshaking between client (sender) and
> server (receiver).
> (2) Notification by the receiver to the originating sender as
> to whether the receiver was responsible for final message
> delivery or would need to act as a relay.  The originator
> could then decide whether to continue with whatever
> assumptions of reduced confidentiality were appropriate or to
> abandon message transmission.  In other words, either
> prohibit hop-by-hop transmission or require that it be used
> only with the express permission of the message originator.
> (3) Possibly other changes that would allow improved
> confidentiality and/or authentication of originator or
> destination.
> (4) Updating, or getting rid of, some of the (forgive me,
> but...) kludges we have incorporated into mail headers in
> order to work around the limitations of the current systems
> and the problems resulting from the hop-by-hop model.
> (5) Probably additional changes to reflect the world of the
> mid-2020s rather than that of the early 1980s, such as smooth
> use of non-ASCII characters and perhaps taking another look
> at the syntax of email address local parts.
> 
> The last two or three provisions would provide added incentives for
> deployment and adoption.
> 
> If the new protocol had no mechanisms for negotiating an encrypted
> connection or hop-by-hop processing (probably useful
> simplifications), the first two provisions above would get lots
> simpler.  The decision of what to do next, perhaps falling back to
> traditional SMTP, would be up to the message originator and would not
> require special mechanisms in the new protocol.  Note the exact
> parallel with the HTTP/HTTPS relationship in that approach.
> 
> So, rather than continuing to discuss how (or if) SMTP can be further
> tweaked or restricted, should we be thinking about CMTP?  Again, that
> is not a topic for either the EMAILCORE or Last Call lists, but it
> may illustrate why trying to turn SMTP into something it is not (a
> protocol with enforced and effective confidentiality) is just not
> feasible.
> 
>    john
> 
> 
> -- 
> last-call mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 

--
  Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC
  [e-mail]