Subject: Re: [Perc] FEC/RTX Was: Double encryption codec/payload type

From: Cullen Jennings <[email-masked]>
Date: Sat, 1 Apr 2017 11:06:10 -0500

A bunch of us had a long conversation about this yesterday and came up with 3 or 4 reasonable approaches to this. It's complicated to understand the pro and con of each one as there is some sort of counter intuitive results about how they handle DDOS. 

I'll write these up such that everyone can properly consider them all. What I think would really help now is to outline what problems people are trying to solve and how important they are. 

Some things I know we want to work are:

RTX
FlexFEC

I get the feeling that for most folks FEC is far more important than RTX. Can people give me an idea of other things that need to work that might be impacted by this as well as well as what things are nice to have, vs important, vs critical to have in the first version.

Thanks, Cullen 

> On Mar 30, 2017, at 9:08 PM, Bernard Aboba <[email-masked]> wrote:
> 
> 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] <mailto:[email-masked]>> wrote:
> 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
> 
> 
> _______________________________________________
> Perc mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/perc <https://www.ietf.org/mailman/listinfo/perc>
> 
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 1 Apr 2017 10:13:16 -0600

> On Mar 30, 2017, at 4:57 PM, Sergio Garcia Murillo <[email-masked]> wrote:
> 
> 
> 
>> 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. 
> 
> That is my key question, how it will be signaled?

For what you are talking about, it is not really negotiated in SDP, it is negotiated in the DTLS when it negotiates which transform to use for SRTP.  From the endpoint (not the Media Distributor) point of view, this is very much like a normal DTLS-SRTP call. It used a transform called double... don't think of double as somehow changing the application to work totally differently, think of it as a pretty normal black box encryption that has the odd property that when if you only know half the key, you can only decrypt/encrypt part of the packet.  Yes, inside it is is implemented with two encryption (thus the name double) but think of it as a normal SRTP transform. When we change what SRTP transform is in use, that is not visible in the SDP - it only happens at DTLS level. 

Hope that helps - glad to get on phone and talk to you about how I'm implementing this if that helps.

---

From: Emil Ivov <[email-masked]>
Date: Sat, 01 Apr 2017 16:20:19 +0000

On Thu, 30 Mar 2017 at 18:07, Sergio Garcia Murillo <
[email-masked]> 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.
> >
> >

A bunch of is had a long conversation over lunch the other day and agreed
that this is the way we should do it.

+1

Emil

-- 
sent from my mobile

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sat, 1 Apr 2017 21:56:45 +0200

> Hope that helps - glad to get on phone and talk to you about how I'm implementing this if that helps.

Thanks, appreciated. I have been already checking on how this could be 
implemented on libwertc and this are the required changes, the process 
would look like that.

Inner crypto can only be applied after all the headers have been set, 
luckily in libwertc, headers on the packet can't be modified after the 
payload is set. So inner crypto has to be done after the payload is set, 
and before the packet is feed to the rtx and fec processing. That will 
allow the RTX and FEC code to work unmodified for perc.

Then, packet processing will continue, and outer crypto aplied when 
DTLS/SRTP code kicks in. As you can see, changes required are minimal, 
but perc is not a "black box", but a two independent process. In fact, 
effectively, what you will be doing is not a double dtls encryption, but 
just encrypting the payload with a custom srtp crypto and then sending 
it via DTLS.

So, in fact, not sure why we need to change the DTLS negotiation at all 
for double, seems an overkill and would make any implementation much 
more complex than required.

Best regards
Sergio

---

From: Stephen Botzko <[email-masked]>
Date: Mon, 3 Apr 2017 12:05:41 -0400

+1

For RTX and XOR this might not be as important, but if you have more than
one repair packet per group, then an evil actor could poison the repair
(with some help from the combinatorial explosion)

On Thu, Mar 30, 2017 at 10:08 PM, Bernard Aboba <[email-masked]>
wrote:

> 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 <
>>> 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.
>>>
>>>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 3 Apr 2017 19:21:18 +0200

But this will not specific for PERC but DTLS/SRTP, right? I mean, same 
would apply to a non-perc rtx stream on webrtc.

Best regards
Sergio
On 03/04/2017 18:05, Stephen Botzko wrote:
> +1
>
> For RTX and XOR this might not be as important, but if you have more 
> than one repair packet per group, then an evil actor could poison the 
> repair (with some help from the combinatorial explosion)
>
> On Thu, Mar 30, 2017 at 10:08 PM, Bernard Aboba 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     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]
>     <mailto:[email-masked]>> 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
>
>
>         <https://www.ietf.org/mailman/listinfo/perc>
>
>
>
>     <https://www.ietf.org/mailman/listinfo/perc>
>
>

