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

[Michael Richardson <[e-mail]>]

Mallory Knodel <[e-mail]> wrote:
    > On 5/11/23 2:03 PM, Michael Richardson wrote:
    >> Mallory Knodel <mknodel=[e-mail]> wrote: > 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"?
    >>
    >> I think that this is best answered by asking the "customer": In this
    >> case, it's other IETF (primarily) protocol writers.  (sure, non-IETF
    >> protocol writers will probably reference)
    >>
    >> As a writer, I would like to be able to describe certain aspects of a
    >> protocol as being e2ee.  It might be some parts a protocol are not.
    >>
    >> To this end (pun intended) we might get better traction by coming up
    >> with a taxonomy of ways in which parts of protocol are *not* e2ee
    >> encrypted.

    > If there are things that e2ee are not that aren't covered in this draft
    > in the converse, that would be useful to know.

It's e2ee only when none of converse things are true :-)

When talking about some protocol, we need the terminology of the converse
more than we need a airtight definition of e2ee.  Because the air always gets out.
We need to be able to describe the different holes by which the air leaks.

If you define e2ee as being *human* to *human*, then nothing is e2ee, as
humans just can't do key agreements in our head.
(At least, not yet: and even if we get augmented, those are still agents..
    https://quoteinvestigator.com/2013/01/31/live-fast/
    Live Hard, Die Young, Leave an Augmented Corpse)

We all need a computational agent to work for us.
There are all sorts of agents that can be deployed, and it would e2e between
the agents.  But, then someone else would say, "oh, no, that's not e2e, it's
*converse* term"

    >> One can easily describe many hop-by-hop encryption schemes where they
    >> operate at layer-1, layer-2 [MACSEC, WEP], layer-3 [IPsec, Wireguard],
    >> layer-4 [TLS,DTLS], up to layer-5/6 [smtp, Tor, HTTPS, SIP], layer-7
    >> [SMIME,PGP,MLS].
    >>
    >> It seems that e2ee is a relative term, and it depends a whole bunch of
    >> negatives.  OTH, when describing the properties of a protocol, it
    >> would be easier to just explain where the ends are that can be
    >> attacked.

    > It is an explicit goal that we remove that relativity with this draft.

Then, I think even if you can hold on to that through the review process, it
will become irrelevant ten minutes after the RFC comes out.

    > I think I've understood that the protocols you're primarily involved in
    > are e2e and they use encryption but they are not e2ee messaging, video,
    > audio, email, etc. So in that sense, we are out of your scope and I
    > think that's the main reason why it's not that useful.

No, I totally and completely disagree.
Everything I (and the IETF) did in 1995, in 2000, in 2005, in 2010, they were
all *AT THE TIME* bleeding edge work, and were all considered e2ee *at the time*.
PGP and SMIME are 35 year old e2ee email systems... until they are deployed
differently with the keys stored in someone else's server.

IPsec is e2ee at layer-3.
TLS is e2ee at layer-4/5.

But, neither they, nor SMIME are going to get audio to my BT headset in an
e2e fashion: that hop will be seperately encrypted.
Nor video to my monitor, or my eyes: that will get encrypted across the HDMI cable.
  In fact, that HDMI cable has been secured *AGAINST* us by the movie industry.
  So it's a really treasonous hop!

So, "messaging/video/audio" can never, according to your definition, be
actually e2ee.

OTH, if you were able to define the various "failures" to get to the end:
     1) smartapplication2smartapplication encryption
     2) host2host encryption (with application2application integrity?)
     3) sipserver2sipserver encryption (with host2host encryption of media)

(1) for instance, can be attacked by Google or Apple (or LG or Samsung or
    Huawei or ...) by changing the video and audio drivers.
    Plus, BT attacks if you are using a headset.
    Maybe also attacks via the baseband CPU on the audio channels.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [




--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide