Re: [E2ee] Review of review-draft-knodel-e2ee-definition-04

[Mallory Knodel <[e-mail]>]

Hi Paul,

Thanks very much for your review! New version is up: 
https://github.com/mallory/e2ee/blob/main/draft-e2ee.md (I missed the 
upload by 14 minutes).

I've put the nits into a simple commit here: 
https://github.com/mallory/e2ee/commit/907c293267ad735c828eb3ba384714faa0902441

Below are some outstanding discussion items and additional commits to 
address the rest.

In the interest of moving the draft forward a bit:

  1. Would you be willing to be the responsible AD for this document?

  2. Are there WG sessions at 114 where you think we should request 
agenda time to present? So far we have presented at MLS, Secdispatch and 
OpenPGP. There may be other WGs who might send in helpful reviews, which 
at this stage is what we are still hoping for.

Thanks! And see below:

On 6/14/22 6:37 PM, Paul Wouters wrote:
> Perhaps the most important part is that it seems to want to say that
> E2EE systems are end to end encrypted but more. Is that really what
> we need? Should we say Privacy Enhanced systems which have as one
> component E2EE? Or do we really want to say "E2EE systems are end to
> end encrypted systems that also tend to have a lot of other features". I
> think the latter is meant, but then I think at a minium the abstract and
> introduction should be a lot more clear about this.
>
"E2EE systems" is fully equivalent to "end-to-end encrypted systems". We 
are trying to solve the problem that nowhere is there agreement on the 
minimum features of E2EE that makes something E2EE. This is becoming a 
problem because I keep hearing this rumours that content moderation (of 
messages in encrypted apps) doesn't break E2EE.

We need to make this clearer and I'm open to ideas about how.

> Also the use of E2EE versus "end-to-end" is confusing, eg:
>
>    Below is an exhaustive, yet vaguely summarised, list of the
>    challenges currently faced by protocol designers of end-to-end
>    encrypted systems.
>
> I thought it would say E2EE systems, as that is the term this document
> is defining, and end-to-end encryption is only one aspect of an E2EE
> system - or at least I think the document wants to define this as such?
>
Done. I have edited the document to only use E2EE in the docname. 
https://github.com/mallory/e2ee/commit/a225529fc56da5991994fcf7b2b2f83b0c7b6669

>
> I think section 2.1 has some fluff and could just present a definition.
>
> I find the section 2.2 talk about Salzer very distracting. Why not just
> explain the difference of the E2EE endpoints (user/user agent) versus the
> data communication endpoints (eg the SMTP TLS example given). And maybe
> explain transport security vs data origin security more clearly. Explain
> hop to hop secucity vs message security vs packet security ? (with
> security I also mean confidentiality). The user of [salzer] citations
> feel like we are arguing the definition instead of defining it based
> on regular IETF considerations.
>
There was quite a bit of discussion in the early days of this draft that 
took this section from two paragraphs to its current state. It was 
enlightening to me to realise that a lot of our problems arise from the 
end-point consideration. See client-side scanning proposals on the issue 
of content moderation: https://arxiv.org/abs/2110.07450

> Permission of data manipulation or
>    pseudo-identities for third parties to allow access under the user's
>    identity are against the intention of E2EE.
>
> I don't understand this sentence. It feels like it says pseudo-identities
> are not E2EE features, but they are.
>
Yes, but "pseudo-identities for third parties" is the key phrase. Happy 
to reword if there's a suggestion.
> The use of the word "adversary" in section 2.4 is problematic. Is 
> Apple or
> Signal or Google an "adversary" in their role of application code? The
> whole idea of E2EE to me is that there are roles that claim to have the
> user interest at heart by preventing or limiting or breaker E2EE and
> believe they do so against "adversaries" (CSAM, DNS filtering, web
> proxy filter, anti-virus scanning are examples of roles a user might
> deem "adversarial" and others feel "beneficial".
>
I also am not sure I fully enjoy "adversary" in this document. What do 
others think? It's a useful approach to rigour, but perhaps we could 
keep it in as addenda?

> I find Section 3.1 confusing. It defines E2EE as "end to end 
> encrypted" and
> then talks about "enhancing" e2ee, but then that redefines what is e2ee ?
>
I've made some changes that I hope clarify this:

>     Defining a technology can also be done by inspecting what it does, or
>     is meant to do, in the form of features.  The features of end-to-end
>     encryption from an implementation perspective can be inspected across
>     several important categories: 1) the necessary features of E2EE of
>     authenticity, confidentiality, and integrity, whereas features of 2)
>     availability, deniability, forward secrecy, and post-compromise
>     security are enhancements to E2EE systems.
Further suggestions most welcome, because I agree with you Paul. I also 
think that "content moderation" is not on the list of ideal features and 
so it doesn't get a mention. When folks talk about "improving" e2ee I 
don't want them pointing to CSAM filtering as a valid feature request.

