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

[Paul Wouters <[e-mail]>]

[still speaking as an individual only]


On Fri, Apr 21, 2023 at 5:43 PM Eric Rescorla <[e-mail]> wrote:

> Document: draft-knodel-e2ee-definition-10.txt
>
> ----
> The basic mismatch I see in that respect is that the IETF designs
> protocols and this document focuses on systems.
>

I don't agree with that assessment. Section 3 is all about protocol
properties. Yes protocol properties sometimes are the same or translate
into system properties too. Section 4 is about user expectation, which
again is the expectation the user has backed by how the protocols runs
on the system. If you look at discussion around
draft-thomson-tls-keylogfile we are also very concerned on how the system
will make use of
this protocol/standard.

Based on the text in Section 2.4 and 3.1.1, 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.
>

The IETF does describe how to safely use protocols on systems. I don't see
that as an issue myself that this is done here as well.


> 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.
>

There are RFCs that explicitly talk about expectations on how to use
protocols or protocol elements. Think of RFC 1984 and RFC 7258. Describing
the enduser expectations of a system is something that can be in scope in
my view.

----
>
> I would make two more points:
>
> The text here seems extremely focused on Instant Messaging-type
> applications and doesn't fit well with other protocols, even when they
> provide end-to-end encryption. Either it should be scoped down to
> Messaging or it should be adjusted to be more broadly applicable.
>

What other protocols does it not fit with? Wouldn't the same apply to
video conferencing, audio streams, file exchange protocols, etc? Do
you have an example of a protocol that falls outside the scope of
this document?


> It seems that the wide view that this document takes really interferes
> with any plausible analysis of whether a given system is E2EE. To take
> a concrete example, imagine a messenger systems of type (2) above,
> which, I think this document would think was E2EE. Now imagine it's
> installed on a computer with extensive monitoring software which can
> introspect into the memory of the client. As I understand S 4.4 and
> 4.6, this document would say that that system no longer provided E2EE.
> That seems very unhelpful for the purpose of protocol or even systems
> design, in that a system that provides E2EE can no longer provide it
> for reasons totally out of control of the system designers.
>

I don't see the problem with describing this? Sure, we don't write in the
NFS
protocol that a compromised endpoint leads to a failure of encrypted
network traffic,
but we also don't tend to have MITM attacks against NFSv4 (or parental
control, or
anti-spam filtering, etc). I think it is the protocol context here of
endusers' communication
that brings this aspect more into scope for this specific class of
protocols.

I don't think Informational drafts should be using 2119 language
> like this.
>

That's a fair point. I agree that should be changed as well.


> S 2.2
> I don't think the attempt to derive the definition of E2EE from
> the end-to-end principle gets us very far. It's fine as a sort
> of motivational concept, I suppose, but the problem here is you
> are trying to define E2EE whereas the E2E principle kind of assumes
> that the ends are well-known.
>

I don't understand the point you are trying to make here? Can you try and
rephrase this?


>    The principle has evolved to an understanding that the "network's job
>    is to transmit datagrams as efficiently and flexibly as possible",
>    and the rest should be done at the ends.  [RFC1958] This principle
>    can also be extended to the design of applications itself.
>    [saltzer][RFC3724][RFC3238]
>
> This text is especially problematic because every real E2EE messaging
> system I know does a huge amount of stuff in servers. Indeed,
> what's common is to end-to-end encrypt data precisely to separate
> it from the stuff the server operates on.
>

I think the original text is talking about content, whereas you are
referring more
to metadata?

S 2.3.
> This whole second paragraph seems kind of irrelevant to producing a
> definition. While I disagree with MSJ about the role of authentication
> in such a definition, I think his text is otherwise much crisper.
>

I'll leave it to the authors to integrate/replace based on the list
feedback.


> S 2.4.
> This section is very confusing because it glues together the concepts
> of protocol (in scope for IETF) with application (largely out of scope
> for IETF). See my comments above.
>

I think the "glueing together" is exactly the important thing. Outside the
IETF, there
are those that conflate everything into protocol properties and pretend
required
features can always be part of the protocol (eg "exceptional access").
Therefor the
document cannot escape talking about protocol vs systems. It is exactly to
clarify
the parts the IETF can and cannot work on because it is or is not at the
protocol level.



