- From: Rob Sayre <sayrer@gmail.com>
- Date: Sun, 3 Nov 2024 15:06:35 -0800
- To: www-archive@w3.org
- Message-ID: <CAChr6Sx11hVE=6TiiWe_yS109HLdBCswgWGrLVVCr+ER_w2haA@mail.gmail.com>
Delivered-To: sayrer@gmail.com
Received: by 2002:a05:6a11:f24:b0:593:d985:66e8 with SMTP id sl36csp1719597pxb;
Sun, 3 Nov 2024 14:17:07 -0800 (PST)
X-Google-Smtp-Source:
AGHT+IHs6JJh4jIAIHjTZahBot0W4bko7TWfAyiEQ855BYShcmmyvjMQ7rtCjOk/YNdOA7jpGpe3
X-Received: by 2002:a05:622a:1988:b0:45f:8ee:1859 with SMTP id
d75a77b69052e-4613be77e58mr474209261cf.0.1730672227246;
Sun, 03 Nov 2024 14:17:07 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1730672227; cv=none;
d=google.com; s=arc-20240605;
b=ZrAiaplfwllvvxABfx8jXYXx4iWFhNOkOIsiOMhfv2edbx0d6T5sqkYuoPvd+DgBXq
JVSbahOA0Do5zph95OxxCvPgFZBfAG6Pm82g6RFvUPK3ueXmXEg5cmkhYrOZcZJ23fWq
rJbNgbrFM5TDVF79D2Z9L2W5pXmc+xmxIwbbpPyrt4OFas5YrbDPoIMYnYsz1/s7yPu6
LSq0bmadbUoSjcfhRHYtVU2B7jHLVzok8UGX46h7YB/kb5WEMtzz6XsY4MJeHlc5pCof
aw2vYHbYEO27u6hfiIQcKHvR4jNfpYuRUB1NAw+Qnb3GAD0L+nj6PASp/7OK51+S8A6q
71XA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=arc-20240605;
h=content-disposition:content-transfer-encoding:mime-version
:references:in-reply-to:message-id:subject:cc:to:from:date;
bh=M5qZdgII/ZUNhYBancP40LaYg8AXpkvLPhSEtigcSuk=;
fh=by1QHSHHcEGKVH1J1yWC4c0WKKRV2L6/x57kG2m+7g8=;
b=MGIlDo2xAJKw6QuWuHc4ddC7NhR9x/L7jeyY4BCHgBsJoOj+/L6v8ZIAwfng94y/cI
OcyFYQ/vJOQ0DgoYhuGPPYSurBMIKgjNnYWJEF3uZPJFMD+gSoHVppvUiZVgN3mNyN1E
FdiANhktvtQcsjzfeZaPvSyVyQyl3CH/XYTjaFc6R4JiXM4u8W4dcF/81guHbBtWWGQH
IaWL53kKfry5uShFGO8FSTmPhuYkGNqvpUqYi9ZITfwVAQwHkg0AQLiSV/nXjwqOYhup
KfjMj7ANTobk4aKYoJ+XTCraHZUUV6eOVetJdeDyyvW+hHrhUKV78vVeU0vwaFiAe7+K
2J4Q==;
dara=google.com
ARC-Authentication-Results: i=1; mx.google.com;
spf=pass (google.com: domain of john-ietf@jck.com designates
70.88.254.51 as permitted sender) smtp.mailfrom=john-ietf@jck.com
Return-Path: <john-ietf@jck.com>
Received: from bsa2.jck.com (bsa2.jck.com. [70.88.254.51])
by mx.google.com with ESMTPS id
d75a77b69052e-462ad249a7dsi91346991cf.613.2024.11.03.14.17.06
for <sayrer@gmail.com>
(version=TLS1 cipher=AES128-SHA bits=128/128);
Sun, 03 Nov 2024 14:17:07 -0800 (PST)
Received-SPF: pass (google.com: domain of john-ietf@jck.com designates
70.88.254.51 as permitted sender) client-ip=70.88.254.51;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of john-ietf@jck.com designates
70.88.254.51 as permitted sender) smtp.mailfrom=john-ietf@jck.com
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp
(Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id
1t7iu9-000KdO-VU; Sun, 03 Nov 2024 17:17:05 -0500
Date: Sun, 03 Nov 2024 17:16:59 -0500
From: John C Klensin <john-ietf@jck.com>
To: Rob Sayre <sayrer@gmail.com>
cc: emailcore@ietf.org
Subject: Re: [Emailcore] Re: [Last-Call] Re: Re: E2E encryption "ideal"
Message-ID: <3F698FF0313534FD85A45B08@PSB>
In-Reply-To: <CAChr6SytiPpG-96qAXwzMuoJA6gtbbbO_LEkP1ZfvJXzPYhy6g@mail.gmail.com>
References: <CAChr6SzD-0CTym566KRYOco2C2cpwyPmgRykAhqjD7udC7jKXA@mail.
gmail.com> <124C50BE8232652D081FB453@PSB>
<CAChr6SxN-Fn2eSauoKyEVbSBq2MPnXffAEaeiNUVUL5B9Ji53A@mail.gmail.com>
<2D47A26B88B3B659E6B2D06A@PSB>
<CAChr6SytiPpG-96qAXwzMuoJA6gtbbbO_LEkP1ZfvJXzPYhy6g@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Rob,
Let me try one more time but, after this, I'm planning to go silent
on the subject because you don't need to convince me, you need to
convince the WG and because I just don't think this is the most
important question on the WG's agenda....
--On Sunday, November 3, 2024 11:46 -0800 Rob Sayre
<sayrer@gmail.com> wrote:
> On Sun, Nov 3, 2024 at 11:35=E2=80=AFAM John C Klensin
> <john-ietf@jck.com> wrote:
>=20
>> Turning some of Dave Crocker's recent
>> comments around, "is clearly part of SMTP and would cause harm if
>> not fixed" would be a different matter, but it does not appear to
>> me that you or anyone else have made that case here.
>>=20
>=20
> I still think it is not that complicated. Why not recommend TLS?
Because that is not the issue, at least as Dave and I see it. The
issue is that it is not part of SMTP and that, even if it were, it
does not offer clear end to end security (small cause and effect
problem there because that is one of the reasons it is not part of
SMTP).
> Every hop should use it, but I do agree that there are no
> guarantees there.
Ok, then why on earth should SMTP recommend that every hop should use
it? Certainly there are reasons to recommend just that --and we have
been around and around about them-- but they are not because they
provide strong security/ privacy/ tamper-proofing for SMTP.
> I also think the draft is misleading as written. We could have
> written, in a pessimistic tone:
>=20
> "Security is provided by technologies almost no one uses, and don't
> matter anyway, since someone can just forward your message in an
> insecure manner."
Wow. My pessimistic version would be closer to:
"While S/MIME and PGP have their own issues, including ones related
to key management and failure to protect the SMTP envelope, if
properly used they can provide strong and reliable, end-to-end,
message content privacy protection and sender authentication.
Various methods, including link encryption methods like TLS, that
work only hop-by-hop may provide several advantages, including
signaling virtue, distracting those who are attempting pervasive
surveillance, and providing cover for anyone who wants to try to use
them to hide sensitive information, but they do not provide serious
information protection or sender authentication in the general case
because they work only on the links and not the intermediate systems
and therefore should not be relied upon for those purposes even
though their use might be desirable."
However, that still is not properly part of SMTP. The present text
describes the difference between end to end and hop by hop methods.
While the sentences that mention PGP and S/MIME can be read to be a
little bit more broadly, the text is otherwise almost entirely about
authentication rather than encryption or other forms of data
protection. Maybe we could or should, make that more clear. But
recommending something that is, at best, of questionable
effectiveness between sender and recipient just does not feel like an
appropriate part of an SMTP document to me and how easy or hard it is
to write the sentences is not relevant to that.
> Once you take that cynical view (which I do), TLS starts to look
> better as a recommendation. I think that's the issue.
Not sure I understand. Do you mean "well, we should understand that
it doesn't work but it would be good to recommend and use it anyway"?
If so, I don't find that persuasive. It sounds a bit too much like
"it isn't fit for purpose, but it is good for some purposes, so we
should recommend it". If so, and the purpose is not, e.g.,
protecting the privacy of mail between sender and receiver, then I
think you should explain what the purpose is... and then I will
probably suggest, again, that purpose isn't part of SMTP and you
should advocate it somewhere else.
Again, you don't have to convince me, you have to convince the WG.
I rather doubt that they will find an argument that sounds like "I
want this and it is easy to do" persuasive, but I'm not the judge
either.
john
Received on Sunday, 3 November 2024 23:06:51 UTC