> messages are encrypted by the sender such that
>     only the intended recipient(s) can decrypt them.
>
> I would say "only the recipient(s) shared and agreed by all recipients".
>
> This avoids the case of one recipient having a "backdoor" or "helper" 
> that
> sees cleartext. One infamous example is the Chinese input helper 
> plugin of
> Signal that sends cleartext to third party keyboard services for 
> translating
> input gestures to characters to send.
>
Yes, made that excellent 
change:https://github.com/mallory/e2ee/commit/1dec30d4936e3eaf79d077adb9479ac41f95dd2a 

> Section 3.1.2 Availability the "i.e." sentence confuses the "not 
> online at
> the same time" with "more than one device". 
It's my view that these are two requirements of the same feature.
> It also introduces "if they have
> been offline for a long time" which I think is a different issue from
> "not required to being online at the same time". (eg Wire does
> ratcheting I believe but if i don't talk to someone for months, I might
> lose messages sent to me)
>
Right, this is a third aspect of the same feature.

While they're not easily solved (Wire doesn't quite achieve it, others 
struggle to) the point is that they are The Hard Problems and something 
all e2ee platforms need to consider as improvements to their service 
(not that they already get it 100% correct).

I haven't made changes to this text.

>
>    both for users and implementers (see previous section),
>
> I neither understand "both for users and implementers" or how "(see
> previous section)" applies. How could the users / implementers bit
> be different? What is really meant with "previous section". The two
> subsections above this one? Or section 2? And I feel no section could
> explain the "both for users and implementers".
>
I just removed this sentence it was badly written and when I improved 
it, it was wholly redundant: 
https://github.com/mallory/e2ee/commit/f3ebd959bb0dd508566975e90fab4e8c84f21e2d

>    2) in some way antithetical to the goals of end-to-end encrypted 
> systems.
>
> Could it be useful to list some of these? Eg like the keyboard plugin
> example mentioned above?
>
We really wanted to avoid definition by contrast so I've not made a 
change here.
>    Users of E2EE systems should be able to communicate with any medium
>    of their choice, from text to large files, however there is often a
>    resource problem because there are no open protocols to allow users
>    to securely share the same resource in an end-to-end encrypted
>    system.  Client-side, e.g. end-point, activities like URL unfurling
>    scanning.
>
> I don't understand how the last sentence starting with "Client-side"
> relates to the entire paragraph ("bullet") it appears in ?
>
I think that was an editing note that didn't get erased! Done now: 
https://github.com/mallory/e2ee/commit/4f7170c5236f7858b774987958d94bb0d11ca505
> Section 4.3 talks about third party access. Perhaps it should be extended
> to talk about CSAM type scanning, eg third parties getting 
> fingerprints of
> data to check against a forbidden list of fingerprints. It is also 
> confusing
> how this type of third party access falls with respect to "without 
> formally
> interfering with channel confidentiality". What is formal and what is 
> informal
> interfering ?
>
Again, we really wanted to avoid definition by contrast so I've not made 
a change here.
> Also the "expectation of that security property" is ever changing. 
> Again look
> at the CSAM example. If users of iMessage expect Apple to do CSAM 
> scanning,
> does this now no longer violate the expectation of the security 
> property of
> Confidentiality ? How can we even write down user expectations in this
> document? Do most users actually object to CSAM scanning or DNS
> filtering or virus scanning of content by their other participants? I
> honestly don't know the answer.
>
Exactly why we wanted to write this down! I think in order to avoid 
definition by contrast we cannot talk too much about the nature of what 
users might consider a violation of this expectation. Suggest no change 
here.
> Analyses such as traffic fingerprinting or other (encrypted or
>    unencrypted) data analysis techniques should be considered outside
>    the scope of an E2EE system's goals of providing secure
>    communications to end users.
>
> Why should this be out of scope? What is wrong with designing a padding
> system to obfuscate message size and even adding padding streams that
> make it harder to determine if the users have a real conversation or not?
>
>    Not only should an E2EE system value user data privacy by not
>    enabling pattern inference,
>
> So it is in scope after all ??
>
> Ahh, Section 4.5 does talk about the expectation of not being compromised
> after all. Good. Perhaps this is the place to talk about CSAM ?
>
The only thing I hate more than talking about CSAM is CSAM! But if the 
group insists we do something here, we do something. But small. Please? 
Open to ideas.
>
> COMMENTS:
>
> Section 2.3 just drops:
>
>    The more common end-to-end technique
>    for encrypting uses the double-ratchet algorithm with an
>    authenticated encryption scheme
>
> It feels wrong to drop these terms like double-ratchet without 
> explaining it.
> I find the use of "we" a little odd for an RFC. It sounds like academic
> speak which we tend to not do in RFC documents.
>
It will link to the MLS protocol.
> I really don't like the use of the word succinct throughout the document.
> I think it is not a good word to use within an international context 
> where
> many speakers' first language is not English. (I recognise it might be
> acceptable in academia, but I think this document is supposed to bridge
> academia with software engineers). In Section 2.4, the "succint 
> definition"
> constitutes a large (not succint!) example as definition.
>
Now "concise" throughout!
>    E2EE systems are unique in
>    providing features of confidentiality, integrity and authenticity for
>    users.
>
> The word "unique" is a bit odd. I guess it needs to be read in the 
> context
> of "messaging" but that's not obvious. Instead of sating E2EE systems are
> unique, I would focus on explaining the uniqueness we are talking about
> more clearly. How about:
>
I think there is nothing that provides secrecy and confidentiality like 
encryption.
>    E2EE systems focus on providing a communication system for users that
>    does not depend on trusted third parties for its confidentiality and
>    integrity.
>
> I left out authenticity on purpose, most services do depend on
> authenticity of a (pseudo-)identity, eg jabber name, email, handle, gpg
> id, etc.
>
I'd like to keep in authenticity since we do leverage that concept later 
on and the third-party or user-agent problem is going to become stark.
> or perhaps:
>
>    E2EE systems focus on providing a communication system for users that
>    prevents anyone from eavesdropping on those users' communication.
>
This is definition by contrast so we will avoid that.

