Re: [saag] Revised version of draft-knodel-e2ee-definition

[John Mattsson <[e-mail]>]

To summarize my earlier comment. I don’t think this is far from ready. 4 high level reasons:

  1.  It defines e2e encryption with so much requirements that its incompatible with almost all current services that claim to be e2e. That should at least be made clear.
  2.  Instead of promoting PFS it problematizes PFS in a way I would say is not correct at all. I would like a sentence saying PFS is essential for the security of the system. But I could live the sentence being removed.
  3.  The assumption that the Providers are trustworthy and Access by a third-party is impossible is almost always wrong and will continue to be wrong. Following zero trust principles you should assume that the providers will misbehave, that they will share info with third parties, and that they will be breached. Based on that you should minimize the impact to yourself. I would strongly like the draft to problematize these aspects, but an alternative is to just remove the section.
  4.  I don’t find it very relevant for any reader to discuss the encryption without discussing the whole system including key management and storage. The e2e encryption matters little if the rest is not secure.

John

From: saag <[e-mail]> on behalf of Black, David <David.Black=[e-mail]>
Date: Friday, 21 April 2023 at 17:04
To: Mallory Knodel <[e-mail]>
Cc: Paul Wouters <paul.wouters=[e-mail]>, IETF SAAG <[e-mail]>
Subject: Re: [saag] Revised version of draft-knodel-e2ee-definition
Mallory,

> Thanks a lot for those suggestions. I think likely in 2.1 we should probably say content instead of messages.

That may help – it’s important to explain what is in and not in scope and/or what the focus of the draft is.  Ideally, there will be crisp language added that makes it easy to determine what is outside the scope of applicability.

> To that end I am not sure we should be specific by listing applicability in the abstract, given it could never be an exhaustive list.

The Abstract ought to say something about applicability to avoid the impression that this draft is generally applicability.  I would also consider including the word “content” or “messages” in the title of the draft.

Thanks, --David

From: Mallory Knodel <[e-mail]>
Sent: Friday, April 21, 2023 10:51 AM
To: Black, David
Cc: Alan DeKok; IETF SAAG; Paul Wouters
Subject: Re: [saag] Revised version of draft-knodel-e2ee-definition


[EXTERNAL EMAIL]
David,

Thanks a lot for those suggestions. I think likely in 2.1 we should probably say content instead of messages. Perhaps there are other places where we need to be vigilant about what we mean. It is meant to be general.

To that end I am not sure we should be specific by listing applicability in the abstract, given it could never be an exhaustive list.

Open to views and suggestions,
-Mallory

On Fri, 21 Apr 2023 at 10:28, Black, David <[e-mail]<mailto:[e-mail]>> wrote:
Hi Mallory,

> Yes, indeed the audience is the IETF and in particular protocol engineers who are implementing e2ee in messaging, email, voice, video and other uses.

It would be very helpful to refine and state that intended applicability in both the Abstract and Introduction.

An example of where this would help is the discussion of Deniability in section 3.1.2 as optional/desirable.  That discussion is plausible in this focus/scope/domain, but it is not plausible for end-to-end encryption in full generality, as there are other contexts  in which the exact opposite of Deniability, namely non-repudiation, is desirable.  The Availability discussion in that section is also focus/scope/domain-specific.

A possible place to start would be to expand section 2.1’s use of “messages” to explain what is meant/envisioned by “messages” (e.g., it appears that a packet is not always a message).  Examples would help, including (negative) examples of Internet communications that do not consist of “messages.”

Thanks, --David

From: saag <[e-mail]<mailto:[e-mail]>> On Behalf Of Mallory Knodel
Sent: Friday, April 21, 2023 9:28 AM
To: Alan DeKok
Cc: Paul Wouters; IETF SAAG
Subject: Re: [saag] Revised version of draft-knodel-e2ee-definition


[EXTERNAL EMAIL]
Hi Alan,

Thanks a lot for reading the draft and providing feedback.

Yes, indeed the audience is the IETF and in particular protocol engineers who are implementing e2ee in messaging, email, voice, video and other uses. We want this document to be readable. To that end we have also made significant reductions in the text so that it is incisive and to the point, which was from previous feedback that we all agreed with.

It is aiming at a definition, not an explainer.

-Mallory

On Fri, 21 Apr 2023 at 09:15, Alan DeKok <[e-mail]<mailto:[e-mail]>> wrote:
On Apr 21, 2023, at 8:50 AM, Tony Rutkowski <[e-mail]<mailto:[e-mail]>> wrote:
> The point is that this definition has a lengthy history with many diverse applications and use cases.  No review is necessary.

  Again, I'm not asking for a review.  I'm suggesting that the document should give the reader a gentle introduction to the subject.

  My comments were editorial and not technical.  I'm not sure why that isn't coming across, despite me saying it repeatedly.

> It is best - as you alternatively suggest - that those use cases can be included in a separate paragraph.
> If this is intended for people who don't intend the subject, the importance of being balanced and inclusive is even more important.  As the EU Resolution notes, there are both benefits and detriments that are context dependent.

  That is essentially the view that we can't describe any use-case without describing them all, because all of them are important.  Which makes for a very difficult document to read.

  Is the intention of this document to be read by average people?  Or only people familiar with 170 years of the subject?  Because your comments are leaning towards the second, and are pejorative towards the first.

  Perhaps the document could begin with something like this:

  "End-to-end encryption is AT LEAST situation X that everyone is familiar with.  We will leverage this use-case as an example of why end-to-end encryption is useful, and how it works.  We will also leverage this use-case to provide a comprehensive overview of the history of end-to-end encryption, and describe where else it can be used".

  But perhaps that kind of gentle introduction is not needed.  We should instead leap in with complex text which assumes the reader already understands everything about the subject.

  I don't think I have any more to add here.  My comments were abundantly clear.  Saying "LA is on the west coast" is not pejorative towards San Diego, and is not political advocacy that San Diego shouldn't exist.

  Alan DeKok.

_______________________________________________
saag mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/saag [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/saag__;!!LpKI!iGhk-orr4dIxfugXWeun5irEk6U7RzwPnhjCF0jAJEPbHmEgPlfVb8bey1yRwkTWD_FEyXB0UIKE02Y$>
--
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780

--
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780