Subject: [Perc] Quick tutorial on PERC keys

From: Cullen Jennings <[email-masked]>
Date: Wed, 12 Apr 2017 11:27:36 -0600

To help explain the keys in perc, I put together some slides you can find at 

https://dl.dropboxusercontent.com/u/17089001/Perc/perc-explained_v3.pdf

and 

https://vimeo.com/212949427

Cullen

---

From: Russ Housley <[email-masked]>
Date: Wed, 12 Apr 2017 15:01:06 -0400

Cullen:

Thanks so much for sharing these.

I have one question about slide 7.  Do these packets flow directly from Alice to Bob and vice versa?  I was expecting to see the wrapped keys sent via the Key Distributor.

Russ

> On Apr 12, 2017, at 1:27 PM, Cullen Jennings <[email-masked]> wrote:
>

---

From: Nils Ohlmeier <[email-masked]>
Date: Wed, 12 Apr 2017 14:58:54 -0700

Hello Russ,

Yes the keys between Alice and Bob get exchanged directly between the clients. (Note: the MD acts as relay on the IP layer for all of Cullen’s ‘Big Picture’ slides, as the clients don’t have any direct IP connection established among them, nor with the Key Distributor.)
The Key Distributor is basically left out of the picture once it has distributed the shared key to all clients. I’m currently not aware of any reason why the Key Distributor should actually know these client keys.

Best
  Nils Ohlmeier

> On Apr 12, 2017, at 12:01, Russ Housley <[email-masked]> wrote:
> 
> Cullen:
> 
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc

---

From: Russ Housley <[email-masked]>
Date: Wed, 12 Apr 2017 18:48:55 -0400

> The Key Distributor is basically left out of the picture once it has distributed the shared key to all clients. I’m currently not aware of any reason why the Key Distributor should actually know th…

I am not suggesting that the Key Distributor ought to know the client keys. Of course, it does have the key needed to decrypt if it ever got the packets.

I was thinking about the complexity associated with middleboxes, especially NATs and firewalls.  Alice and Bob already have communications with the Key Distributor and the Media Distributor.  Sending the wrapped key via one of them could avoid a bunch of complexity associated with the peer-to-peer communications.

Russ

---

From: Nils Ohlmeier <[email-masked]>
Date: Wed, 12 Apr 2017 16:05:59 -0700

Russ,

> On Apr 12, 2017, at 15:48, Russ Housley <[email-masked]> wrote:
> 
> Nils:
>> 

While the Key Distributor obviously knows the shared yellow key, you will notice that it does not know the red keys.

> I was thinking about the complexity associated with middleboxes, especially NATs and firewalls.  Alice and Bob already have communications with the Key Distributor and the Media Distributor.  Sendi…

The ‘Big Picture’ slides up to slide 7 do not take IP layer connections into account. Both endpoints, Alice and Bob, will have IP connections to the MD. So the key exchange on slide seven gets relayed on the IP layer through the MD. You can see that on slide 14 and 15.
Sure both endpoints also maintain their DTLS connection to the KD, but since these connection are relayed on the IP layer through the MD again, exchanging the red sending keys through the KD would only add extra delays.

I fact I think that in case of the “cloud KD” on slide 12 Bob does not even have to have a connection to the KD. I would expect that arrow #0 goes to WebEx box, which then chooses a KD and talks to it in the name of Bob. But that is probably a detail of how people want to deploy this.

Best
  Nils Ohlmeier

---

From: Richard Barnes <[email-masked]>
Date: Wed, 12 Apr 2017 20:10:12 -0400

It's really not clear to me how these slides map to the mechanisms we have
on the table.  Could someone explain how you accomplish what's in these
slides with DTLS-SRTP and EKT?

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 13 Apr 2017 13:45:11 -0600

Russ, 

I'll update these slides to show the arrows going thought the Media Distributor - I think that will make it clearer that all the packets flowing from Alice to Media Distributor to Bob. 

Thanks. 

> On Apr 12, 2017, at 5:05 PM, Nils Ohlmeier <[email-masked]> wrote:
> 
> Russ,
>

---

From: Emil Ivov <[email-masked]>
Date: Thu, 13 Apr 2017 16:27:08 -0500

This is very helpful!

Thanks for putting it together!

Emil

-- 
https://jitsi.org

---