I've not made any changes to this piece.

>
>    their right to whisper.
>
> I would not use whisper but state "communicate privately with a guarantee
> that no one can eavesdrop on the conversation". Whisper to me still has
> the connotation that someone nearby could maybe hear the message. I
> think whisper might be a term used elsewhere in academia that I (and
> presumbly other IETFers) are not familiar with.
>
It is used elsewhere but I think it's complimentary to, not intended to 
replace, the IETF community's typical definitions.

Would love others to weigh in on whether we have captured the latter 
precisely.

>    In the tradition of cryptography
>
> I don't understand what the "tradition of cryptography" is ?
>
Now, "field of cryptography".
> Section 3.1.2 introduces the term "participant" while before (end)user
> was used. Is there a difference meant ? Why use this new term now?
>
I will hold on this because it's Chelsea's text that might end up as 
addenda.

>    with a record of the transcript
>
> Should that clarify this is the decrypted message ?
>
Replaced with "anyone able to decrypt a record"
>    As demonstrated by the Signal and OTR protocols
>
> I'm not sure the protocols need to be named/advertised here.
>
Replaced with "widely implemented"
>    and older ones are immediately deleted after used.
>
> I would say:
>
>    and old keys no longer required to encrypt or decrypt any new
>    messages are immediately destroyed.
>
Done.
> I think the "Post-compromise security" is confusing. I think it should
> more clearly say the compromise was found and countered.
> I am also confused how adding new ephemeral keys would help if the
> user's long term identity private key was compromised. And further,
> how does the remote particiant know there might be compromised messages
> in transit? I think I agree with the description of the term, but the
> sentence that starts with "It is usually" is not enough of a description
> of a "fix" for compromised situations.
>
Opened an issue and assigned it to my crypto colleague Sofia :)
>    Also because "the IETF
>    is a place for state-of-the-art producing high quality, relevant
>    technical documents that influence the way people design, use, and
>    manage the Internet" we can be confident that current deployments of
>    end-to-end encrypted technologies in the IETF indicate the cutting
>    edge of their developments
>
> This is a rather circular reasoning. The quotation marks are also 
> confusing
> as it seems to be quoting something, but throwing it at google does 
> not give
> a hint about the source for this statement. It smells very much like 
> "Wij van
> WC Eend, adviseren WC Eend!" (Ask Olaf :)
>
Misquoted the IETF mission-- now fixed.

>    Below is an exhaustive, yet vaguely summarised, list [...]
>
> Is it exhaustive as in "very surely entirely complete", or do you mean it
> is a "tiresome list"? I think neither is what you mean to say :)
> Maybe say "comprehensive" list? Or perhaps more in line with the internet
> spirit, call it a "best effort list" :P
>
Love it-- done.
> It is unclear this paragraph and the following are at a different level,
> eg "part of the list" vs "not part of the list". Why not make a real list
> with nice "o" letter dots, or via subsections if headers would be 
> helpful?
>
Now with bullets!
>
>    and to move the private key to another device
>    compromises the security of one of the end-points of the system.
>
> I do not think this is correct. It might reduce the security to the
> security of the weakest device, but if done properly, it does not
> compromise the security. Eg me adding an ipad to my Apple ID and
> installing Signal does not compromise the security of my Signal client
> on my iphone nor does it compromise the past or future communications
> with other participants. What is this sentence trying to say?
>
The capability of moving the secret key between devices is itself the 
vulnerability. Would appreciate help here in describing the actual risk 
for folks familiar.
> Meta-data is difficult to obfuscate efficiently.
>
> Obfuscating to me is a term for making something just a little harder
> but not really impossible. It is not an asset to an E2EE sysem. I think
> what is meant is more something like "Meta-data needs to be minimized as
> much as possible, but one cannot elliminate all of it".
>
> I also do not understand what the word "efficiently" does here? Why does
> efficiency matter here?
>
Done. Added "eliminate or" just before obfuscate and instead of 
efficiently I use "entirely". I agree with you that obfuscate alone 
isn't enough.
>    but this presents major problems of scale for end-to-end encryption
>
> Why is this a "major problem" but the next bullet "forwards secrecy" is
> only an unquantified "problem" ? I would simply remove "major".
>
Done.
> Usability considerations are sometimes in conflict with security
>    considerations, such as message read status, typing indicators, URL/
>    link previews.
>
> I would definetely add the Chinese virtual keyboard issue in this list as
> it is an example of a real life huge problem created in Signal and 
> ignored
> for years (See Naomi Wu's comments on this)
We haven't added examples to date but we could, for each, if that's 
helpful in a definition document (again noting our need to avoid 
definition by contrast).
>
> I think the 3.2 list of Challenges is missing an important issue; how 
> does
> the user know they can trust the software? Most of these E2EE systems are
> not opensource, or even open protocols. How do these E2EE systems prove
> they are not backdoor'ed or weak. Eg Signal tried to do something like
> run server-side code in a CPU Secure Enclave (Intel SGX) and publish the
> source code for verification (but does not mean it is opensource).
> This is later touched on in Section 4, but why is it not lsited here?
>
I would suggest we expand on it in user expectations rather than hard 
problems. Software is indeed always facing this as a hard problem, but 
if we frame it, rightly as you suggest, as a user verification problem 
then we can get a better understanding, I think.
> And another item misisng on the list is the typical E2EE feature of
> "disappearing images" that completely depend on client-side security
> which cannot exist with opensource E2EE clients.
>
Can you say more about this? I am aware of disappearing messages, which 
should be a feature, but I am unfamiliar with disappearing images.
>
>    Section 4.2 Providers are trustworthy
>
> Do users really expect this? I agree some users do but some users don't.
> And for most users there is a big differene between "at home" or "using
> my telco" versus "coffeeshop" or "hotel" networks.
>
It's not about whether or not they do, it's about the objectives of a 
healthy ecosystem that serves the user. We must assume that the only way 
forward with e2ee messaging that has the best interests of users is one 
in which the user trusts the provider and then define what that looks 
like. Open to changes in the wording to be less controversial.

And to your point about which users to ask, we are keeping in mind users 
who are using these tools for the privacy properties that the tools 
themselves espouse.

> Trustworthy A system is completely trustworthy if and only if it is
>       completely resilient, reliable, accountable, and secure in a way
>       that consistently meets users' expectations.  The opposite of
>       trustworthy is untrustworthy.
>
> This seems like a recursive definition. It also seems to throw in the
> word "completely" to undo whatever definition it is trying to make as
> now we have "Trustworthy" and "completely trustworthy" but only a
> definition of the latter.
>
Happy if folks have come across a better definition in the wild. I'd 
rather not have to write draft-trustworthiness-definition :)
>
> I like the closing definition in Section 4.2 but I felt it disjoined from
> the section title. Perhaps change "the set of functions" to "the provider
> of the set of functions" ?
>
Done.

NITS fixed: 
https://github.com/mallory/e2ee/commit/907c293267ad735c828eb3ba384714faa0902441

Thanks!
-Mallory

>
>
> NITS:
>
> communications systems -> communication systems  ?
>
> direction of travel -> development
>
> it's also -> it is also
>
> succint -> clear ?
>
> we -> this document ?
>
> I cannot parse "with amongst end points."
>
> I personally don't like the work "holistically". Might be a english 
> not my first language thing.
>
> "such as [...] and more"  seems redundant.
>
>       Steps should be taken to
>       minimize metadata leakage such as user obfuscating IP addresses,
>       reducing non-routing metadata, and avoiding extraneous message
>       headers can enhance the confidentiality and security features of
>       E2EE systems.
>
> I would remove the last bit of the sentence starting at "can enhance ..."
> for more consistency (and less redundany) with the other items in the 
> list.
>
>
-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780