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

[Mallory Knodel <[e-mail]>]

Hi,

On 5/11/23 8:43 PM, Michael Richardson wrote:
> 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.

Rather if 10 minutes after the RFC comes out there is a new thing that 
hits user devices or a new change to an e2ee service, the definition 
document can be useful to people to determine whether t his is e2ee 
based on its properties. Elided support for PFS? Well, this doc says 
your service is not trustworthy e2ee.

It answers, no matter what the future holds, what are the fundamental 
constituent pieces of e2ee?

>      > 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.
It's not about bleeding edge work. It's about the end points, and in 
this document we are concerned with people who have agents that use keys 
to authenticate and encrypt their communications. IPsec and TLS are out 
of scope.
> 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.

We're worried about compromise at scale on the network, so this is also 
out of scope.

-Mallory

-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780