Re: [saag] Scope of draft-knodel-e2ee-definition

[Mallory Knodel <[e-mail]>]

On 4/24/23 10:29 PM, Black, David wrote:

> Picking up on a response to EKR that it looks like he didn’t follow up on:
>
> >> 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?
>
> The draft generally assumes that “users” are accessing “messages” that 
> are transmitted via the protocol, which is a scope-limiting assumption.
>
Yes-- messages + video + audio + media + email.

-M



> A more specific concern is that the Availability, Deniability and 
> Disappearing messages paragraphs in 3.1.2 effectively limit the scope 
> of this draft to a space that includes instant messaging applications 
> and the like:
>
>   * The Availability paragraph is problematic for most infrastructure
>     protocols, including “file exchange protocols” and infrastructure
>     management protocols, because it doesn’t seriously address
>     Availability of the communication service involved.  If I want to
>     exchange (transfer) a file, I care about availability of the
>     service that performs that transfer, not just the end-system
>     availability of the file after the transfer.
>   * The Deniability paragraph is wrong for a plethora of protocols,
>     starting with S/MIME for email and certificate-authenticated TLS,
>     both of which have non-repudiation properties.  It’s likewise
>     wrong for end-to-end encryption of stored data.  As I’ve pointed
>     out previously, there are many protocols for which
>     Non-Repudiation, the opposite of Deniability, is wanted.
>   * The Disappearing messages paragraph is wrong for protocols that
>     don’t use messages and don’t want data to disappear – the latter
>     is true of most storage protocols, including “file exchange
>     protocols.”
>
> Mallory’s prior suggestion that this draft is about protocols that 
> transfer “content” may be a step in the right direction.  Another 
> suggestion would be to describe the space of protocols for which the 
> Availability, Deniability and Disappearing messages paragraphs are 
> correct, focusing on protocols with “users” who want to communicate 
> “messages” …
>
> Thanks, --David
>
>
> _______________________________________________
> 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