[V3] E2E Security and P2P media

Cullen Jennings <fluffy@iii.ca> Tue, 24 March 2020 14:13 UTC

Return-Path: <fluffy@iii.ca>
X-Original-To: v3@ietfa.amsl.com
Delivered-To: v3@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id AA1B73A0BD8 for <v3@ietfa.amsl.com>; Tue, 24 Mar 2020 07:13:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id N8UXsU8sz605 for <v3@ietfa.amsl.com>; Tue, 24 Mar 2020 07:12:53 -0700 (PDT)
Received: from smtp84.ord1d.emailsrvr.com (smtp84.ord1d.emailsrvr.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94D453A096E for <v3@ietf.org>; Tue, 24 Mar 2020 07:12:53 -0700 (PDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp19.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id A5189603F3; Tue, 24 Mar 2020 10:12:51 -0400 (EDT)
X-Sender-Id: fluffy@iii.ca
Received: from [] ([UNAVAILABLE]. []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by (trex/5.7.12); Tue, 24 Mar 2020 10:12:52 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_667CBC2B-630E-4225-B67C-684D853736E4"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <CABcZeBPWEZnRz39NeeMfvgej335t8qFVcWjefqJTt74rHV1ORg@mail.gmail.com>
Date: Tue, 24 Mar 2020 08:12:49 -0600
Cc: Jonathan Rosenberg <jdrosen@jdrosen.net>, v3@ietf.org, IETF QUIC WG <QUIC@ietf.org>
Message-Id: <AB4F26A6-207D-4D51-8179-D1C523B2269F@iii.ca>
References: <CA+23+fHwc9NEpgJCZHdEdpXKrt1nLKufQzPEusz9NiewQOO=bA@mail.gmail.com> <CABcZeBPWEZnRz39NeeMfvgej335t8qFVcWjefqJTt74rHV1ORg@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Classification-ID: 52a457f1-4773-4d2d-a294-5dd0535fecd6-1-1
Archived-At: <https://mailarchive.ietf.org/arch/msg/v3/nESUeXNSEPepzjwRkt3SL5ZDCVU>
Subject: [V3] E2E Security and P2P media
X-BeenThere: v3@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <v3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v3>, <mailto:v3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v3/>
List-Post: <mailto:v3@ietf.org>
List-Help: <mailto:v3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v3>, <mailto:v3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Mar 2020 14:13:15 -0000

> On Feb 22, 2020, at 3:00 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> Your charter specifies e2e security, but AFAICT, this is not
> provided by this specification, nor is it obvious how to enhance
> it to provide it. Indeed, it seems like there's not any support
> for a disjoint media path. You may recall that I made similar
> comments at the DISPATCH session in SIN, and I had understood
> that it was your intention to accommodate these cases, but
> I don't see anything here, which is somewhat disappointing.

This was in some version but accidentally got deleted out in editing but what I think we should do is something along the lines of following:

1.Include End-2-End encryption and authentication of the media packets in the base design. (and there would also still be Hop-bop provided by transport layer) 

2. Design it to work well if you are using MLS keying or something like it but the keying would be out of scope. 

That design would well to do things like cover the PERC WG uses cases. (but i am not advocating a solution like double - just we have one E2E that is keyed by something like MLS and a separate HbH that is keyed by TLS) 

I don’t think we should directly take on P2P media to start with due to the complexity that an ICE like protocol adds. Most the uses cases driving this work fine in the same sort of way that HTTP works without any P2P.  Much of the “P2P” SIP and WeBRTC traffic actually goes via a TURN server or other tunnel and RIPT would support that sort of relay topology as long as we had a E2E crypto. 

I do think it might be possible that we will be able to use WebRTC set up a data channel then run RIPT  over that data channel.