Fwd: Confidentiality for data channels

Someone suggested that I forward this here; though most folks here are
over there already :)

I'm not suggesting any change to the current API surface for this; if
we decide to do some more confidentiality features, I would propose
that we do those as API add-ons and not concern ourselves with
designing any affordances right now.


---------- Forwarded message ----------
From: Martin Thomson <martin.thomson@gmail.com>
Date: 24 July 2014 11:47
Subject: Confidentiality for data channels
To: "rtcweb@ietf.org" <rtcweb@ietf.org>


One issue that I neglected to mention yesterday in the ALPN discussion is this:

What do we do with data channels?

After discussions with Michael Procter, I have reached something of a
conclusion on the subject and wanted to share and get more feedback.

There are two approaches that immediately spring to mind:

1. forbid the use of data channels (at least in their present form)
when the RTCPeerConnection is in a confidential mode

2. permit the use of data channels and note that their contents are
not, and cannot ever be, confidential, since they innately require
that applications create and consume their contents

I think that the latter option is closer to reality, though it makes
me a little sad about the potential to do things like confidential
file sharing or confidential text chat, even if we have no current
desire to provide these features (and the necessary widgets) in
browsers.

So I think that we have a third option (which I now believe was
previously mentioned by someone else in the past), which is to allow
for the creation of this feature in the future.  This is option 2, but
we note that maybe something else can be built later if we want this
feature.  That something else could be a new SCTP PPID that marks
confidential data separate to the current set of two (and maybe 3 or
4) PPIDs that are not confidential.

Received on Thursday, 24 July 2014 18:55:29 UTC