From: Adam Roach <[email-masked]>
Date: Thu, 13 Apr 2017 18:08:29 -0500

On 4/12/17 19:10, Richard Barnes wrote:
> It's really not clear to me how these slides map to the mechanisms we 
> have on the table.  Could someone explain how you accomplish what's in 
> these slides with DTLS-SRTP and EKT?

Cullen's slides expand on the key exchange that I used 
<https://www.ietf.org/proceedings/95/slides/slides-95-perc-4.pdf> to 
illustrate. As far as I know, the DTLS-SRTP and EKT handling has not 
changed since I created that older deck. I believe that the final three 
slides of that deck should answer your question.

/a

---

From: Richard Barnes <[email-masked]>
Date: Thu, 13 Apr 2017 22:12:01 -0400

On Thu, Apr 13, 2017 at 7:08 PM, Adam Roach <[email-masked]> wrote:

> Cullen's slides expand on the key exchange that I used <
> https://www.ietf.org/proceedings/95/slides/slides-95-perc-4.pdf> to

Here's where you're losing me, though: These entities called "HBH key" and
"E2E key" don't actually exist; they're internal to the double transform.
>From every other perspective -- DTLS-SRTP, EKT, etc -- there is one key
that's twice the length of an AES key.  So you never send around an "E2E
key" or an "HBH" key, you send around one big key that has E2E and HBH
halves.

When participant A sends an EKT message to participant B when B joins, it
sets both the HBH and E2E keys that B will use to decrypt packets from A's
SSRC.  This implies that there's no need for the MD to do re-encryption HBH
unless it wants to change something.

Here's the story as I understand it at this point:

- Each endpoint establishes an HBH+E2E key from the DTLS handshake that it
uses for transmission
- The KD tells the MD the HBH half of each of these keys
- The KD tells each endpoint an EKTKey in an ekt_key message (encrypted
under some key derived from the DTLS handshake)
- On join, each endpoint sends an EKTCiphertext message with its HBH+E2E
transmission key, encrypted with the EKTKey

In colorful slides (with apologies to the red/green colorblind in the
audience):

https://docs.google.com/presentation/d/1LpKZSN_7mKzN0C0gllsT8Znb3YnaikLa0h1znahWajg/edit?usp=sharing

Does this seem correct to folks?

--Richard

---

From: Nils Ohlmeier <[email-masked]>
Date: Thu, 13 Apr 2017 21:42:44 -0700

> On Apr 13, 2017, at 19:12, Richard Barnes <[email-masked]> wrote:
> Here's where you're losing me, though: These entities called "HBH key" and "E2E key" don't actually exist; they're internal to the double transform.  From every other perspective -- DTLS-SRTP, EKT, etc -- there is one key that's twice the length of an AES key.  So you never send around an "E2E key" or an "HBH" key, you send around one big key that has E2E and HBH halves.
> 
> When participant A sends an EKT message to participant B when B joins, it sets both the HBH and E2E keys that B will use to decrypt packets from A's SSRC.  This implies that there's no need for the MD to do re-encryption HBH unless it wants to change something.
> 
> - Each endpoint establishes an HBH+E2E key from the DTLS handshake that it uses for transmission
> - The KD tells each endpoint an EKTKey in an ekt_key message (encrypted under some key derived from the DTLS handshake)
> - On join, each endpoint sends an EKTCiphertext message with its HBH+E2E transmission key, encrypted with the EKTKey
> 
> In colorful slides (with apologies to the red/green colorblind in the audience):
> 
> https://docs.google.com/presentation/d/1LpKZSN_7mKzN0C0gllsT8Znb3YnaikLa0h1znahWajg/edit?usp=sharing <https://docs.google.com/presentation/d/1LpKZSN_7mKzN0C0gllsT8Znb3YnaikLa0h1znahWajg/edit?usp=sharing>
> 

I see you point here. And it start to dawn on me why there are sometimes discussions about one or two crypto contexts.

The part which I don’t get though is what you haven’t documented in your slides when endpoints start to send RTP:
- A uses the red EH key to encrypt its RTP packet and sends it to the MD
- Now you seem to suggest the MD could work in two different modes:
  - #1: it just takes the unmodified packet and forwards its to B (and C & D), so its operating in a 1:N relay mode (similar to a TURN relay not paying attention to the packet, but relaying 1:N instead of 1:1 like your normal TURN relay)
  - #2: it needs to re-write the PT for example:
    - so it decrypts the outer encryption with the red H key
    - replaces the PT value and inserts (or replaces) the OHB extension header
    - now it needs to encrypt the packet again. Which H key does it use?

For me natural choice at this point would be to use the green H key, because that is the key the MD shares with participant B. But then how would B know if it needs to use the red or the green H key to decrypt the outer encryption.
So it looks to me like it needs to use the red H key instead again to encrypt. Which looks strange because then it appears as if the MD is impersonating A at this point.

Clarification on how an MD which wants to re-write packets under your description works would be appreciated.

Thanks
 Nils Ohlmeier

---

From: Emil Ivov <[email-masked]>
Date: Fri, 14 Apr 2017 07:06:36 +0000

> key" or an "HBH" key, you send around one big key that has E2E and HBH

I think that this view of the situation is probably the reason for a big
part of the disagreements in the working group.

I do see the appeal here but looking at this as a single key adds way too
many unnecessary constraints.

This is certainly not how our implementation works.

Emil

-- 
sent from my mobile

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 14 Apr 2017 09:14:21 +0200

On 14/04/2017 9:06, Emil Ivov wrote:
>     On Thu, Apr 13, 2017 at 7:08 PM, Adam Roach <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>             It's really not clear to me how these slides map to the
>             mechanisms we have on the table.  Could someone explain
>             how you accomplish what's in these slides with DTLS-SRTP
>             and EKT?
>
>
>         <https://www.ietf.org/proceedings/95/slides/slides-95-perc-4.pdf>
>         to illustrate. As far as I know, the DTLS-SRTP and EKT
>         handling has not changed since I created that older deck. I
>         believe that the final three slides of that deck should answer
>         your question.
>
>
>     Here's where you're losing me, though: These entities called "HBH
>     key" and "E2E key" don't actually exist; they're internal to the
>     double transform.  From every other perspective -- DTLS-SRTP, EKT,
>     etc -- there is one key that's twice the length of an AES key.  So
>     you never send around an "E2E key" or an "HBH" key, you send
>     around one big key that has E2E and HBH halves.
>
>
> I think that this view of the situation is probably the reason for a 
> big part of the disagreements in the working group.
>
> I do see the appeal here but looking at this as a single key adds way 
> too many unnecessary constraints.
>

I agree, and IMHO saying that there is "only one key that is the result 
of concatenation of two keys" is an artificial construct. The truth is 
that there is a pair of keys as Cullen slides show, wether they are 
transfer and set in a single blob or not is irrelevant.

Best regards
Sergio

---

From: Nils Ohlmeier <[email-masked]>
Date: Fri, 14 Apr 2017 00:22:48 -0700

> On Apr 14, 2017, at 00:14, Sergio Garcia Murillo <[email-masked]> wrote:
> 
> I agree, and IMHO saying that there is "only one key that is the result of concatenation of two keys" is an artificial construct. The truth is that there is a pair of keys as Cullen slides show, wether they are transfer and set in a single blob or not is irrelevant.

In Richard’s scenario the whole double key is derived from the DTLS connection. So the KD also knows the full key, but throws away half of it (and only sends the other half to the MD).

In Cullen’s slide 6 it says the endpoints “has” an end-to-end key. I assume that means it either generates a new key for every call. Or could this key be administrated to be the same one for all calls?

To me Cullen’s scenario makes more sense from the point of distributing only the minimum amount of keys.

  Nils

---

From: Richard Barnes <[email-masked]>
Date: Fri, 14 Apr 2017 09:44:45 -0400

On Fri, Apr 14, 2017 at 12:42 AM, Nils Ohlmeier <[email-masked]>
wrote:

> https://docs.google.com/presentation/d/1LpKZSN_
> 7mKzN0C0gllsT8Znb3YnaikLa0h1znahWajg/edit?usp=sharing
>
> I see you point here. And it start to dawn on me why there are sometimes
> discussions about one or two crypto contexts.
>
>   - #1: it just takes the unmodified packet and forwards its to B (and C &
> D), so its operating in a 1:N relay mode (similar to a TURN relay not
> paying attention to the packet, but relaying 1:N instead of 1:1 like your
> normal TURN relay)

If I'm understanding everything correctly, it uses the red H key.

EKT sets the encryption key for an SSRC, so when A sent the red EH key to B
in EKT, B learned that it needs to use the red EH key to decrypt what it
receives from A's SSRC.  So the MD needs to use the red H key to re-do the
HBH transform.

In other words, the same E2E and HBH keys are always used together.  If you
have two pairs (E1, H1) and (E2, H2), then E1 is used for the inner
transform if and only if H1 is used for the outer transform, and likewise
for E2/H2.

--Richard

>
> For me natural choice at this point would be to use the green H key,
> because that is the key the MD shares with participant B. But then how
> would B know if it needs to use the red or the green H key to decrypt the
> outer encryption.
> So it looks to me like it needs to use the red H key instead again to
> encrypt. Which looks strange because then it appears as if the MD is
> impersonating A at this point.
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 14 Apr 2017 09:50:22 -0400

On Fri, Apr 14, 2017 at 3:14 AM, Sergio Garcia Murillo <
[email-masked]> wrote:

> On Thu, 13 Apr 2017 at 21:12, Richard Barnes <[email-masked]> <[email-masked]>
> wrote:
>
>> Here's where you're losing me, though: These entities called "HBH key"
>> and "E2E key" don't actually exist; they're internal to the double
>> transform.  From every other perspective -- DTLS-SRTP, EKT, etc -- there is
>> one key that's twice the length of an AES key.  So you never send around an
>> "E2E key" or an "HBH" key, you send around one big key that has E2E and HBH
>> halves.
>>
>
> I agree, and IMHO saying that there is "only one key that is the result of
> concatenation of two keys" is an artificial construct.
>

Well, at a certain level, everything we do here is an artificial construct
:)  There's nothing natural about the Internet.

I'm not saying that there's one key because I like the aesthetics.  I'm
saying that because that's the semantic that's available from the protocols
we're depending on here, namely DTLS-SRTP and EKT.  If we want the
specifications to work in terms of pairs of keys with independent halves,
we'll need to patch those specifications, or require that they be used in
special ways.  For example, if you wanted to have the HBH key be the same
for all endpoints, we would have to define how it gets synchronized;
there's nothing else that's going to do that for you.

Personally, I think it's cleaner to deal in terms of one key (except where
we give half a key to the MD).  It makes the media layer look basically the
same as non-PERC for everyone but the MD, and the only cost to the MD is
that it has to keep a table of HBH instead of a single one -- but of course
pre-PERC, it had whole independent DTLS state per client, so that doesn't
seem like a big deal.

--Richard

> The truth is that there is a pair of keys as Cullen slides show, wether
> they are transfer and set in a single blob or not is irrelevant.
>
> Best regards
> Sergio
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 14 Apr 2017 20:36:06 +0200

On 14/04/2017 15:50, Richard Barnes wrote:
>
>
> On Fri, Apr 14, 2017 at 3:14 AM, Sergio Garcia Murillo 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>     On Thu, 13 Apr 2017 at 21:12, Richard Barnes <[email-masked]>
>>     <mailto:[email-masked]> wrote:
>>
>>                 It's really not clear to me how these slides map to
>>                 the mechanisms we have on the table.  Could someone
>>                 explain how you accomplish what's in these slides
>>                 with DTLS-SRTP and EKT?
>>
>>
>>             <https://www.ietf.org/proceedings/95/slides/slides-95-perc-4.pdf
>>             <https://www.ietf.org/proceedings/95/slides/slides-95-perc-4.pdf>>
>>             handling has not changed since I created that older deck.
>>             I believe that the final three slides of that deck should
>>             answer your question.
>>
>>
>>         Here's where you're losing me, though: These entities called
>>         "HBH key" and "E2E key" don't actually exist; they're
>>         internal to the double transform.  From every other
>>         perspective -- DTLS-SRTP, EKT, etc -- there is one key that's
>>         twice the length of an AES key.  So you never send around an
>>         "E2E key" or an "HBH" key, you send around one big key that
>>         has E2E and HBH halves.
>>
>>
>>     I think that this view of the situation is probably the reason
>>     for a big part of the disagreements in the working group.
>>
>>     I do see the appeal here but looking at this as a single key adds
>>     way too many unnecessary constraints.
>>
>     I agree, and IMHO saying that there is "only one key that is the
>     result of concatenation of two keys" is an artificial construct.
>
>
> Well, at a certain level, everything we do here is an artificial 
> construct :)  There's nothing natural about the Internet.
>
> I'm not saying that there's one key because I like the aesthetics.  
> I'm saying that because that's the semantic that's available from the 
> protocols we're depending on here, namely DTLS-SRTP and EKT.  If we 
> want the specifications to work in terms of pairs of keys with 
> independent halves, we'll need to patch those specifications, or 
> require that they be used in special ways.  For example, if you wanted 
> to have the HBH key be the same for all endpoints, we would have to 
> define how it gets synchronized; there's nothing else that's going to 
> do that for you.
>
> Personally, I think it's cleaner to deal in terms of one key (except 
> where we give half a key to the MD).  It makes the media layer look 
> basically the same as non-PERC for everyone but the MD, and the only 
> cost to the MD is that it has to keep a table of HBH instead of a 
> single one -- but of course pre-PERC, it had whole independent DTLS 
> state per client, so that doesn't seem like a big deal.
>

