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
---------
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.
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@xxxxxxxxxxxxxx> 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
