Re: [Last-Call] Last Call: <draft-knodel-e2ee-definition-07.txt> (Definition of End-to-end Encryption) to Informational RFC

I too am surprised to see this draft being brought forth. As Rich
indicates, there were a number
of critical comments raised in SAAG [0], and the draft has not been updated
to address those comments. I trust that those will be taken into
consideration as part
of the consensus determination without the authors having to re-send them.

I have attached my review (previously sent to SAAG) below.

-Ekr

[0] https://mailarchive.ietf.org/arch/msg/saag/EC9FvWH_PNqBMQBPp5cccqOzcRk/

---------
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
actually apply to something we could reason about in the IETF context.

-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 Mon, Oct 10, 2022 at 7:01 PM Salz, Rich <rsalz=
40akamai.com@dmarc.ietf.org> wrote:

> I am strongly opposed to this document being published in the IETF stream.
>
>
> In response to Paul bringing the draft up, there were several major
> concerns raised. There was no feedback from the author, let alone no new
> draft that addressed any of the issues.  There is also no explanation why
> Paul brought it up, although there was the implication that it was being
> considered as AD-sponsored. Is that correct? If so, why is it now being
> considered as an inidividual submission?
>
>
> Why isn't this being sent to the ISE?
>
>
> --
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call
>