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

[Mallory Knodel <[e-mail]>]

Hi Eric,

On 5/12/23 10:28 AM, Eric Rescorla wrote:
>
> I think the analysis needs to start with the purpose of this
> document. Is it intended to assist the IETF in designing protocol
> specifications? If so, how?  If intended for some other audience, then
> who? Once there is agreement on that question, then we can discuss the
> shape of the document.
>
The purpose is to define e2ee and as multiple people have said on this 
list, there is not agreement. It's to make clear what we mean when we 
talk about e2ee.

Are you suggesting that the analysis go into the document text? Or that 
we have a group discussion here about why we wrote it? Or that we have a 
group discussion about something else?

> In terms of process, I think it should be clear at this point that
> this document is unsuitable for AD sponsorship. That really only works
> for documents which are largely finished, which is not the case
> here. If this document is to proceed, it really needs to be in a WG.
> This suggests that the next step is SECDISPATCH to determine whether
> or not the IETF wants to work on this problem.
>
On the contrary, the authors have been able to make relevant changes to 
the text based on feedback in this process so far. We see a way forward 
with all of the feedback and we'll have a new version out soon.

Most recently I've asked about the systems question because that, too, 
is pretty straightforward to change. Welcome your thoughts on that since 
you raised them.

Thanks,

-Mallory


>
>
>
> On Fri, May 12, 2023 at 12:40 AM Eliot Lear <[e-mail]> wrote:
>
>     Hi Mallory,
>
>     I would recommend starting by *concisely* defining the term,
>     elaborating the properties, why they are important, and how
>     protocol designers can help.  It's clear that there is not even
>     agreement on what e2ee should mean, and it's not yet even clear
>     that the term is the right one to use.  Get consensus on all of
>     this, and it seems to me that you've done a good day's work.
>
>     Systems aspects can be introduced, but only to support the above. 
>     Introducing them in the definition or the properties is, I think,
>     counterproductive.
>
>     Eliot
>
>     On 11.05.23 13:37, Mallory Knodel wrote:
>>
>>     Hi all,
>>
>>     On the larger question of system versus protocol in this
>>     document, the following top post:
>>
>>     I think we can resolve this in a few ways.
>>
>>     1) we keep the text as describing systems and achieve some high
>>     level of guidance that impacts closer to users
>>
>>     2) we revise the text to remove the systems framing, but
>>     sacrifice some of what we wanted to achieve in terms of
>>     addressing ambiguity in tradeoffs for implementers
>>
>>     3) we do a reorg of the text around (2) but add the systems
>>     considerations as a separate section.
>>
>>     Because it was a deep discussion and intentional choice early on
>>     in the drafting, I think the authors and I are still partial to
>>     (1) and I would be happy to explain more about why. But I wanted
>>     to offer these (only, as I see it) options as a way forward in
>>     the hope of gathering feedback from folks about what would truly
>>     best reflect an IETF-consensus document on the question "what is
>>     e2ee"?
>>
>>     Mille thanks,
>>
>>     -Mallory
>>
>>     On 4/23/23 7:02 PM, Eric Rescorla wrote:
>>>     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
>>>
>>>
>>>     _______________________________________________
>>>     saag mailing list
>>>     [e-mail]
>>>     https://www.ietf.org/mailman/listinfo/saag
>>     -- 
>>     Mallory Knodel
>>     CTO, Center for Democracy and Technology
>>     gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780
>>
>>     _______________________________________________
>>     saag mailing list
>>     [e-mail]
>>     https://www.ietf.org/mailman/listinfo/saag
>     _______________________________________________
>     saag mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/saag
>
-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780