Return-Path: X-Original-To: keytrans@mail2.ietf.org Delivered-To: keytrans@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id CE140B022CA; Thu, 13 Mar 2025 14:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbbcOHcHqw1l; Thu, 13 Mar 2025 14:02:32 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 5D7C8B02236; Thu, 13 Mar 2025 14:02:32 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-43cfe574976so9314515e9.1; Thu, 13 Mar 2025 14:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741899751; x=1742504551; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=fi2MNuT/zhiFEVbxHUXwh7hdpgKFc/7wB3nUZAFN558=; b=gfvgzlgsvM/5m7lehf5C2PRPtf5BhB8BiTtBaDYuNkWYn+8ukOaMOHES44NBSvpc2R yO7xziva5jFPkicoCi6eUqqcsmJfwUvJX8O/wIJy8HCe6y9lzOIlnf9ScZ7PsBhYXH/i WR+FhVnh1wTj5tfKOhSTbh4xfqPGXy8tezARxCusbz7YCYFM+RlLNgduRqXHEom4taDA LHTXZzBMTwNZhM0sZb1vNUeYF0XXBv6Ka17t8PLL2jOzieZrY8cNzZa8XeESqChCRCbE 0ZbYspgB3tdWlFgwVLlhpJwjqQDCdC1SbmbJfpSQ5Nk5Bu1Y6pWqvsOX1sWMCzAJjFfA /HIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741899751; x=1742504551; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fi2MNuT/zhiFEVbxHUXwh7hdpgKFc/7wB3nUZAFN558=; b=RoNiGRvN3ZNyFC+CFuIBm+wRzvgqMWTYSMfoMvFIII6KtWN970SjZx+8XJhjMD5g0Q m8ARg36K8bIjZ5C2JjspJU27cKeU3J/0/6U0IZIp4Ruq7Lo5GuPIV72UNeO9F7Ao+7JE 7JibaY60u8C381O33CqEXvwCrJV4qPO0ZjX1Wmi/R/6ZN5gm1/9yhXu5xX1G8tVJh1kg PhYKO3DqfKoxUN7yQtuTZ97W++a0G680a4Ytz4JaENHTVP84ISHqaGuEQlqsQkNrxHgW B9j29dJX0BY21SIXQbDkzLLbabyHgY92xYoAADwhYiVUmkq2HLAgyfd9iYxdOwgyVUkF x6ew== X-Forwarded-Encrypted: i=1; AJvYcCVmgRgzkL9WwaXv21c3Eqv0TGt9CMoEwZPXiWQJJFgp6cvg1HWNDJcS0Xsat9G9X1WW+A74lzY+ul4=@ietf.org, AJvYcCVzXx7Trox+TyPOa3H9QcQEBRDgAQF9TDgiHiD+pI6+9QTrijQaEM2ySI1oNF62RCVn+hTHCi/qWNJBQeRLaC3SlUpCVqv/IG5U0pcW@ietf.org, AJvYcCXWUcwvMHJ2lmWfidBl7NUCkAGwW0rpCUXvcWUHyXMIbCRkqnTLNXMHu1r2LaanWhqIO5yB@ietf.org X-Gm-Message-State: AOJu0YxA0/8E1cs1fgzQqoE7mXqsX++1mUp+1yWjA+ospndcBeCYQH97 SPqKp8TqG9frZJDKsHJ5TXCgYUzht+LP7hNcSqheMSSnh89chCXz X-Gm-Gg: ASbGncuLQyVMs8+r38vVWvbBO/Tsb4Z1f+R5s666kdi+3pan/9dSDLpZcxTVLRcA1+m mV3B5Md6W5qZQXKIlooTFVnLk2IPoP12mTVadvvH46zpDRVFPDRtmgcXnBLKIJ9ORaBKK5pz3kd ca075YAk/B/lKBYzls4VThmqXqRTZ72qvAYwpyCJI8yuEVtEfjhhTUooWgIYzaZ3uN1kc1S23a1 e0Lgir4vpAUuXKDpDFcGH/pkynRLR92ipywUzG4F+m7BxkL3BZFdE91hqamLwGjuBbdmTRz/IjP Is6r+XctS2o2s76B1morh9O6uUeBgRWmxnccuUxtdjzBg8e0EOWBvF65UD3Xuh6k X-Google-Smtp-Source: AGHT+IEiQCOvmxuGaYndMcx0AV+RNZnEoXuG/cASI6wnYo3B/O99SliS0OIZ/OjN5sAPOYIrLGLtRg== X-Received: by 2002:a05:600c:3108:b0:43c:fe15:41e1 with SMTP id 5b1f17b1804b1-43d1ec66daamr870575e9.4.1741899750991; Thu, 13 Mar 2025 14:02:30 -0700 (PDT) Received: from smtpclient.apple ([212.77.220.109]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43d18a2aec8sm31911325e9.27.2025.03.13.14.02.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Mar 2025 14:02:30 -0700 (PDT) From: Felix Linker Message-Id: <67D1B34C-701A-4CB4-B2BE-FCC51CCF596F@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_049E7C9F-3517-4474-8826-A97B65DA73EE" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3818.100.11.1.3\)) Date: Fri, 14 Mar 2025 00:02:17 +0300 In-Reply-To: <70B0FA23-E333-4A65-9D56-1615202BB668@nps.edu> To: "Hale, Britta (CIV)" References: <2a84ec57-2481-4cc9-b7de-3709794f305f@cis-india.org> <70B0FA23-E333-4A65-9D56-1615202BB668@nps.edu> X-Mailer: Apple Mail (2.3818.100.11.1.3) Message-ID-Hash: 4SBADETLLHNSCBKGGC7MCEC6BYJE4OB2 X-Message-ID-Hash: 4SBADETLLHNSCBKGGC7MCEC6BYJE4OB2 X-MailFrom: linkerfelix@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Brendan McMillion , Mallory Knodel , Gurshabad Grover , "mls@ietf.org" , "draft-knodel-e2ee-definition@ietf.org" , "keytrans@ietf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BKeytrans=5D_Re=3A_=5BMLS=5D_Re=3A_Definition_of_end-to-end_encr?= =?utf-8?q?yption_for_communication?= List-Id: Key Transparency Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_049E7C9F-3517-4474-8826-A97B65DA73EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi everyone, Thanks, Brendan, for bringing this interesting draft to my attention! I = just read it and would like to join this discussion, but will also = submit an independent review. I find the addition of "without the user being aware of the = third-party=E2=80=99s access=E2=80=9C to authentication a bit weird. It = seems motivated by key transparency and only key transparency. It is standard that systems can only provide desirable guarantees under = certain assumptions. There are many assumptions that one might want to = make. In a system using key transparency, the assumption would be that = the service provider does not want to be caught lying. I find it = absolutely acceptable to design systems that do not make this assumption = and where providers are trusted to only provide authentic key material. If we were to add this assumption about =E2=80=9Edetectability=E2=80=9C = into the draft, why not also add standard cryptographic assumptions to = other properties? For example, it is not impossible for other parties to = read encrypted communication. It should only be possible with negligible = probability. Likewise, we could add that clients must use uncorrupted = devices and clients. I think this starts getting silly quite quickly. I find it fine that the draft does not mention some implicit assumptions = that will need to be made explicit for concrete designs. In particular, = I find it absolutely fine that the end user expectation is that "it = should not be possible for any third-party end point [=E2=80=A6] to = access the data.=E2=80=9C The =E2=80=9Eexpectation=E2=80=9C and the = =E2=80=9Eshould=E2=80=9C already cover that this may not be the case in = reality. Best, Felix > On 12 Mar 2025, at 21:54, Hale, Britta (CIV) = wrote: >=20 > I concur with the second one. > It is probably worth the clarification addendum =E2=80=9C=E2=80=A6withou= t the user being aware of the third-party=E2=80=99s access.=E2=80=9D > =20 > Britta > =20 > =20 > From: Brendan McMillion > > Date: Wednesday, March 12, 2025 at 1:40=E2=80=AFPM > To: Mallory Knodel > > Cc: Gurshabad Grover >, "mls@ietf.org = " >, = "draft-knodel-e2ee-definition@ietf.org = " = >, "keytrans@ietf.org = " > > Subject: [MLS] Re: Definition of end-to-end encryption for = communication > =20 > NPS WARNING: *external sender* verify before acting. > =20 > Hi Mallory=20 > =20 > My point was actually that KT doesn't seem to meet the document's = definition, nor any other approach I can think of. More specifically, = the text I'm taking issue with is this: > =20 >> No matter the specifics, any methods used to access to the content of = the messages by a third party would violate a user's expectations of = end-to-end encrypted messaging... It should not be possible for any = third-party end point, even those under the user's identity as per = Section 2.1, to access the data regardless of reason. > =20 > No e2ee messenger makes it "not possible" for a third-party to access = user messages. This is because any e2ee messenger can just distribute = the wrong public keys for a user and man-in-the-middle. It would be more = accurate to either say: > =20 > - It is not possible for a third-party to access a user's messages = **assuming that** the service provider does not take action to enable = it. Or, > - It is not possible for a third-party to access a user's messages = without the user being aware of the third-party > =20 > The second one is obviously a stronger, and I think preferable, = condition since it can not be secretly undermined by the service = provider. > =20 > On Tue, Mar 11, 2025 at 12:51=E2=80=AFPM Mallory Knodel = > wrote: >> Hi Brendan, >> =20 >> Thanks for reading the draft.=20 >> =20 >> Indeed key transparency seems to be a way to achieve this part of the = doc=E2=80=99s definition.=20 >> =20 >> The rest of your comment seems to be a deeper read into issues not = raised nor confronted by the text. >> =20 >> -Mallory >> =20 >> -Mallory >> =20 >> On Tue, Feb 25, 2025 at 22:27 Brendan McMillion = > wrote: >>> The document states that authenticity is a necessary property: >>> =20 >>>> Authentication: A system provides authentication if the recipient = and sender can verify each other's identities in relation to the = contents of their communications. >>> =20 >>> There is a lot to unpack in this definition. Assuming that this is a = client-server architecture where the client talks only to some Service = Provider server, the server can always lie in the short-term and say = "this is Brendan's public key" when it really isn't. So claims that it = should be "impossible" do not stand. The question then is, at what point = is the lie detected? Never? When the two users get together in-person = and scan each other's QR codes (so, also never)? Key Transparency = provides that such a lie can be detected within a bounded amount of = time. I obviously would support prescribing KT as a "necessary" part of = e2ee but I don't know that this was intentional on your part. >>> =20 >>> Of course, if the answer to "when is the lie detected" is either "we = trust the service provider not to lie" or "never", then stating = authenticity as a requirement would seem to be empty to me. >>> =20 >>> On Fri, Feb 21, 2025 at 4:36=E2=80=AFAM Gurshabad Grover = > wrote: >>>> Hey! >>>>=20 >>>> We wanted to (re-) start discussion on the Definition of End-to-end=20= >>>> Encryption I-D.=20 >>>> = > >>>>=20 >>>> The I-D defines end-to-end encryption, discusses the security = properties=20 >>>> that make up end-to-end encrypted communication, and associated=20 >>>> implementation considerations and challenges. >>>>=20 >>>> We feel that the I-D can serve multiple purposes: >>>>=20 >>>> (1) serve as a baseline for IETF working groups specifying = end-to-end=20 >>>> encryption communication, a term used but not defined previously at = the=20 >>>> IETF; >>>>=20 >>>> (2) provide a reference for inside and outside the IETF to = understand=20 >>>> when a communication protocol/system is in fact end-to-end = encrypted,=20 >>>> particularly because the term has been prone to abuse outside the = IETF=20 >>>> and the topic has been subject to legislation/regulation that = improperly=20 >>>> interprets the term or aims to undermine security guarantees of=20 >>>> end-to-end encrypted communication. >>>>=20 >>>> This I-D was written first in 2021, and has evolved significantly = since=20 >>>> then, thanks to extensive discussions and review in the saag = mailing=20 >>>> lists, feedback from the IAB, and some suggestions from MLS = participants. >>>>=20 >>>> We feel that MLS is the perfect place to discuss and finalise this=20= >>>> definition, given that it has the most experience in creating a=20 >>>> specification for an e2ee system. >>>>=20 >>>> We welcome your feedback on the I-D, and will seek some time at the = next=20 >>>> MLS meeting to discuss it. >>>>=20 >>>> Thanks! >>>>=20 >>>> - Mallory, Sof=C3=ADa, Olaf, GG >>>>=20 >>>> _______________________________________________ >>>> MLS mailing list -- mls@ietf.org >>>> To unsubscribe send an email to mls-leave@ietf.org = --=20 > Keytrans mailing list -- keytrans@ietf.org > To unsubscribe send an email to keytrans-leave@ietf.org --Apple-Mail=_049E7C9F-3517-4474-8826-A97B65DA73EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = everyone,

Thanks, Brendan, for bringing this = interesting draft to my attention! I just read it and would like to join = this discussion, but will also submit an independent = review.

I find the addition of "without the = user being aware of the third-party=E2=80=99s access=E2=80=9C to = authentication a bit weird. It seems motivated by key transparency and = only key transparency.

It is standard that = systems can only provide desirable guarantees under certain assumptions. = There are many assumptions that one might want to make. In a system = using key transparency, the assumption would be that the service = provider does not want to be caught lying. I find it absolutely = acceptable to design systems that do not make this assumption and where = providers are trusted to only provide authentic key = material.

If we were to add this assumption = about =E2=80=9Edetectability=E2=80=9C into the draft, why not also add = standard cryptographic assumptions to other properties? For example, it = is not impossible for other parties to read encrypted = communication. It should only be possible with negligible probability. = Likewise, we could add that clients must use uncorrupted devices and = clients. I think this starts getting silly quite = quickly.

I find it fine that the draft does not = mention some implicit assumptions that will need to be made explicit for = concrete designs. In particular, I find it absolutely fine that the end = user expectation is that "it should not be possible = for any third-party end point [=E2=80=A6] to access the data.=E2=80=9C = The =E2=80=9Eexpectation=E2=80=9C and the =E2=80=9Eshould=E2=80=9C = already cover that this may not be the case in = reality.

Best,
Felix
On 12 Mar 2025, at 21:54, Hale, Britta = (CIV) <britta.hale@nps.edu> wrote:

I = concur with the second one.
It is probably worth the clarification = addendum =E2=80=9C=E2=80=A6without the user being aware of the = third-party=E2=80=99s access.=E2=80=9D
 
Britta
 
 
From: Brendan McMillion <brendanmcmillion@gmail.com>
Date: Wednesday, March 12, = 2025 at 1:40=E2=80=AFPM
To: Mallory Knodel <mallory.knodel@nyu.edu>
Cc: Gurshabad Grover <gurshabad=3D40cis-india.org@dmarc.ietf.org>, "mls@ietf.org" <mls@ietf.org>, = "draft-knodel-e2ee-definition@ietf.org" <draft-knodel-e2ee-definition@ietf.org>, "keytrans@ietf.org" <keytrans@ietf.org>
Subject: [MLS] Re: Definition of = end-to-end encryption for = communication
 
NPS WARNING: *external = sender* verify before acting.
 
Hi Mallory 
 
My point was = actually that KT doesn't seem to meet the document's definition, nor any = other approach I can think of. More specifically, the text I'm taking = issue with is this:
 
No matter the specifics, any methods used to access to the = content of the messages by a third party would violate a user's = expectations of end-to-end encrypted messaging... It should not be = possible for any third-party end point, even those under the user's = identity as per Section 2.1, to access the data regardless of = reason.
 
 No e2ee = messenger makes it "not possible" for a third-party to access user = messages. This is because any e2ee messenger can just distribute the = wrong public keys for a user and man-in-the-middle. It would be more = accurate to either say:
 
- It is not = possible for a third-party to access a user's messages **assuming that** = the service provider does not take action to enable it. = Or,
- It is not possible for a = third-party to access a user's messages without the user being aware of = the third-party
 
The second one is = obviously a stronger, and I think preferable, condition since it can not = be secretly undermined by the service = provider.
 
On Tue, Mar 11, 2025 at 12:51=E2=80=AFPM Mallory Knodel <mallory.knodel@nyu.edu> = wrote:
Hi = Brendan,
 
Thanks for = reading the draft. 
 
Indeed key = transparency seems to be a way to achieve this part of the doc=E2=80=99s = definition. 
 
The rest of your = comment seems to be a deeper read into issues not raised nor confronted = by the text.
 
-Mallory
 
-Mallory
 
On Tue, Feb 25, 2025 = at 22:27 Brendan McMillion <brendanmcmillion@gmail.com> = wrote:
The document states that authenticity = is a necessary property:
 
Authentication: A system provides = authentication if the recipient and sender can verify each other's = identities in relation to the contents of their = communications.
 
There is a lot to = unpack in this definition. Assuming that this is a client-server = architecture where the client talks only to some Service Provider = server, the server can always lie in the short-term and say "this is = Brendan's public key" when it really isn't. So claims that it should be = "impossible" do not stand. The question then is, at what point is the = lie detected? Never? When the two users get together in-person and scan = each other's QR codes (so, also never)? Key Transparency provides that = such a lie can be detected within a bounded amount of time. I obviously = would support prescribing KT as a "necessary" part of e2ee but I don't = know that this was intentional on = your part.
 
Of course, if the = answer to "when is the lie detected" is either "we trust the service = provider not to lie" or "never", then stating authenticity as a = requirement would seem to be empty to = me.
 
On Fri, Feb 21, 2025 = at 4:36=E2=80=AFAM = Gurshabad Grover <gurshabad=3D40cis-india.org@dmarc.ietf.org> = wrote:
Hey!

We wanted to (re-) start discussion on = the Definition of End-to-end 
Encryption I-D. 
<https://datatracker.ietf.org/doc/html/draft-knodel-e2ee-defini= tion-11>

The I-D defines end-to-end encryption, discusses = the security properties 
that make up end-to-end = encrypted communication, and associated 
implementation = considerations and challenges.

We feel that the I-D can serve = multiple purposes:

(1) serve as a baseline for IETF working = groups specifying end-to-end 
encryption = communication, a term used but not defined previously at the 
IETF;

(2) = provide a reference for inside and outside the IETF to understand 
when a communication = protocol/system is in fact end-to-end encrypted, 
particularly because = the term has been prone to abuse outside the IETF 
and the topic has been = subject to legislation/regulation that improperly 
interprets the term or = aims to undermine security guarantees of 
end-to-end encrypted = communication.

This I-D was written first in 2021, and has = evolved significantly since 
then, thanks to = extensive discussions and review in the saag mailing 
lists, feedback from = the IAB, and some suggestions from MLS participants.

We feel that = MLS is the perfect place to discuss and finalise this 
definition, given that = it has the most experience in creating a 
specification for an = e2ee system.

We welcome your feedback on the I-D, and will seek = some time at the next 
MLS meeting to discuss = it.

Thanks!

- Mallory, Sof=C3=ADa, Olaf, = GG

_______________________________________________
MLS mailing = list -- mls@ietf.org
To unsubscribe send an = email to mls-leave@ietf.org
-- 
Keytrans mailing list -- = keytrans@ietf.org
To = unsubscribe send an email to = keytrans-leave@ietf.org

= --Apple-Mail=_049E7C9F-3517-4474-8826-A97B65DA73EE--