Ted,
I think there may be some misunderstandings here. If we are going to
disagree, it would be good to be confident we understand what we are
disagreeing about. In no particular order:
* While John Levine's printer may be unique (although I rather doubt
it), there are several families of devices out there that rely on
cleartext, unauthenticated, SMTP for reporting functions. For
example, I'm aware of at least one species of home security systems
that rely on cleartext SMTP (and, for other functions, HTTP) for
notifications and control. They assume they are going to be used on
a more or less protected LAN; running them without other protection
on the public Internet would be, well, dumb, for reasons that extend
well beyond how they are using SMTP. Someone made the argument that
the added costs of running encryption (opportunistic or otherwise)
were trivial these days, but these are IoT (or, maybe better, LoT
(LAN of Things)) devices and that may not be true. Would their
owners/ operators be better off with more "modern" devices? Perhaps,
but the alternatives that dominate the marketplace come with "Your
Data and Behavior are Our Data" terms and conditions, so there is a
extra tradeoff.
* "Old version of sendmail as a relay" is not so obvious when there
is an SMTP client/server on the LAN and maybe not as obvious as you
think. I would know how to do it (possibly by running two LANs) even
for the local server case although it might involve some tricky port
setups; I'm confident you and John Levine know how to do it; but my
neighbor who says he is "not an Internet guy" and who can barely
handle reading and sending email... not very likely even for the
simple case.
* Helping "random despotic governments": no desire to do that at all.
But we may have an interest in enabling as much communication between
the rest of the world and their residents and citizens as feasible
even if the governments (often in some heavy-handed way) want to be
sure they can spy on those communications. I would think that an
IETF community that claims an interest in human rights considerations
in protocols would take as much interest in maximizing the rights of,
and communications with, people who live in non-ideal environments as
for those of us whose ability to protect our and each other's privacy
through, e.g., encryption are unrestricted.
* I'm in favor of STARTTLS as long as its limitations (and those of
other hop-by-hop technologies) are understood. I don't think it (or
almost any other extension) belongs as part of the SMTP spec, much
less as a requirement there, but I would welcome a serious discussion
and recommendation in the Applicability Statement or some document it
could reference. I do think we need to be more careful than we have
been --no matter where we recommend or require it-- to not give users
the impression that, if their messages go out over a TLS connection
(from an SMTP server or, for that matter, even a Message Submission
one) that they will therefore reach the intended recipient without
any intermediate party being able to read them. The latter is the
point of the comments in rfc5321bis-31 (and -32): we should not
mistake authentication (or encryption) on a hop-by-hop basis for
authentication or message content privacy protection end to end.
* Finally, a suggestion I have been holding for my response to
Donald, a response that keeps getting put off as I try to think about
and respond to these more isolated issues... If one looks closely at
the Security Considerations section of the I-D, it becomes clear that
the material there, especially Section 7.1, are focused on message
authentication, integrity, and spoofing detection and not
specifically on privacy and/or encryption of message content
information. If someone feels that there should be a separate
"privacy" discussion/subsection there, please make the case on the
EMAILCORE list, ideally with proposed text. Be prepared for me and
others to oppose, e.g., a specific recommendation (much less a
requirement) for STARTTLS there, but there may well be things that
should be said have have not been said. Don't be surprised if there
is resistance on the basis of minimal change, especially at this late
date but I think it would be something to which the WG should be
willing to give serious consideration.
john
--On Wednesday, October 30, 2024 14:26 +0100 Ted Lemon
<mellon@xxxxxxxxx> wrote:
> John, with all due respect (which is a lot!), there is exactly one
> printer on the internet that sends mail via SMTP, and Other John
> owns it. There is zero risk that it's going to stop working for
> him, because he can just use an old version of sendmail as a relay:
> one that supports STARTTLS but doesn't require it. It is not
> unusual to have to set up stuff like this to deal with old tech,
> although the carbon footprint of this hypothetical printer may
> justify recycling it at this point.
>
> Nobody is going to mock the IETF for making this change. If we are
> going to be mocked, it will be for not making this change.
>
> And if some government makes STARTTLS illegal, then it's on them to
> figure out how this is going to work. Will they also make HTTPS
> illegal? If they did that, it would be up to them to figure out how
> to make it work, not up to us. It is not our job to help random
> despotic governments snoop on their citizens. If they want to do
> that, that's their choice, but we are 100% not obliged to help them.
>
> There may be good arguments against requiring STARTTLS, but neither
> of the arguments you have advanced here is among them.
>
> On Wed, Oct 30, 2024 at 2:08 PM John C Klensin
> <john-ietf@xxxxxxx> wrote:
>
>>
>>
>> --On Tuesday, October 29, 2024 22:24 -0400 John R Levine
>> <johnl@xxxxxxxxx> wrote:
>>
>> > On Tue, 29 Oct 2024, Paul Wouters wrote:
>> >>>
>> >>> I can easily imagine scenarios where STARTTLS makes no sense
>> >>
>> >> No network should run smtp in the clear, whether it is "over the
>> >> internet" or not. Even if you'd gain nothing because you use
>> >> macsec, IPsec or another link layer encryption, the cost of
>> >> double encryption on email is so low that you might as well
>> >> still run (opportunistic) TLS instead of unencrypted smtp.
>> >
>> > I have an old printer that e-mails "I'm jammed" or "I'm empty"
>> > notices in the clear to a local mail server. It's not going to
>> > change, and if we somehow imagine we're going to force people to
>> > reject its out of paper messages, we're just making ourselves
>> > look silly. New printers should certainly do STARTTLS, but we
>> > at least used to give lip service to backward compatability and
>> > existing practice.
>>
>> Let me take this a step or two further. First, as I think someone
>> else pointed out, if the IETF mandated STARTTLS and were wildly
>> successful, John's receiving MTA (and, btw, mine with some similar
>> problems) might decline to accept email unless it came over an
>> encrypted connection. At that point, the IETF would have mandated
>> significantly reduced functionality for the purpose of "protecting"
>> the equivalent of an "I'm jammed" message over a LAN. Bad for the
>> user and, as John has suggested, makes us look silly and maybe
>> damages our credibility.
>>
>> More important, while one view (see Paul's message) is that being
>> "out of touch of the NSA et all is the minimum viable product",
>> that view hides a few interesting assumptions.
>>
>> First, there is the issue of selective, rather than pervasive,
>> surveillance. I think I've written elsewhere about the GorillaMail
>> <-> OtherGorilla case. From the standpoint of encryption on the
>> wire, that may be the case supporting the largest number of
>> messages, at least in the US, Western Europe, and countries with
>> similar usage patterns. Anyone here believe that their hiring
>> practices are sufficiently selective, perhaps to the point of
>> omniscience, that the NSA (since the comment above focused on
>> them) could not succeed in getting an appropriately trained agent
>> embedded within the relevant part of the Gorilla organization
>> and/or compromising an existing employee? Against that sort of
>> attack, TLS and friends are perhaps only a notch above security
>> theater and the only realistic option someone trying to protect
>> the content of their messages has is something like S/MIME or PGP,
>> desktop to desktop.
>>
>> Second and perhaps more important globally (and the NSA aside),
>> suppose some collection of Internet users live in, say, Lower
>> Slobbovia. Then suppose that the government of Lower Slobbovia has
>> concluded that spying on in-transit traffic is necessary to protect
>> its citizens from various real or imaginary attacks and prohibits
>> the use of TLS or equivalent within the country. For users in that
>> country, there is then a choice between receiving mail in cleartext
>> (at least as far as the transport system is concerned) and being
>> cut off completely from the global Internet's email structure. If
>> all they are passing in and out of the country are favorite
>> recipes or the next move in a chess game, they may not care
>> whether the government intercepts those or not. They might even
>> like the idea of the government having to invest resources in
>> surveilling and evaluating such traffic. If they have
>> communications interests that the government would consider
>> inappropriate, they might have knowledge of centuries-old
>> traditions of using codes (not ciphers or other forms of
>> encryption) that can slip information past hostile spectators
>> disguised as something else.
>>
>> The two cases come together a bit if the Lower Slobbovian
>> government makes the use of private email systems illegal and
>> requires that all mail go through government-provided servers.
>> Then there would be no need to even bother with monitoring traffic
>> on the wire where capturing the traffic on those servers is far
>> easier.
>>
>> Do we really want to be in the position of having the IETF make the
>> decision to cut residents of that country off from the Internet,
>> preventing both casual conversations that don't need workarounds
>> and whatever other mechanisms they might adopt to carry out
>> conversations, perhaps even plot revolution, without the government
>> noticing? Only if the answer is "yes" is trying to fix email so
>> that sending unencrypted traffic between hosts is impossible a
>> good answer.
>>
>> > As I may have said once or twice, the STARTTLS stuff belongs in
>> > the A/S.
>>
>> And, for the reasons above, probably as strong advice, not an
>> "implementation that allows cleartext is non-conforming"
>> requirement or a suggestion that amessage that arrives without
>> transport encryption should be bounced or just silently dropped.
>>
>> john
>>
>> >
>> > R's,
>> > John
>> >
>> > PS:
>>
>>
>> --
>> last-call mailing list -- last-call@xxxxxxxx
>> To unsubscribe send an email to last-call-leave@xxxxxxxx
>>
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
