Re: [saag] reviews needed of draft-knodel-e2ee-definition

[Russ Housley <[e-mail]>]

I agree with EKR's comments.  In addition, I'd like to raise a few points of my own:

In Section 2.1, s/MAY/may/

In Section 2.2, it might be helpful to include Wi-Fi encryption as an example with is similar to 4G LTE.

In Section 2.3, it is not currently the case that double-ratchet algorithm, an AEAD, and an AKE are a "more common end-to-end technique". Sure this work is taking hold, but it is not yet common.

In Section 2.3, the phrase "to achieve a truly end-to-end encrypted communication system" is concerning.  The whole point of this document is to explain end-to-end encryption.  Please drop "truly".

In Section 2.3, the bias toward OpenPGP is odd.  At the level of detail in this document, OpenPGP and S/MIME both offer the same security services.  The two depend on very different approaches to bind a public key to an identity, but that is not really the point here.

In Section 3.1.1, I think that a TLS 1.3 session between a browser and a web server is an example of end-to-end encryption.  In most situations, the server is authenticated to the browser, but not the other way.  Yet, this definition requires that "the recipient and sender attest to each other's identities."  While I do not think we need to get into the difference between unilateral and mutual authentication in this document, this definition is not helping people understand end-to-end encryption.  Mutual authentication is not a necessary feature to achieve end-to-end encryption.

In Section 3.1.2, last paragraph, the phrase "truly confidential conversations" bothers me.  Please drop "truly". The definition of confidentiality talks about "messages". A sentence to explain conversations would be helpful, especially since the document requires mutual authentication for conversations later on.

In Section 3.2, the concept of an "account identity" is introduced.  I question whether this concept is needed in the document.

Russ

> On Sep 29, 2022, at 4:48 PM, Eric Rescorla <[e-mail]> wrote:
> 
> Document: draft-knodel-e2ee-definition-07.txt
> 
> I too have concerns about this draft as-is. I reviewed a previous
> version of this document (-02) and I see that a number of my comments
> [0] still apply, but in this message I want to talk about the bigger
> picture, specifically what function we expect this document to
> serve in the IETF.
> 
> The basic mismatch I see in that respect is that the IETF designs
> protocols and this document focuses on systems. For instance, consider
> three instant messaging systems:
> 
> - In System 1, all messages are TLS-encrypted between clients and
>   the server but in the clear on the server.
> 
> - In System 2, everyone has an app that they use for messaging and data
>    is encrypted all the way to the app using MLS.
> 
> - System 3, is much like System 1 except that someone has built
>   a client which runs on the server and which exposes a Web
>   interface.
> 
> Based on the text in Section 2.2, I take it that the position that
> this document takes is that only System 2 is E2E secure and that
> Systems 1 and 3 are not. While I agree that this is true from a
> systems level, it's not helpful in IETF, which concerns itself with
> designing protocols.
> 
> Specifically, there is an important distinction between a protocol
> like MLS, which is *compatible* with a fully E2E system and a protocol
> like TLS, which is not--at least for messaging--though it might be E2E
> in other contexts. And because the IETF's job is to design protocols,
> having a definition which tends to elide that distinction doesn't seem
> very helpful for our purposes, though it might of course be useful for
> other purposes. 
> 
> I think this document would be a lot more useful if it focused on
> protocol functionality and the system architectures it enables; the
> result would be something much shorter and more targeted, but would
> be more applicable to the work of the IETF.
> 
> -Ekr
> 
> 
> [0] https://mailarchive.ietf.org/arch/msg/secdispatch/BwmdjEnXlAjd8u4DWQgeSOKr6rA/ <https://mailarchive.ietf.org/arch/msg/secdispatch/BwmdjEnXlAjd8u4DWQgeSOKr6rA/>
> [1] There are, of course, settings in which TLS is used end-to-end,
>     but that's a separate topic.
> 
> On Thu, Sep 29, 2022 at 4:23 AM Eliot Lear <[e-mail] <mailto:[e-mail]>> wrote:
> I have to agree with Hannes, and would go further.  The document as it is should not be published, and needs some refocusing.
> 
> The problems begin in the abstract where it is not made clear what the reader will learn.  They continue into the introduction where the motivations for the work are not stated.
> 
> There are already far more concise definitions of end-to-end encryption.  The definition isn't the problem.  Attaining end-to-end encryption and understanding the tradeoffs and implications is at least one problem.  That is, intersecting Section 3.2 and 4 could make for a good piece of work.  Also, stuffing a definition of end-to-end security in the middle of the document is asking for trouble.
> 
> I could see value in exploring the relationship between the end-to-end principle and end-to-end encryption, but that to me strikes me as an academic exercise.  If that's what the authors want to do, great.  There are portions of RFC 3742 that could be addressed.  Absent that, huge swathes of Section 2 should shrink, and that which remains needs to be far better supported, and must support the thesis of the work.
> 
> I could see value in exploring end-to-end encryption in the context of RFC 8890.  But that doesn't always mean that the user is quite so visible.  Think about that water coming out of your tap and the control systems involved.
> 
> Anyway, to quote Yogi Berra, when you come to a fork in the road, take it.  Here we are.
> 
> Eliot
> 
> 
> 
> On 29.09.22 10:13, Hannes Tschofenig wrote:
>> I have read through the document. I am curious to what event has triggered the authors to work on it.
>> 
>>  
>> 
>> I have been asking myself several times in the document “Why are they writing about this issue?”
>> 
>>  
>> 
>> Ciao
>> Hannes
>> 
>>  
>> 
>> From: saag <[e-mail]> <mailto:[e-mail]> On Behalf Of Paul Wouters
>> Sent: Wednesday, September 28, 2022 11:49 PM
>> To: IETF SAAG <[e-mail]> <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>> Subject: [saag] reviews needed of draft-knodel-e2ee-definition
>> 
>>  
>> 
>> Hi,
>> 
>>  
>> 
>> A few people have been working on a document to define what it means to be end-to-end encrypted, and wrote this up in a draft.
>> 
>>  
>> 
>> https://datatracker.ietf.org/doc/html/draft-knodel-e2ee-definition-07 <https://datatracker.ietf.org/doc/html/draft-knodel-e2ee-definition-07>
>>  
>> 
>> I believe this work small and self-contained and would be beneficial to the community. Please provide feedback to the list and authors. Even if you just agree with publication, please let the list (or me) know so that we can gather some insights on the community consensus on this draft.
>> 
>>  
>> 
>> Authors: if you can, please respond to this message with any IPR claims or lack there of for the public record.
>> 
>>  
>> 
>> Paul
>> 
>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. 
>> 
>> _______________________________________________
>> saag mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/saag <https://www.ietf.org/mailman/listinfo/saag>
> _______________________________________________
> saag mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/saag <https://www.ietf.org/mailman/listinfo/saag>
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag