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’s access“ 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 „detectability“ 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 […] to access the data.“ The „expectation“ and the „should“ 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 “…without the user being aware of the third-party’s access.”
>  
> Britta
>  
>  
> From: Brendan McMillion <brendanmcmillion@gmail.com <mailto:brendanmcmillion@gmail.com>>
> Date: Wednesday, March 12, 2025 at 1:40 PM
> To: Mallory Knodel <mallory.knodel@nyu.edu <mailto:mallory.knodel@nyu.edu>>
> Cc: Gurshabad Grover <gurshabad=40cis-india.org@dmarc.ietf.org <mailto:gurshabad=40cis-india.org@dmarc.ietf.org>>, "mls@ietf.org <mailto:mls@ietf.org>" <mls@ietf.org <mailto:mls@ietf.org>>, "draft-knodel-e2ee-definition@ietf.org <mailto:draft-knodel-e2ee-definition@ietf.org>" <draft-knodel-e2ee-definition@ietf.org <mailto:draft-knodel-e2ee-definition@ietf.org>>, "keytrans@ietf.org <mailto:keytrans@ietf.org>" <keytrans@ietf.org <mailto: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 PM Mallory Knodel <mallory.knodel@nyu.edu <mailto: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’s 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 <mailto: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 AM Gurshabad Grover <gurshabad=40cis-india.org@dmarc.ietf.org <mailto:40cis-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-definition-11 <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dknodel-2De2ee-2Ddefinition-2D11&d=DwMFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=krANNudPSfUTEf2kXiduBUqRjXhDsKNCASr1kibHLfs&m=BQBzFfbBWgMSNCDBbgEfB6kFUV0yGHa19okzrHp5XnAgkneL22pv_LpilqVBDxtn&s=yX0aXZFZdQQIQN3tzTZIgOJcNFesuAhkYkPDcO6z5DY&e=>>
>>>> 
>>>> 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ía, Olaf, GG
>>>> 
>>>> _______________________________________________
>>>> MLS mailing list -- mls@ietf.org <mailto:mls@ietf.org>
>>>> To unsubscribe send an email to mls-leave@ietf.org <mailto:mls-leave@ietf.org>-- 
> Keytrans mailing list -- keytrans@ietf.org
> To unsubscribe send an email to keytrans-leave@ietf.org