Re: [saag] reviews needed of draft-knodel-e2ee-definition

Document: draft-knodel-e2ee-definition-07.txt

I too have concerns about this draft as-is. I reviewed a previous
version of this document (-02) and I see that a number of my comments
[0] still apply, but in this message I want to talk about the bigger
picture, specifically what function we expect this document to
serve in the IETF.

The basic mismatch I see in that respect is that the IETF designs
protocols and this document focuses on systems. For instance, consider
three instant messaging systems:

- In System 1, all messages are TLS-encrypted between clients and
  the server but in the clear on the server.

- In System 2, everyone has an app that they use for messaging and data
   is encrypted all the way to the app using MLS.

- System 3, is much like System 1 except that someone has built
  a client which runs on the server and which exposes a Web
  interface.

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

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.

I think this document would be a lot more useful if it focused on
protocol functionality and the system architectures it enables; the
result would be something much shorter and more targeted, but would
be more applicable to the work of the IETF.

-Ekr

[0]
https://mailarchive.ietf.org/arch/msg/secdispatch/BwmdjEnXlAjd8u4DWQgeSOKr6rA/
[1] There are, of course, settings in which TLS is used end-to-end,
    but that's a separate topic.

On Thu, Sep 29, 2022 at 4:23 AM Eliot Lear <lear@lear.ch> wrote:

> I have to agree with Hannes, and would go further.  The document as it is
> should not be published, and needs some refocusing.
>
> The problems begin in the abstract where it is not made clear what the
> reader will learn.  They continue into the introduction where the
> motivations for the work are not stated.
>
> There are already far more concise definitions of end-to-end encryption.
> The definition isn't the problem.  Attaining end-to-end encryption and
> understanding the tradeoffs and implications is at least one problem.  That
> is, intersecting Section 3.2 and 4 could make for a good piece of work.
> Also, stuffing a definition of end-to-end security in the middle of the
> document is asking for trouble.
>
> I could see value in exploring the relationship between the end-to-end
> principle and end-to-end encryption, but that to me strikes me as an
> academic exercise.  If that's what the authors want to do, great.  There
> are portions of RFC 3742 that could be addressed.  Absent that, huge
> swathes of Section 2 should shrink, and that which remains needs to be far
> better supported, and must support the thesis of the work.
>
> I could see value in exploring end-to-end encryption in the context of RFC
> 8890.  But that doesn't always mean that the user is quite so visible.
> Think about that water coming out of your tap and the control systems
> involved.
>
> Anyway, to quote Yogi Berra, when you come to a fork in the road, take
> it.  Here we are.
>
> Eliot
>
>
> On 29.09.22 10:13, Hannes Tschofenig wrote:
>
> I have read through the document. I am curious to what event has triggered
> the authors to work on it.
>
>
>
> I have been asking myself several times in the document “Why are they
> writing about this issue?”
>
>
>
> Ciao
> Hannes
>
>
>
> *From:* saag <saag-bounces@ietf.org> <saag-bounces@ietf.org> *On Behalf
> Of * Paul Wouters
> *Sent:* Wednesday, September 28, 2022 11:49 PM
> *To:* IETF SAAG <saag@ietf.org> <saag@ietf.org>;
> draft-knodel-e2ee-definition.authors@ietf.org
> *Subject:* [saag] reviews needed of draft-knodel-e2ee-definition
>
>
>
> Hi,
>
>
>
> A few people have been working on a document to define what it means to be
> end-to-end encrypted, and wrote this up in a draft.
>
>
>
> https://datatracker.ietf.org/doc/html/draft-knodel-e2ee-definition-07
>
>
>
> I believe this work small and self-contained and would be beneficial to
> the community. Please provide feedback to the list and authors. Even if you
> just agree with publication, please let the list (or me) know so that we
> can gather some insights on the community consensus on this draft.
>
>
>
> Authors: if you can, please respond to this message with any IPR claims or
> lack there of for the public record.
>
>
>
> Paul
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> _______________________________________________
> saag mailing listsaag@ietf.orghttps://www.ietf.org/mailman/listinfo/saag
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>