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

[Alec Muffett <[e-mail]>]

On Fri, 30 Jul 2021 at 04:02, Martin Thomson <[e-mail]> wrote:

> 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

-- 
https://alecmuffett.com/about