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

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

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