Re: [CFRG] A Duck Test for End-to-End Secure Messaging: "Video Deck" on YouTube

Hi Alec,

Thanks for putting this together.  It's an excellent presentation.  (Though I do encourage you to try to avoid playing a video if you can manage to be available for the meeting.)

When I first saw your slides, I was concerned about the large number of them, but your video laid those concerns largely to rest.  Perhaps in the interest of brevity and conciseness, you could skip the Nit (1-8) slides and just reserve them as backup material in case of questions.  That seems to be about half of your talking time in the video and would let us focus on your key point.

I do think that this is the right test.  It's clear and understandable and captures what I think is the essence of the problem -- at the right level.  Mostly...

Three high-level points that I think we need to have clear answers to:

1. Your restriction of this to messaging only is, I think, the only thing I truly disagree with in terms of high level goals.  I believe that this test applies equally well to all forms of communication.  Messaging is a very important use case, but I don't see how this test would not apply to anything the IETF produces (RFCs 1984, 2804, 3552, 7258, and more being all consistent with the concept as you define it).

2. I like that this doesn't try to mandate policy either.  It should not.  It doesn't attempt to say that the IETF needs to produce e2e protected protocols.  That's why I think we should avoid talking about what happens on the endpoints in this work.  I think that it would be a bad idea to enter that space.  In your presentation, Slide 38 in particular steps over that line and I would skip straight to 39.

3. The hard one.  This test depends on some very key assumptions about the nature of the endpoint TCB.  Let me give you an example: there are claims that sframe produces e2e protection (see the working group of the same name for reference).  In that design, web sites send javascript to endpoints that is executed by a browser.  The javascript, not the browser, is responsible for encryption, decryption, and key management.  If we consider the javascript as part of the TCB, then your definition applies; if we do not, then it all breaks down.

This last item highlights a general problem: in many messaging systems, the software that provides protection, the servers, the key management, the authentication systems, and even the protocols involved are all under the control of the same entity.  That entity is generally not included in the set of intended recipients, but they clearly have the power to access the content of messages, should they modify the necessary components.

You do address this in the sense that you assume the RFC 3552 condition that the endpoint is not compromised.  I think it is worth recognizing that e2e protections like this are often voluntary on the part of system designers.  When they are voluntary, there are still benefits, but not necessarily guarantees.  Often this also relies on operational security practices to provide real outcomes, like ensuring that the team that looks after the servers that forward messages do not have the means to push client updates or to make changes to authentication servers.  

This was not historically as much of an issue if you assume standardized protocols and independent client implementation, but it is a real concern here.  Either way, making a better distinction about what the TCB is can be critical to understanding where the lines are.   As I hinted at, the TCB also extends beyond the client as it often includes external dependencies for things like trust anchors.  That too will need to be acknowledged and handled carefully.

(To answer my own question from before, I tend to think that sframe as described above does not fit the definition on these terms, but it could with some minor adjustments. To be clear, we're working on those too.)

I have some concerns about the document as it is.  I think we should concentrate on these high-level topics first.  I'd be happy to contribute to work in this area.

Thanks again,
Martin

On Fri, Jul 30, 2021, at 11:42, Alec Muffett wrote:
> Hi All,
> 
> I will be presenting "draft-muffett-end-to-end-secure-messaging" 
> tomorrow at the CFRG meeting*, but my slide deck is packed, it will be 
> late in the evening in the UK, I'm sleep-deprived from a new baby, and 
> my experience of Meetecho so far has involved rather a lot of lag.
> 
> So I thought I would put in some effort up-front and entirely spoiler 
> myself. Attached is a YouTube video with my entire slide deck for 
> tomorrow, and voiceover, running for 9:42s, so at least in theory it is 
> possible for me to run to time.
> 
> https://www.youtube.com/watch?v=QmL9HYywrHg
> 
> I am sharing the video openly, and depending on "tech" I may try 
> showing it tomorrow, reusing the audio, or else I may attempt to "wing 
> it" and repeat it verbatim, live; but if you're enthusiastic about the 
> draft, you're hereby invited to prep your slings and arrows by watching 
> the video beforehand.
> 
> Datatracker: 
> https://datatracker.ietf.org/doc/draft-muffett-end-to-end-secure-messaging/
> Github: 
> https://github.com/alecmuffett/draft-muffett-end-to-end-secure-messaging/
> 
> Best wishes, and I welcome your feedback.
> 
>     - alec
> 
> * https://datatracker.ietf.org/meeting/111/materials/agenda-111-cfrg-04
> 
> --
> https://alecmuffett.com/about
> 
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
> 