Subject: [Perc] Double implementation status

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 15 Nov 2017 16:40:20 +0100

Hello all,

As agreed on latest IETF meeting in Prague, the latest Double Encryption 
proposal seemed technically correct but we were waiting to validate the 
viability of implementing the changes required in an RTP stack.

In order to modify a current webrtc stack (libwebrtc for example) it 
would be needed to :

  * Implement double encryption in libsrtp
  * Modifications to dtls to support tunneling negotiation and
    extracting the key pair (I expect this to be fairly easy)
  * Change all the libwrtc rtp stack to perform rtx/fec after srtp
    encryption and use the repair mode for it

As far as I know, there is a librtsp implementation for double made by 
cisco, which will cover the double encryption part 
(https://github.com/bifurcation/libsrtp/tree/ohb-in-payload), but we 
feel that there are important pieces missing in order to fully validate 
its implementation viability. But the code available seems not to cover 
the repair_mode to be able to apply only the HBH encryption to the 
RTX/FEC packets.

I also feel that the last point is the key one, because the impact of 
modification of the fec/rtx and srtp order can be huge.

Also, I think that it would be needed to know how it would be the 
transition phase be handled when we will have "old" webrtc 
implementations doing fec/rtx before srtp and "new" ones doing it in the 
opposite way.

Best regards

Sergio

---

From: Nils Ohlmeier <[email-masked]>
Date: Thu, 16 Nov 2017 17:41:14 +0800

Hello Sergio,

As an individual contributor.

> On Nov 15, 2017, at 23:40, Sergio Garcia Murillo <[email-masked]> wrote:
> In order to modify a current webrtc stack (libwebrtc for example) it would be needed to :
> 
> Implement double encryption in libsrtp
> Modifications to dtls to support tunneling negotiation and extracting the key pair (I expect this to be fairly easy)
> Change all the libwrtc rtp stack to perform rtx/fec after srtp encryption and use the repair mode for it
> As far as I know, there is a librtsp implementation for double made by cisco, which will cover the double encryption part  (https://github.com/bifurcation/libsrtp/tree/ohb-in-payload <https://github.com/bifurcation/libsrtp/tree/ohb-in-payload>), but we feel that there are important pieces missing in order to fully validate its implementation viability. But the code available seems not to cover the repair_mode to be able to apply only the HBH encryption to the RTX/FEC packets.
> I also feel that the last point is the key one, because the impact of modification of the fec/rtx and srtp order can be huge.
> 
True. The changes needed here are quite substantial.

But just to avoid people having the impression that PERC lite is easier to implement: I think that depends a lot on your design, and in case of Firefox it would also require major surgery.
> Also, I think that it would be needed to know how it would be the transition phase be handled when we will have "old" webrtc implementations doing fec/rtx before srtp and "new" ones doing it in the opposite way.
My assumption here is that the modifications to your webrtc implementation need to allow you to run it in either or mode. So that you can support running calls in the “new” mode when doing PERC calls. But you can keep running in the “old” mode for non-PERC calls.

Eventually there might be value in moving all calls over to the “new” mode where you always encrypt before caching and repair. I assume a transition would require some form of signaling indication that you support and want to do the new mode. But that is discussion for the future how to solve that.

Best regards
  Nils Ohlmeier

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 16 Nov 2017 11:59:45 +0100

On 16/11/2017 10:41, Nils Ohlmeier wrote:
>> On Nov 15, 2017, at 23:40, Sergio Garcia Murillo 
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> As far as I know, there is a librtsp implementation for double made 
>> by cisco, which will cover the double encryption part  
>> feel that there are important pieces missing in order to fully 
>> validate its implementation viability. But the code available seems 
>> not to cover the repair_mode to be able to apply only the HBH 
>> encryption to the RTX/FEC packets.
>>
> But just to avoid people having the impression that PERC lite is 
> easier to implement: I think that depends a lot on your design, and in 
> case of Firefox it would also require major surgery.

Hi Nils,

Could you elaborate?

Adding the end to end encryption is just putting two lines of code in 
the correct places in libwebrtc. Passing the key from js (which is out 
of the scope of this wg) has been made substantially easy by having them 
as a parameter in the setParameters  for rtp senders/receivers.

Where do you expect the problem to arise?

>> implementations doing fec/rtx before srtp and "new" ones doing it in 
>> the opposite way.
>>
> My assumption here is that the modifications to your webrtc 
> implementation need to allow you to run it in either or mode. So that 
> you can support running calls in the “new” mode when doing PERC calls. 
> But you can keep running in the “old” mode for non-PERC calls.
>
> Eventually there might be value in moving all calls over to the “new” 
> mode where you always encrypt before caching and repair. I assume a 
> transition would require some form of signaling indication that you 
> support and want to do the new mode. But that is discussion for the 
> future how to solve that.
>
Apart of having to implement and support two different modes of 
operation, how would the endpoint know in which mode to operate?

I would prefer to answer that solutions now in order to ensure that we 
have a complete solution that RTCWEB group could adopt in the future 
without further discussions.

Best regards
Sergio

---

From: Nils Ohlmeier <[email-masked]>
Date: Fri, 17 Nov 2017 08:59:49 +0800

> On Nov 16, 2017, at 18:59, Sergio Garcia Murillo <[email-masked]> wrote:
> 
> Adding the end to end encryption is just putting two lines of code in the correct places in libwebrtc. Passing the key from js (which is out of the scope of this wg) has been made substantially easy by having them as a parameter in the setParameters  for rtp senders/receivers.
> 

My point is that Firefox doesn't use the standard libwebrtc setup. It invokes libsrtp way outside the libwebrtc stack. Therefore any PERC solution will require major surgery.

> Apart of having to implement and support two different modes of operation, how would the endpoint know in which mode to operate?
> 
> I would prefer to answer that solutions now in order to ensure that we have a complete solution that RTCWEB group could adopt in the future without further discussions.

I fear the answer for that is not within the charter of the PERC working group. But once the PERC working group has chosen a solution for double I would be happy to write a draft with you about signaling in SDP (or other signaling protocols if desired/needed) which alternative of encrypt->repair or repair->encrypt the endpoint support and/or prefers and try to get it through the right working groups at IETF.

Best
  Nils Ohlmeier

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 16 Nov 2017 17:41:41 -0800

Sergio said:

"
Apart of having to implement and support two different modes of operation,
how would the endpoint know in which mode to operate? "

[BA] A more basic question is why there needs to be two modes of operation
in the first place, when a single mode could be made to work and would be
considerably simpler.
"

On Thu, Nov 16, 2017 at 2:59 AM, Sergio Garcia Murillo <
[email-masked]> wrote:

>    - Implement double encryption in libsrtp
>    - Modifications to dtls to support tunneling negotiation and
>    - Change all the libwrtc rtp stack to perform rtx/fec after srtp
> cisco, which will cover the double encryption part  (https://github.com/
> bifurcation/libsrtp/tree/ohb-in-payload), but we feel that there are
> important pieces missing in order to fully validate its implementation
> viability. But the code available seems not to cover the repair_mode to be
> able to apply only the HBH encryption to the RTX/FEC packets.
>
> But just to avoid people having the impression that PERC lite is easier to
> implement: I think that depends a lot on your design, and in case of
> Firefox it would also require major surgery.
>
>
> Hi Nils,
>
> Could you elaborate?
>
> Adding the end to end encryption is just putting two lines of code in the
> correct places in libwebrtc. Passing the key from js (which is out of the
> scope of this wg) has been made substantially easy by having them as a
> parameter in the setParameters  for rtp senders/receivers.
>
> transition phase be handled when we will have "old" webrtc implementations
> doing fec/rtx before srtp and "new" ones doing it in the opposite way.
>
> My assumption here is that the modifications to your webrtc implementation
> need to allow you to run it in either or mode. So that you can support
> running calls in the “new” mode when doing PERC calls. But you can keep
> running in the “old” mode for non-PERC calls.
>
> Eventually there might be value in moving all calls over to the “new” mode
> where you always encrypt before caching and repair. I assume a transition
> would require some form of signaling indication that you support and want
> to do the new mode. But that is discussion for the future how to solve that.
>
> Apart of having to implement and support two different modes of operation,
> how would the endpoint know in which mode to operate?
>
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc
>
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 17 Nov 2017 10:22:56 +0100

El 17/11/2017 2:04, "Nils Ohlmeier" <[email-masked] 
<mailto:[email-masked]>> escribió:

     > On Nov 16, 2017, at 18:59, Sergio Garcia Murillo
     >> But just to avoid people having the impression that PERC lite is
    easier to implement: I think that depends a lot on your design, and
    in case of Firefox it would also require major surgery.
     >
     > Hi Nils,
     >
     > Could you elaborate?
     >
     > Adding the end to end encryption is just putting two lines of
    code in the correct places in libwebrtc. Passing the key from js
    (which is out of the scope of this wg) has been made substantially
    easy by having them as a parameter in the setParameters  for rtp
    senders/receivers.
     > Where do you expect the problem to arise?

    My point is that Firefox doesn't use the standard libwebrtc setup.
    It invokes libsrtp way outside the libwebrtc stack. Therefore any
    PERC solution will require major surgery.

AFAIK Firefox doesn't support neither RTX nor FEC, so it should be 
fairly easy to add Lite. You don't need to change neither your ICE/DTLS, 
just place the inner crypto before calling your srtp code, or even 
inside your code.

     >> My assumption here is that the modifications to your webrtc
    implementation need to allow you to run it in either or mode. So
    that you can support running calls in the “new” mode when doing PERC
    calls. But you can keep running in the “old” mode for non-PERC calls.
     >>
     >> Eventually there might be value in moving all calls over to the
    “new” mode where you always encrypt before caching and repair. I
    assume a transition would require some form of signaling indication
    that you support and want to do the new mode. But that is discussion
    for the future how to solve that.
     >
     > I would prefer to answer that solutions now in order to ensure
    that we have a complete solution that RTCWEB group could adopt in
    the future without further discussions.

    I fear the answer for that is not within the charter of the PERC
    working group. But once the PERC working group has chosen a solution
    for double I would be happy to write a draft with you about
    signaling in SDP (or other signaling protocols if desired/needed)
    which alternative of encrypt->repair or repair->encrypt the endpoint
    support and/or prefers and try to get it through the right working
    groups at IETF.

Well, the fact is that I don't want to have to write any draft about 
signaling in SDP for PERC to work :)

Best regards
Sergio