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

[Mallory Knodel <[e-mail]>]

Hi Eliot,

On 5/12/23 3:39 AM, Eliot Lear wrote:
>
> 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.
>
On the question of systems, of the options below it sounds like (3) 
would be your preference.

-Mallory

> 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

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