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

[Eric Rescorla <[e-mail]>]

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

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

And if this document only consisted of Section 3, the
conversation would be different. But that's not the case.


> Section 4 is about user
> expectation, which again is the expectation the user has backed by how
> the protocols runs on the system.

The issue here is that many of these properties are properties
of the system architecture, and not of the protocols that the
IETF is building, which can be used either in modes which
provide end-to-end security and in modes which do not, and
often in contexts where it's not possible for one endpoint
to determine which is which.


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

Here and below where you cite 1984 and 7258, you seem to making some
process point about what is potentially in scope for IETF. But that's
not what I'm addressing here. Stipulating for the moment that this is
in scope for IETF, and putting aside the important differences between
1984 and 7258, which (1) were *policy* statements about the IETF's
practices, which this is not and (2) were developed by the leadership,
not AD sponsored, my point is that this document isn't particularly
helpful in the task of the IETF which is primarily to design technical
specifications for protocols.

The reason for this is as I indicated in the following passage from
my review:

     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.

To attempt to sharpen this point: many of the protocols that we are
designing here can be used *either* in modes which provide what this
document describes as E2EE or in modes where they do not. For example,
S/MIME can provde E2EE but if it's terminated at a Webmail server, it
most likely does not do so. However, this is an invisible difference
to the peer. There are numerous other examples, such as devices
which have monitoring systems on them.

Much more useful is to think about protocols and protocol architectures
which are *compatible* with end-to-end encryption and those which are
not. For instance STARTTLS is not, and S/MIME is. That is actually
a useful guide to protocol design and analysis. However, trying to
define E2EE in a way that includes these exogenous factors is not,
because it elides that protocol level difference.


> > 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 understand what point you are trying to make here.



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

I don't think that it's productive to try to treat the end-to-end
argument as some kind of axiom that we derive the idea of
E2EE from.


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

I think you're overreading that text. Here is the entire sxn:

   The end-to-end principle is a core architectural guideline of the
   Internet.  [RFC3724]

   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]

Which part of this do you think confines the discussion to content?


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

I'm just reading the literal text here, which says:

   if only the sender and intended recipient(s) can read the message
   plaintext

Of course, this is a trivial observation but it's precisely this
kind of trivial observation/attack that makes writing exact
definitions so difficult (incidentally, this is a common problem
in formal protocol modelling). If this document is to claim
to provide a definition, then it needs to actually be exact
and take into account this kind of thing (this is part of why
I am advocating not doing so!).


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

Well, attest usually has some indication that one claims something,
to another party, so I would choose a different word.


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

This isn't my position at all. A transport-layer security protocol
can be a full e2ee protocol in some contexts (e.g., DTLS-SRTP
when the endpoints are full clients talking directly to each other)
and not in other circumstances (e.g., DTLS-SRTP when the endpoints
are talking to an MTU).

>

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

It's in fact possible to provide PCS in these circumstances, though
we'd have to get into some detail on whether MLS (for instance)
does so.


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

Putting aside the transport versus message question, which I addressed
above, this seems like a very surprising statement. Is your claim,
then, that S/MIME does not provide E2EE (ignoring the WebMail case)
because there are multiple cert providers? What system do you believe
currently provides E2EE?




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

As I said, I think that this should make clear that in open systems
this is just a hope-based feature.


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

Really? What fraction of messaging users do you think even know
what the UDHR is?


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

In that case, a better word than "expect" seems like it
would be helpful.

-Ekr

On Sat, Apr 22, 2023 at 9:19 AM Paul Wouters <[e-mail]> wrote:

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