Subject: [Perc] Double encryption codec/payload type

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 30 Mar 2017 20:01:06 +0200

Hi all,

I have another doubt about double encryption, which payload should it 
use. If I read the specs correctly the original media payload should be 
used for carrying the inner encrypted packet.

This doesn't seem very correct to me, as it breaks the semantic of the 
SDP. How about using an new codec/payload type for carrying that 
information and use an apt-like semantic for signaling the PT of the 
inner packet?

Best regards

Sergio

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 30 Mar 2017 20:03:56 +0000

Sergio,

I don't fully understand your question, since we did not define an 
"inner packet".  There are two encryption passes over the packet using 
two different keys, so I guess you're referring to the first encryption 
pass.

We do not change the PT when we apply SRTP, so applying "double" should 
not result in a new PT, either.  It's just a new "transform".

So, I'm not sure what you mean here.

Paul

------ Original Message ------
From: "Sergio Garcia Murillo" <[email-masked]>
To: [email-masked]
Sent: 3/30/2017 2:01:06 PM
Subject: [Perc] Double encryption codec/payload type

>_______________________________________________
>Perc mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/perc

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 30 Mar 2017 22:22:45 +0200

For me conceptually you are just tunneling an rtp over rtp, at least 
this is how I am implementing it. Let me explain.

For applying the first crypto, you need an rtp packet (my "inner 
packet), of the resulting srtp packet, you are creating another rtp 
packet ("outher packet) with happens to have same rtp header, copy the 
encrypted payload of the encrypted inner packet, encrypt it again and 
send it to the MD.

The MD then decrypts the  it, removes the "outher packet", and 
creates/encrypts another "outher packet"  with the payload, to send it 
to the receiver, but the receiver in order decrypt it, needs to recreate 
the original "inner packet", that's why we are sending the the OHB data.

At the end this is a very similar mechanism to RED/FEC or even RTX, so 
that's why I think that it could make sense to use a new codec/payload 
to signal it.

The other alternative to signal this on the SDP would be to change the 
transport to somthing like UDP/TLS/RTP/TLS/RTP/SAVPF (or whatever) but I 
don't think that would be semantically correct, as the inner encryption 
can't be terminated at the MD. So in fact, what you are transporting on 
the RTP packet is an encrypted payload, whin in SDP semantics requires a 
codec and a payload.

What is your view about this?

Best regards
Sergio

On 30/03/2017 22:03, Paul E. Jones wrote:
> two different keys, so I guess you're referring to the first 
> encryption pass.
>
> We do not change the PT when we apply SRTP, so applying "double" 
> should not result in a new PT, either.  It's just a new "transform".
>
>> use. If I read the specs correctly the original media payload should 
>> be used for carrying the inner encrypted packet.
>>
>> This doesn't seem very correct to me, as it breaks the semantic of 
>> the SDP. How about using an new codec/payload type for carrying that

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 30 Mar 2017 22:43:13 +0000

Sergio,

Our original proposal was to encrypt the packet using one key and 
authenticate using a second key.  In theory, that could have been done 
in a single pass (and we coded it that way).

With PERC, it's now fully two passes of encryption.  The steps at the 
endpoint are:
1) Form an RTP packet;
2) Call rtp_protect() (or similar function) that applies the double 
cipher logic;
3) Append the EKT tag; and
4) Send the packet.

I don't see the reason for having a separate PT and I don't view it as 
tunneling one packet inside another packet.

RTX is a problem, because we want the middlebox to act on packets.  But 
since the RTX data is inserted before encryption and since the middlebox 
does not have the E2E key, it's a problem.  FEC presents similar 
challenges.  A possible solution is to do one pass of encryption, then 
RTX, then the second.  That was proposed at the meeting yesterday.

Even if we split the two-pass encryption step fully into two pieces, 
that's not creating a tunnel or a new media type.  It's just how the 
crypto transforms are applied.  Devices who receive the media are going 
to know and understand this, because it will be negotiated in SDP.

Paul

------ Original Message ------
From: "Sergio Garcia Murillo" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>; [email-masked]
Sent: 3/30/2017 4:22:45 PM
Subject: Re: [Perc] Double encryption codec/payload type

>to the receiver, but the receiver in order decrypt it, needs to 
>recreate the original "inner packet", that's why we are sending the the 
>OHB data.
>
>transport to somthing like UDP/TLS/RTP/TLS/RTP/SAVPF (or whatever) but 
>I don't think that would be semantically correct, as the inner 
>encryption can't be terminated at the MD. So in fact, what you are 
>transporting on the RTP packet is an encrypted payload, whin in SDP 
>semantics requires a codec and a payload.
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 31 Mar 2017 00:57:04 +0200

> crypto transforms are applied.  Devices who receive the media are 
> going to know and understand this, because it will be negotiated in SDP. 

That is my key question, how it will be signaled?

Best regards
Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 31 Mar 2017 01:07:50 +0200

On 31/03/2017 0:43, Paul E. Jones wrote:
>
> RTX is a problem, because we want the middlebox to act on packets.  
> But since the RTX data is inserted before encryption and since the 
> middlebox does not have the E2E key, it's a problem. FEC presents 
> similar challenges.  A possible solution is to do one pass of 
> encryption, then RTX, then the second.  That was proposed at the 
> meeting yesterday.
>
>
This would be my preferred option too, which would mean that FEC (well, 
Flex FEC better) and RTX are also HBH.

Best regards
Sergio

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 31 Mar 2017 01:47:11 +0000

Sergio,

Signaling work has literally just started with an initial draft from 
Adam Roach:
https://tools.ietf.org/html/draft-roach-perc-webrtc-00

One big clue is that when DTLS-SRTP is performed, the ciphers indicated 
would be DOUBLE_*.  Another clue will be the EKTKey message, though that 
in and of itself doesn't mean "PERC" and endpoints that do not 
understand that DTLS message will not act on it.  We might want to have 
something more explicit, but that isn't yet defined.

Paul

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 30 Mar 2017 21:08:58 -0500

This would be my preferred option as well, particularly because it would
allow the FEC and RTX packets to be authenticated.

On Thu, Mar 30, 2017 at 6:07 PM, Sergio Garcia Murillo <
[email-masked]> wrote:

>> challenges.  A possible solution is to do one pass of encryption, then RTX,
>> then the second.  That was proposed at the meeting yesterday.
>>
>>