The historic motivation for opportunistic security is not that it makes the system completely secure, but that it reduces the number of opportunities for attacks, renders them more expensive, and hence renders users somewhat safer. It's absolutely true that requiring STARTTLS doesn't solve the problem. But in practice it really does make a difference, and that's why the consensus in the market has gone in the direction of enabling it.
I haven't heard a strong argument for not adding this requirement, and I don't think a detailed security analysis is required. We already have RFC 7435, which I think does a good job of explaining why this is important. A reference to that RFC would fully explain the change and would not encourage unrealistic expectations.
On Wed, Oct 30, 2024 at 6:36 AM John C Klensin <john-ietf@xxxxxxx> wrote:
--On Tuesday, October 29, 2024 08:55 +1300 Brian E Carpenter
<brian.e.carpenter@xxxxxxxxx> wrote:
>...
>> I think the document could use a sentence here saying what it
>> doesn't cover. SMTP is incredibly insecure, but that's the state
>> of play.
>
> I've been trying to stay out of this one, but here goes.
> The Security Considerations start by saying "SMTP mail is
> inherently insecure" which is undoubtedly true, although
> "Transmission of mail via SMTP is inherently insecure" might be
> more precise.
A change I'm happy to make if the WG is ok with it, but note that
this is another one of those sentences that has been with us since at
least RFC 2821 in 2001. I don't have time to run it down but I
suspect it may come from even earlier text. As I have suggested
before, I (and I assume the WG) would really appreciate it if people
would read Sections 1.1 and 1.2 and understand the present document
in the context of the latter. Should we have completely rewriten the
thing around 2000 instead of patching multiple documents together?
Perhaps so. But, unless someone has the resources to hire a very
good technical editor with an understanding of IETF protocols to do
that _and_ knows how to put together a WG with the energy to ensure
that any inadvertent errors are caught and corrected, that certainly
is not going to happen now.
So, the question is whether it is worth changing this one sentence is
worth it given dozens of other rough edges in the document. And, for
this case, if "SMTP" were not specifically a "Mail Transport
Protocol", the improved sentence would not look as redundant.
> So I am a bit surprised that the next sentence
> doesn't require STARTTLS and cite RFC 3207 and RFC 7817. It seems
I'm happy to have you ask Alexey to create a ticket and have the WG
discuss this, but my quick answer answer is that such citations would
just about require an analysis of problems those specifications would
and would not solve. That analysis would probably be controversial
and drag things out further.
> to me that this would be a practical response to Donald's comments
> about transport authentication and surveillance, and I don't see
> why it should be kicked to the future Applicability Statement. In
> particular, it deals with both threats against SMTP (a *transfer*
> protocol) - alteration to the content, and capture of the content.
Only if the scenario Paul Wouter's describes as:
> In practise, the pipeline is a few hops trusted by the sender,
> followed by a direct delivery to the mx target with no
> intermediate/backup MX, followed by a few anti-spam hops trusted by
> the receiver. So the chance of email modification is low.
were universally true. Unfortunately, once one ventures
significantly out of the words of what many in the email environment
might describe as gorilla <-> gorilla or smaller provider <-> gorilla
communications, it isn't. As soon as either:
* a relay enters the system that can potentially be
compromised or
* the (human) sender or receiver has little or no reason to trust
their email provider (especially a provider -- possibly including
governmental entities-- that is under the control of a party
interested in the message content or one whose business model
includes harvesting and using or selling information) the protection
offered by TLS and similar tools becomes dubious at best.
> Just a couple of sentences could capture these threats and STARTTLS
> as the mitigation.
Having tried in other contexts, I don't think so. And STARTTLS
provides no mitigation at all if the message can be captured while it
sits on an intermediate system.
> I agree with John Klensin that DMARC, DKIM and the like are out of
> scope for SMTP as such. They aren't part of simple mail *transfer*
> so they don't belong here.
> The rest of the Security Considerations are really about
> operational security and, presumably, are based on experience.
Yep.
I just noticed that another 15 messages came in while I was working
on this one. Maybe tomorrow. And maybe then I can finish up the
half-complete response to Donald's note.
As a preview in case I can't get back to it or the additional
messages distract me, two observations:
(1) I would welcome a document that carefully analyzed the threat
models for SMTP/Message Format based email (including both
confidentiality and authentication), presented remedies, and analyzed
their strengths and weaknesses (including attacks against the
remedies themselves). Ideally, I'd like to see an end to end analysis
that would also include submission servers and some issues
draft-ietf-emailcore-rfc5322bis probably should have covered if the
same criteria for an adequate Security Considerations section were
applied there. However, I think it would be a major effort and not,
e.g., "a couple of sentences" that could be dropped into
SMTP/rfc5321bis or even into draft-ietf-emailcore-as. Whether some
halfway or half-baked approximation (with "half" possibly being too
optimistic) would be worth the trouble and the risk of confusion or
misleading users that it might cause leads to the other observation.
(2) If we are in a situation where those whose concerns about the
presentation and coverage of security issues believe that this
document should not move forward unless their concerns are addressed
as they would prefer, this is likely to turn into a question for the
IESG (and perhaps the larger IETF community) as to whether to agree
with that position and, if so, whether we are better off with this
document or dropping it and staying with RFC 5321. While I'd be happy
to be wrong, experience over the last year of so causes me to doubt
that the WG has the energy to complete the needed analysis in a way
that would be satisfactory to all concerned.
I am, again, only guessing about how the WG feels about the above,
but these issues have been discussed enough there that it is not a
completely wild guess.
best,
john
--
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