>
>
> S 3.1.1.
>    Confidentiality  A system provides message confidentiality if only
>       the sender and intended recipient(s) can read the message
>       plaintext, i.e. messages sent between participants can only be
>       read by the agreed upon participants in the group and all
>       participants share the identical group member list.
>
> So if we are in a conversation protected with MLS, and I forward
> a message to someone not in the group, then it's not E2EE? That
> seems pretty obviously wrong.
>

That would be taking the message outside the system. It is not different
from
you reading the message out loud over the PA system. This reasoning is a bit
far fetched. It's like me saying firefox doesn't support private browsing
because I can
take a photo or screenshot of the browser (even over your shoulder)

   Integrity  A system provides message integrity when it guarantees
>       that messages have not been modified in transit.  If a message has
>       been modified, it must be detected in a reliable way by the
>       recipient.
>
>    Authentication  A system provides authentication if the recipient and
>       sender attest to each other's identities in relation to the
>       contents of their communications.
>
> What does "attest" mean?
>

That both parties agree on what they deem trustworthy as a way to
accept/confirm each other's identity. Which
could be an openpgp key to a nickname or a government issued passport
deemed fraud resistant. I assume the
word "attest" is used exactly to leave the mutually acceptable methods out
of scope.


> S 3.1.2.
>    Availability  A system provides high availability if the user is able
>       to access the contents of the message (decrypt them) when they so
>       desire and potentially from more than one device.  For example, a
>       message can arrive to a recipient even after they have been
>       offline for a long time.  Note that applications that use this
>       feature often implement a threshold for this property: number or
>       aggregate size of messages; or messages from a month ago can be
>       read by a user that has been offline, but not messages from a year
>       ago.
>
>    Loss Resilience  If a message is permanently lost by the network,
>       sender(s) and/or recipient(s) should still be able to communicate.
>
> These are odd definitions and seem to be really tied to Instant Messaging.
> In particular, I would usually expect availability to be tied to service
> operational guarantees as much as protocols. How would you apply thes
> to (say) QUIC, where the considerations are totally different.
>

As you described above yourself, a transport layer security protocol is not
a full e2ee protocol.


>
>    Forward secrecy  Forward secrecy is a security property that prevents
>       attackers from decrypting encrypted data they have previously
>       captured over a communication channel before the time of
>       compromise, if the attacker compromises one of the endpoints.
>       Forward secrecy is usually achieved by regularly deriving new
>       encryption/decryption keys, and destroying old keys that are no
>       longer required to encrypt or decrypt messages.
>
> I agree with John Mattson that while this may not be formally part of
> a definition of E2EE, it's clearly a best practice for encryption,
> so framing it as optional is problematic.
>

Agreed.


>
>    Post-compromise security  Post-compromise security is a security
>       property that seeks to guarantee future confidentiality and
>       integrity in the face of a passive end-point compromise (and
>       consequently that communication sent post-compromise is protected
>       with the same security properties that existed before the
>       compromise).  It is usually achieved by adding new ephemeral key
>       exchanges (new randomness) to the derivation of encryption/
>       decryption keys every 'x' amount of time or after 'n' messages
>       sent.  Note that post-compromise security is not met in the face
>       of active attackers that compromise an end-point.
>
> This doesn't seem strictly right. For instance, if I compromise an
> endpoint and steal its keys but don't do a Key Update and then lose
> access, then when that endpoint updates its keys, I will lose access,
> no?
>

Right, but do you envision systems where an attacker only managed to steal
session keys,
but not the long term identity keys? These days that is very unlikely to be
the case, but I
do hope that in the future that would be more common (eg store long term
identity private
keys in hardware with no export capability)

The text could be tweaked a bit to take these considerations into account.


>    Metadata obfuscation  Digital communication inevitably generates data
>       other than the content of the communication itself, such as IP
>       addresses, group memberships, and date and time of messages.  To
>       enhance the privacy and security of end-to-end encryption, steps
>       should be taken to minimize metadata.  Additional steps should be
>       taken to prevent leakage such as hiding users' IP addresses,
>       reducing non-routing metadata, and avoiding extraneous message
>       headers.
>
> This also seems like a very messaging-focused definition. For instance,
> it's not meaningful for QUIC to conceal IP addresses.
>

See my comment above. I think of QUIC as a transport security mechanism
only. If you mean
a system based on mutually authenticated TLS with webpki based certificates
using QUIC, I
would probably agree with the current draft that such a system would not
meet the minimum requirements
of an e2ee protocol/system (because many CAs could forge new enduser
identities)

   Disappearing messages  For confidential conversations, deleting one-
>       by-one sensitive messages typically depends on a level of client-
>       side security that is unsustainable.  For example, endusers can
>       still copy text or screenshot images outside the secured client
>       application.  A certain level of trust among users of the system
>       is required.  That said, features like "delete for me", "delete
>       for everyone" or "disppearing messages" which is time based
>       automated deletion of content do still provide a valuable defense
>       amongst trusted parties in the event of a compromise of a device
>       of one of the participants.
>
> This doesn't seem like a property of the encryption at all. It's solely
> an application feature. I think it's also important to note that
> this is not really consistent with open protocols and implementations.
>

I commented on that similarly as well and suggested the quoted text above
to make that
point as well. The text does state now that it is limited to "trusted
users" (aka the assumption
people don't lie and skip deleting messages), and in the context of
complying users, it still adds
a level of security (eg i voluntarily delete old stuff, so if I am forced
to unlock my phone at the airport,
most content will no longer be on my phone). I think the above text does
capture that properly.

S 3.2.
>    Below is a best effort list of the challenges currently faced by
>    protocol designers of end-to-end encrypted systems.  Problems that
>    fall outside of this list are likely 1) unnecessary feature requests
>    that negligibly, or do nothing to, achieve the aims of end-to-end
>    encrypted systems, or are 2) in some way antithetical to the goals of
>    end-to-end encrypted systems.
>
> This seems like a very strong statement. As a concrete example, having
> large scale e2ee video has a number of problems in terms of working
> out what should be encrypted, what the functions of the SFU are, etc.
> I don't think these fall into either (1) or (2). I would just remove
> this claim.
>

Fair. I'll leave that up to the authors to handle.


>
> S 4.
> I would make two broad points:
>
> 1. This whole section seems to really embody the conflation of
> systems and protocols.
>

We discussed that earlier in this message already.


> 2. I think the assertions about user expectations here are very
> strong. It's not clear to me these in fact are what users
> expect (I have noted some such cases below). So I think this
> needs to be rewritten.
>
>
>
   People have the right to data privacy as defined in international
>    human rights law, and within the right to free expression and to hold
>    opinions is inferred the right to whisper, whether or not they are
>    using digital communications or walking through a field.
>
> I don't think that trying to root this in human rights law is helpful.
> That's not where people's expectations derive from.
>

I do think human rights are those rights that people expect to have.


> And the IETF
> certainly shouldn't be making normative statements here about whether
> people have a "right to whisper" whatever that means.
>

I don't see why not to elaborate on the users' expectation being grounded
in some
pretty universal concepts but I personally have no strong feelings about
including the
sentence or leaving it out.


>
>
> S 4.2.
> Like John Mattson, I find this sxn very confusing. Users may in fact
> think that the provider is trustworthy, but the whole point of
> E2EE is to provide security even in the face of a largely untrustworthy
> provider.
>

Agreed, it should be fixed.



>
>
> S 4.3, 4.4.
> It's not clear to me that either of these match user expectations.
> In particular, user's experience is that client software is wildly
> insecure, and many users have the experience of having monitoring
> software on their machines. I'm certainly not saying that either
> of these situations is desirable, but they are common, even in
> settings where people run messaging systems which in other environments
> would provide E2EE security by the definition here.
>

I think there is an issue on the interpretation of "expected" here. While I
"expect"
security, I also expect "total failure of security". I expect firefox to be
a secure
browser but I'm expecting to see CVEs in the future too.

Paul