Subject: [Perc] PERC and DataChannels

From: Adam Roach <[email-masked]>
Date: Mon, 2 May 2016 15:01:45 -0500

One of the things that came up on the call last week was what to do with 
DTLS data received at the KMS; this would include WebRTC datachannels.

After considering this quite a bit (and discussing it with Cullen on 
Friday), I'm pretty certain that the answer, from a PERC perspective, is 
that we don't want to specify setting up any kind of data communications 
along that path. So, for example, an attempt to negotiate a datachannel 
in a webrtc context would fail.

If anyone thinks this is going in the wrong direction, please speak up.

/a

---

From: Martin Thomson <[email-masked]>
Date: Tue, 3 May 2016 10:43:12 +1000

On 3 May 2016 at 06:01, Adam Roach <[email-masked]> wrote:
> along that path. So, for example, an attempt to negotiate a datachannel in a
> webrtc context would fail.

Would this be an outright prohibition (MUST NOT) or just a "don't do
that, it doesn't make sense"?

---

From: Christian Groves <[email-masked]>
Date: Tue, 3 May 2016 15:44:13 +1000

How would CLUE fit into this equation?

Do we say for CLUE that a 2nd DTLS association for the data channel 
would need to be established with the MDD? Basically if an endpoint 
wants to use data channels it can't multiplex it on the same DTLS 
association as PERC.

I do agree it doesn't make sense to send CLUE to the KMF.

Regards, Christian

On 3/05/2016 6:01 AM, Adam Roach wrote:
> One of the things that came up on the call last week was what to do 
> with DTLS data received at the KMS; this would include WebRTC 
> datachannels.
>
> Friday), I'm pretty certain that the answer, from a PERC perspective, 
> is that we don't want to specify setting up any kind of data 
> communications along that path. So, for example, an attempt to 
> negotiate a datachannel in a webrtc context would fail.
>
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 4 May 2016 09:42:26 -0500

> that, it doesn't make sense"?

I was thinking the latter: just including guidance that this can't be 
expected to work in the general case, and a suggestion that a full-mesh 
setup for data is more sensible.

/a

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 May 2016 00:59:32 +1000

> setup for data is more sensible.

I would be careful with that.  Rather you should say that PERC is
designed for media, not data.  Suggesting a full mesh just invites the
crazy.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 4 May 2016 13:58:14 -0400

> designed for media, not data.  Suggesting a full mesh just invites the

I would phrase this yet differently.  In principle, you could probably make
something like EKT and -double work for DataChannels; we just haven't.
(And won't.  I think it's pretty clearly out of scope of the current
charter.)

That doesn't mean you can't use them, it just means that you're stuck with
the pre-PERC privilege levels: You're part of the DTLS association or
you're not.  You can send additional DTLS packets to the KMF and have it do
something with them, or you can make a DataChannel to the MDD, but you
can't have the KMF synchronize the keys or allow the MDD to decrypt/modify
anything.

--Richard

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 10 May 2016 16:12:21 +0000

> On May 2, 2016, at 6:43 PM, Martin Thomson <[email-masked]> wrote:
> 

I think it would be more just not defined by PERC and don't expect this to work or do anything in particularly unless something else extended it