Well, I have a completely different view, and I think this is the root 
of all misunderstandings with double encryption.

The reality is that we have two crypto keys one for the HBH and one 
shared for the E2E. The E2E encryption would work even if we didn't used 
DTLS/SRTP for HBH and we just sent it in plain RTP. So while some people 
see it as "DTLS/SRTP with double encryption" others (at least me) start 
to see it as "E2E media encryption using SRTP shared key sent over 
DTLS/SRTP".

Best regards
Sergio

---

From: Stephen Botzko <[email-masked]>
Date: Fri, 14 Apr 2017 14:57:11 -0400

On Fri, Apr 14, 2017 at 9:50 AM, Richard Barnes <[email-masked]> wrote:

>> of concatenation of two keys" is an artificial construct.
>>
>

[sb] Until you try to make RTX and FEC repair flows work properly - and
they have work properly for PERC to be viable.  "Work properly" includes
the ability of the endpoints to authenticate the repair flows, so it is not
just about the MD implementation. [/sb]

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 17 Apr 2017 14:37:52 -0700

> On Apr 13, 2017, at 7:12 PM, Richard Barnes <[email-masked]> wrote:
> 
> 
> On Thu, Apr 13, 2017 at 7:08 PM, Adam Roach <[email-masked] <mailto:[email-masked]>> wrote:
> It's really not clear to me how these slides map to the mechanisms we have on the table.  Could someone explain how you accomplish what's in these slides with DTLS-SRTP and EKT?
> 
> Cullen's slides expand on the key exchange that I used <https://www.ietf.org/proceedings/95/slides/slides-95-perc-4.pdf <https://www.ietf.org/proceedings/95/slides/slides-95-perc-4.pdf>> to illustrate. As far as I know, the DTLS-SRTP and EKT handling has not changed since I created that older deck. I believe that the final three slides of that deck should answer your question.
> 

That's roughly what I have had in my mind for a long time but is slightly different than what is in framework. The slight differences being if all the participants have own HBH key is effectively shared across all to all participants. I think the protocols support both (basically difference is if EKT shares half or full key double key ). I don't care too much but we would need to update framework slightly to reflect this.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 17 Apr 2017 18:05:03 -0400

On Mon, Apr 17, 2017 at 5:37 PM, Cullen Jennings <[email-masked]> wrote:

> That's roughly what I have had in my mind for a long time but is slightly
> different than what is in framework. The slight differences being if all
> the participants have own HBH key is effectively shared across all to all
> participants. I think the protocols support both (basically difference is
> if EKT shares half or full key double key ). I don't care too much but we
> would need to update framework slightly to reflect this.
>

So it sounds like we need a document update here either way:

1. With the approach in Cullen's slides, we would need to update EKT to
handle half-keys
2. With the approach in my slides, we would need to update -framework

ISTM that (2) is the right approach.  Updating EKT to handle half-keys
would either require a general mechanism to partly update keys, a giant
foot-gun, or a double-specific provision in EKT, which reduces the utility
of EKT quite a bit.

For the folks in the crowd concerned about RTX / FEC -- this shouldn't make
a profound difference one way or the other.  There's no difference between
the two cases in terms of what's encrypted or what the MD can do.

--Richard