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

From: Alec Muffett <[email-masked]>
Date: Fri, 30 Jul 2021 02:42:53 +0100

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

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 30 Jul 2021 13:02:04 +1000

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.
> 
> 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.
> 
> 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: 
> _______________________________________________
> CFRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Alec Muffett <[email-masked]>
Date: Fri, 30 Jul 2021 04:30:07 +0100

> Hi Alec,

Hey Martin - thank you for your thoughtful and considered response.  I am
about to turn in for the night (4am, ick) but wanted to quickly spin a
couple of comments back to you in case they unblock other questions you
might have.

>  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.
>

I am thinking broadly along the same lines, though I see 1..6 as the most
skippable.  Posting the video beforehand, de-stresses a lot of that concern
for me.

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).
>

I've learned to scope small and then expand: messaging without access to
retrospective history is a moderately well-defined app space.

If I were to exhibit hubris and claim that this test was a fit test for
some, huge broad spectrum of solutions, then I might end up having to
address questions about websites sending javascript to sframes, in the
process grandfathering in a huge space of browser-related behaviours that
may differ wildly from my well-explored, mostly-understood space.  I would
be deeply content to solve the problem that I am equipped to address, and
then let some more energetic bright spark take it forward into other
domains. :-)

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.
>

I prefer to keep slide 38 because it reinforces what IETF said in RFC2804,
viz: that IETF should *not* be saying what happens upon clients.

Quote: "The IETF, an international standards body, believes itself to be
the wrong forum for designing protocol or equipment features that address
needs arising from the laws of individual countries"

For "equipment", I nowadays read "apps on phones".  So, curiously, I
believe that you're agreeing with me?

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.
>

...and that's why I scoped it to E2E-Secure Messenger applications. :-P

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 is well-covered (if slightly dated) in the Clark/Blumenthal paper, but
yes, the TCB is no longer a static beast, it contains dynamic
dependencies on your app-writers, app-stores, device-platforms and whatnot.

Back in the old days, the worst we had to worry about in dynamic
dependencies was DNS Spoofing, ARP-Cache poisoning, and bogus patches,
surely? O tempora…

> 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.
>

Concur.  There's a lot of work TBD, and so far I am doing it solo.

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.
>

I would be delighted.  Talk more in the morning?

 -a

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 30 Jul 2021 17:01:43 -0600

> 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 abo…

It might be prudent for this document to mention less centralized
architectural models (and examples other than Signal, WhatsApp, and the
like). For instance, most modern XMPP clients implement OMEMO [1] for
end-to-end encryption and XMPP-based projects like Snikket [2] are
making it much easier for people to deploy XMPP services under their own
control.

Peter

[1] https://xmpp.org/extensions/xep-0384.html

[2] https://snikket.org/

---

From: Alec Muffett <[email-masked]>
Date: Sat, 31 Jul 2021 01:33:00 +0100

> making it much easier for people to deploy XMPP services under their own

I would love that, yes please; so far I only have Ricochet, Briar and Cwtch
to refer to in the "decentralised" space.

And PGP/Email, kinda.  :-)

Can we organise a group chat offline for anyone who wants to chip in?  Mail
me back directly if interested?

    -a

---

From: Alec Muffett <[email-masked]>
Date: Sat, 31 Jul 2021 01:46:35 +0100

Hi All!

Thank you for a great first CFRG experience.

One key comment/thread from the chat, which I just wanted to repeat here in
order to avoid confusion:

> Chris Lemmons: Yeah, we should avoid producing two different definitions
of e2ee.
> Alec Muffett: @Chris: for absolute clarity: I am NOT providing a
definition of E2EE. I am providing a test, possibly one of many, which
would invalidate claims of E2EE.
> Chris Lemmons: Alec: That's a good point. I had missed that. It's
important, though.

The first cut of this I-D was posted with an ill-advised, misconceived
name, referring to it as a definition.  That was foolish of me.

The process of developing this deck for presentation at CFRG has taught me
a huge amount* regarding how to think about and describe what this test is
offering - and it is not offering a definition.

The I-D provides one (single) mechanism to falsify claims of "end-to-end
security" (or: "end-to-end encryption?") being provided by a given solution.

There may be other mechanisms invented, and I would welcome them, and
welcome other research in this space.

Nonetheless: this test and this I-D do not live in the space of
definitions; they propose metrics of behaviour, and divide that behaviour
as being compliant with E2E, or not (i.e. "backdoor")

    -a

*learnings which I will clearly need to roll into the I-D.