---

From: Stephen Botzko <[email-masked]>
Date: Mon, 3 Apr 2017 13:06:07 -0400

Repair Poisoning can occur in any use case in which the repair packets
themselves are not authenticated.  Poisoning is a result of an evil actor
sending bogus repair packets that are the correct size and which appear to
be from the correct source.  If the bogus packets are used to repair, then
the reconstructed packet is incorrect.

In PERC, the receiver can detect that the repair failed, since the
reconstructed packet won't authenticate.  If there is only one repair
packet per block, then the receiver can try each received repair packet in
turn, until it finds the true one that does reconstruct a packet that
authenticates.  However, if there are multiple repair packets per block,
then this mitigation quickly becomes impractical.  Instead, you need to
reject the bogus repair packets prior to reconstruction.

RFC 3711 states

   The default processing when using Forward Error Correction (e.g.,
RFC <https://tools.ietf.org/html/rfc2733>
   2733 <https://tools.ietf.org/html/rfc2733>) processing with SRTP
SHALL be to perform FEC processing prior
   to SRTP processing on the sender side and to perform SRTP processing
   prior to FEC processing on the receiver side.  Any change to this
   ordering (reversing it, or, placing FEC between SRTP encryption and
   SRTP authentication) SHALL be signaled out of band.

That default processing order ensures that the repair packets can be
authenticated, which mitigates the threat.

In the specific case of Double, the threat is also mitigated if the
repair packets are authenticated hop-by-hop.  That allows the MD to
repair flows it receives, and also to generate its own repair packets
on flows it sends.

Stephen

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 3 Apr 2017 21:46:13 +0200

Hi Ste,

Not following you, RTX packets are proposed to be HBH (as you state at 
the end), so they will be encrypted and authenticated.

Best regards
Sergio
On 03/04/2017 19:06, Stephen Botzko wrote:
> themselves are not authenticated.  Poisoning is a result of an evil 
> actor sending bogus repair packets that are the correct size and which 
> appear to be from the correct source.  If the bogus packets are used 
> to repair, then the reconstructed packet is incorrect.
>
> packet per block, then the receiver can try each received repair 
> packet in turn, until it finds the true one that does reconstruct a 
> packet that authenticates. However, if there are multiple repair 
> packets per block, then this mitigation quickly becomes impractical.  
> Instead, you need to reject the bogus repair packets prior to 
> reconstruction.
>
> RFC 3711 states
>     The default processing when using Forward Error Correction (e.g.,RFC <https://tools.ietf.org/html/rfc2733>
>     2733 <https://tools.ietf.org/html/rfc2733>) processing with SRTP SHALL be to perform FEC processing prior
> On Mon, Apr 3, 2017 at 1:21 PM, Sergio Garcia Murillo 
>     But this will not specific for PERC but DTLS/SRTP, right? I mean,
>     same would apply to a non-perc rtx stream on webrtc.
>
>     Best regards
>     Sergio
>
>>     For RTX and XOR this might not be as important, but if you have
>>     more than one repair packet per group, then an evil actor could
>>     poison the repair (with some help from the combinatorial explosion)
>>
>>         This would be my preferred option as well, particularly
>>         because it would allow the FEC and RTX packets to be
>>         authenticated.
>>
>>                 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: Bernard Aboba <[email-masked]>
Date: Mon, 3 Apr 2017 12:48:11 -0700

In general, having to perform operations prior to verifying packet
authenticity tends to lead to problems.

Moxie Marlinspike gives several examples of this in his blog post "The
Cryptographic Doom Principle":
https://moxie.org/blog/the-cryptographic-doom-principle/

For example, it might be possible to use "repair poisoning" to create a
PERC "padding attack".

On Mon, Apr 3, 2017 at 10:06 AM, Stephen Botzko <[email-masked]>
wrote:

>    The default processing when using Forward Error Correction (e.g., RFC <https://tools.ietf.org/html/rfc2733>
> That default processing order ensures that the repair packets can be authenticated, which mitigates the threat.
>
>
> In the specific case of Double, the threat is also mitigated if the repair packets are authenticated hop-by-hop.  That allows the MD to repair flows it receives, and also to generate its own repair packets on flows it sends.
>
>
> Stephen
>
>
>>>>> middlebox does not have the E2E key, it's a problem. FEC presents similar
>>>>> This would be my preferred option too, which would mean that FEC
>>>> (well, Flex FEC better) and RTX are also HBH.
>>>>
>>>> Best regards
>>>> Sergio
>>>>
>>>>