Subject: [Perc] Double Encryption and header extensions issue

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

Hi all,

I have been reviewing the documentation for double encryption and I have 
serious doubts about how the header extensions are handled.

If I have understood it (please correct me if I am wrong) the MD must 
rely all the header extensions present before the OHB to the other peers:

       The Media Distributor MUST NOT delete any header extensions before
       the OHB, but MAY add, delete, or modify any that follow the OHB.

This is an obvious requirement, as to be able to decrypt the inner 
crypto, the end receiver must have the same original rtp packet, which 
includes header extensions.

My concerns is that there are scenarios in which this is not possible:

  * Sender and receiver may not support same set of header extensions
  * Sender and receiver may have negotiated a different id for same
    header extension

In any of the previous scenarios, the receiver will not be able to parse 
the packet correctly, and at best case scenario, it will ignore the 
header extension.

Is there anything that I missing?

Best regards
Sergio

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 30 Mar 2017 16:31:39 +0000

Sergio,

Your interpretation is correct, I think.  When we submitted the original 
proposal for PERC (that we called "PRIME"), the RTP payload itself was 
encrypted using an E2E key, but the headers only authenticated with a 
HBH key.  That draft was this:
https://tools.ietf.org/html/draft-jones-avtcore-private-media-framework-00

This was proposed using a single crypto context with an additional E2E 
key.  Another way to have viewed this (which I think is perhaps easiest 
to comprehend) is that there were two contexts, one for E2E and one for 
HBH.  The E2E context would have used, for example, AES-CM with null 
authentication and the HBH context would have used null encryption and 
HMAC-SHA1 for authentication.  (Of course, any ciphers or auth functions 
could have been used.)  This would have allowed the middlebox to change 
headers as it saw fit, so long as we retained the fields required to 
re-construct the crypto contexts.  However, the need to maintain SSRC 
and sequence numbers to reconstruct the crypto context is where a lot of 
discussion took place that forced some discussion on how we had proposed 
to do the encryption.

Double addressed the issue of changing certain critical fields, while 
also moving toward authenticated encryption.  There were concerns with 
introducing a new RFC with a split in encryption and authentication, so 
Double addressed those concerns, too.

However, you're right that the negotiated values might present a 
problem.  I've not spent much time thinking about how to solve that.  
During this meeting, there were also concerns raised with Double and how 
it works with RTX and FEC. Obviously, we need to get that right and 
perhaps those and the RTP header extension concerns you raise should 
both be topics for discussion in an interim meeting that the chairs will 
be arranging.

Paul

------ Original Message ------
From: "Sergio Garcia Murillo" <[email-masked]>
To: [email-masked]
Sent: 3/30/2017 11:16:11 AM
Subject: [Perc] Double Encryption and header extensions issue

>Hi all,
>
>I have been reviewing the documentation for double encryption and I 
>have serious doubts about how the header extensions are handled.
>
>The Media Distributor MUST NOT delete any header extensions before the 
>OHB, but MAY add, delete, or modify any that follow the OHB. This is an 
>obvious requirement, as to be able to decrypt the inner crypto, the end 
>receiver must have the same original rtp packet, which includes header 
>extensions.
>
>Sender and receiver may not support same set of header extensionsSender 
>and receiver may have negotiated a different id for same header 
>extension
>In any of the previous scenarios, the receiver will not be able to 
>parse the packet correctly, and at best case scenario, it will ignore 
>the header extension.
>

---

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

Maybe I am jumping to the conclusions too fast, but IMHO both RTX/FEC 
and header extensions should be HBH and not E2E.

For header extensions I don't see a feasible way of negotiating the 
minimum common header extension subsets and getting all clients use the 
same extensions with same id. Also, I don't see much value in having the 
rtp header extensions E2E, as except the video orientation one, most of 
them are meant to be terminated at the MD (except the video orientation 
which would just need to be copied by the SFU).

Also, I don't see any privacy issue doing extensions HBH, as they are 
transmitted in clear to the MD, and even more, the main purpose of the 
rfc6904 for encrypted header extensions was to protect the client to 
mixer/mixer to client audio indications, which by definition are not E2E 
and required by an SFU to operate.

So IMHO, the inner encryption should be done on a "cloned" packet 
without extensions, and even more, we could use that encoded packet as 
the media payload of the outer encryption and forget about OHB 
completely and solve the RTX/FEC issue altogether. After all, it would 
be just a matter of adding an extra 12 bytes overhead (the full rtp 
payload header) vs the current OHB header extension, which could get 
also up to those 12 bytes if we need to include ssrc and ts.

Best regards
Sergio

On 30/03/2017 18:31, Paul E. Jones wrote:
> Sergio,
>
> Your interpretation is correct, I think.  When we submitted the 
> original proposal for PERC (that we called "PRIME"), the RTP payload 
> itself was encrypted using an E2E key, but the headers only 
> authenticated with a HBH key.  That draft was this:
> key.  Another way to have viewed this (which I think is perhaps 
> easiest to comprehend) is that there were two contexts, one for E2E 
> and one for HBH.  The E2E context would have used, for example, AES-CM 
> with null authentication and the HBH context would have used null 
> encryption and HMAC-SHA1 for authentication.  (Of course, any ciphers 
> or auth functions could have been used.)  This would have allowed the 
> middlebox to change headers as it saw fit, so long as we retained the 
> fields required to re-construct the crypto contexts.  However, the 
> need to maintain SSRC and sequence numbers to reconstruct the crypto 
> context is where a lot of discussion took place that forced some 
> discussion on how we had proposed to do the encryption.
>
> introducing a new RFC with a split in encryption and authentication, 
> so Double addressed those concerns, too.
>
>  During this meeting, there were also concerns raised with Double and 
> how it works with RTX and FEC. Obviously, we need to get that right 
> and perhaps those and the RTP header extension concerns you raise 
> should both be topics for discussion in an interim meeting that the 
> chairs will be arranging.
>
> Paul
>
> From: "Sergio Garcia Murillo" <[email-masked] 
> <mailto:[email-masked]>>
> To: [email-masked] <mailto:[email-masked]>
>> crypto, the end receiver must have the same original rtp packet, 
>> which includes header extensions.
>>

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 30 Mar 2017 17:42:00 +0000

Sergio,

For RTX and FEC, I wasn't referring to the header extensions, but rather 
how those are handled in light of "double."

What you suggest is certainly possible.  We could have the endpoints 
insert the OHB as the first extension and then have all others follow 
it.  That would make all extensions HBH, effectively.

Paul

------ Original Message ------
From: "Sergio Garcia Murillo" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>; [email-masked]
Sent: 3/30/2017 1:02:39 PM
Subject: Re: [Perc] Double Encryption and header extensions issue

>same extensions with same id. Also, I don't see much value in having 
>the rtp header extensions E2E, as except the video orientation one, 
>most of them are meant to be terminated at the MD (except the video 
>orientation which would just need to be copied by the SFU).
>
>mixer/mixer to client audio indications, which by definition are not 
>E2E and required by an SFU to operate.
>
>>>the OHB, but MAY add, delete, or modify any that follow the OHB. This 
>>>is an obvious requirement, as to be able to decrypt the inner crypto, 
>>>the end receiver must have the same original rtp packet, which 
>>>Sender and receiver may not support same set of header 
>>>extensionsSender and receiver may have negotiated a different id for 
>>>same header extension

---

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

Hi Paul

Re: RTX/FEC, yeah I know, IMHO the problem has the same root cause and 
solution, but let's keep that discussion on a separate thread.

Regarding OHB, as a developer, changing meaning of rtp headers depending 
on the relative position of the OHB feels very unfriendly for me, 
specially if I have later have to reconstruct the packet and apply 
padding to keep boundaries. Doesn't seem a clean solution IMHO.

I would really prefer to not touch the header extensions and move the 
OHB to the packet payload, which is were it belongs IMHO (same as OSN in 
normal RTX). That brings another question, which I will open on a new email.

Best regards
Sergio

On 30/03/2017 19:42, Paul E. Jones wrote:
> Sergio,
>
> For RTX and FEC, I wasn't referring to the header extensions, but 
> rather how those are handled in light of "double."
>
> To: "Paul E. Jones" <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> minimum common header extension subsets and getting all clients use 
>> the same extensions with same id. Also, I don't see much value in 
>> having the rtp header extensions E2E, as except the video orientation 
>> one, most of them are meant to be terminated at the MD (except the 
>> video orientation which would just need to be copied by the SFU).
>>
>> transmitted in clear to the MD, and even more, the main purpose of 
>> the rfc6904 for encrypted header extensions was to protect the client 
>> to mixer/mixer to client audio indications, which by definition are 
>> not E2E and required by an SFU to operate.
>>
>> without extensions, and even more, we could use that encoded packet 
>> as the media payload of the outer encryption and forget about OHB 
>> completely and solve the RTX/FEC issue altogether. After all, it 
>> would be just a matter of adding an extra 12 bytes overhead (the full 
>> rtp payload header) vs the current OHB header extension, which could 
>> get also up to those 12 bytes if we need to include ssrc and ts.
>>
>> Best regards
>> Sergio
>>
>>> This was proposed using a single crypto context with an additional 
>>> E2E key.  Another way to have viewed this (which I think is perhaps 
>>> and one for HBH.  The E2E context would have used, for example, 
>>> AES-CM with null authentication and the HBH context would have used 
>>> null encryption and HMAC-SHA1 for authentication.  (Of course, any 
>>> ciphers or auth functions could have been used.)  This would have 
>>> allowed the middlebox to change headers as it saw fit, so long as we 
>>> retained the fields required to re-construct the crypto contexts. 
>>>  However, the need to maintain SSRC and sequence numbers to 
>>> reconstruct the crypto context is where a lot of discussion took 
>>> place that forced some discussion on how we had proposed to do the 
>>> encryption.
>>>
>>> Double addressed the issue of changing certain critical fields, 
>>> while also moving toward authenticated encryption.  There were 
>>> concerns with introducing a new RFC with a split in encryption and 
>>> authentication, so Double addressed those concerns, too.
>>>
>>>  During this meeting, there were also concerns raised with Double 
>>> and how it works with RTX and FEC. Obviously, we need to get that 
>>> right and perhaps those and the RTP header extension concerns you 
>>> raise should both be topics for discussion in an interim meeting 
>>> that the chairs will be arranging.
>>>
>>> Paul
>>>
>>>> If I have understood it (please correct me if I am wrong) the MD 
>>>> must rely all the header extensions present before the OHB to the 
>>>> other peers:
>>>>
>>>> parse the packet correctly, and at best case scenario, it will 
>>>> ignore the header extension.
>>>>

---

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

Sergio,

Moving the OHB to the payload is doable, but perhaps a better solution 
is simply have the endpoint always insert the OHB as the first header 
extension.  We could also pre-populate that with every single value that 
we might ever want to change (i.e., allow it to be a fixed size).  
Having a fixed-size was suggested yesterday in the meeting.  It would 
mean, though, that the header extensions are not E2E authenticated or 
encrypted.  I don't know how important that might be to anyone.

Paul

------ Original Message ------
From: "Sergio Garcia Murillo" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>; [email-masked]
Sent: 3/30/2017 1:54:07 PM
Subject: Re: [Perc] Double Encryption and header extensions issue

>Regarding OHB, as a developer, changing meaning of rtp headers 
>depending on the relative position of the OHB feels very unfriendly for 
>me, specially if I have later have to reconstruct the packet and apply 
>OHB to the packet payload, which is were it belongs IMHO (same as OSN 
>in normal RTX). That brings another question, which I will open on a 
>new email.
>
>Best regards
>Sergio
>
>>>>>extensionsSender and receiver may have negotiated a different id 
>>>>>for same header extension

---

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

One thing I realized is that adding OHB in the payload would mean that 
it is also sent from the sender to the MD, which would be an unnecessary 
overhead.

Regarding encrypted  extensions, I think that the question is even more 
basic, can we have e2e extensions? My view is that it is not possible 
because extensions and ids are negotiated HBH, not E2E.

If we don't (can't) have E2E extensions, there is no reason at all to 
mandate OHB to be at any specific position, and we will not change 
current rtp header extensions, making it much more easy to implement it 
in current products.

Best regards
Sergio

On 30/03/2017 22:20, Paul E. Jones wrote:
> extension.  We could also pre-populate that with every single value 
> that we might ever want to change (i.e., allow it to be a fixed size). 
>> Re: RTX/FEC, yeah I know, IMHO the problem has the same root cause 
>> and solution, but let's keep that discussion on a separate thread.
>>
>> depending on the relative position of the OHB feels very unfriendly 
>> for me, specially if I have later have to reconstruct the packet and 
>> apply padding to keep boundaries. Doesn't seem a clean solution IMHO.
>>
>>> insert the OHB as the first extension and then have all others 
>>> follow it.  That would make all extensions HBH, effectively.
>>>
>>> Paul
>>>
>>>> Maybe I am jumping to the conclusions too fast, but IMHO both 
>>>> RTX/FEC and header extensions should be HBH and not E2E.
>>>>
>>>> having the rtp header extensions E2E, as except the video 
>>>> orientation one, most of them are meant to be terminated at the MD 
>>>> (except the video orientation which would just need to be copied by 
>>>> the SFU).
>>>>
>>>> Also, I don't see any privacy issue doing extensions HBH, as they 
>>>> are transmitted in clear to the MD, and even more, the main purpose 
>>>> of the rfc6904 for encrypted header extensions was to protect the 
>>>> client to mixer/mixer to client audio indications, which by 
>>>> definition are not E2E and required by an SFU to operate.
>>>>
>>>> would be just a matter of adding an extra 12 bytes overhead (the 
>>>> full rtp payload header) vs the current OHB header extension, which 
>>>> could get also up to those 12 bytes if we need to include ssrc and ts.
>>>>
>>>> Best regards
>>>> Sergio
>>>>
>>>>> original proposal for PERC (that we called "PRIME"), the RTP 
>>>>> payload itself was encrypted using an E2E key, but the headers 
>>>>> only authenticated with a HBH key.  That draft was this:
>>>>> E2E key.  Another way to have viewed this (which I think is 
>>>>> perhaps easiest to comprehend) is that there were two contexts, 
>>>>> one for E2E and one for HBH.  The E2E context would have used, for 
>>>>> example, AES-CM with null authentication and the HBH context would 
>>>>> have used null encryption and HMAC-SHA1 for authentication.  (Of 
>>>>> course, any ciphers or auth functions could have been used.)  This 
>>>>> would have allowed the middlebox to change headers as it saw fit, 
>>>>> so long as we retained the fields required to re-construct the 
>>>>> crypto contexts.  However, the need to maintain SSRC and sequence 
>>>>> numbers to reconstruct the crypto context is where a lot of 
>>>>> discussion took place that forced some discussion on how we had 
>>>>> proposed to do the encryption.
>>>>>
>>>>> problem.  I've not spent much time thinking about how to solve 
>>>>> that.  During this meeting, there were also concerns raised with 
>>>>> Double and how it works with RTX and FEC. Obviously, we need to 
>>>>> get that right and perhaps those and the RTP header extension 
>>>>> concerns you raise should both be topics for discussion in an 
>>>>> interim meeting that the chairs will be arranging.
>>>>>
>>>>> Paul
>>>>>
>>>>>> I have been reviewing the documentation for double encryption and 
>>>>>> I have serious doubts about how the header extensions are handled.
>>>>>>
>>>>>> This is an obvious requirement, as to be able to decrypt the 
>>>>>> inner crypto, the end receiver must have the same original rtp 
>>>>>> packet, which includes header extensions.
>>>>>>
>>>>>>   * Sender and receiver may have negotiated a different id for
>>>>>>     same header extension
>>>>>>
>>>>>> In any of the previous scenarios, the receiver will not be able 
>>>>>> to parse the packet correctly, and at best case scenario, it will

---

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

Sergio,

Yeah, all of these are valid points. Likely, none should be E2E 
extensions, but that would mean that the OHB will always be first in the 
packet the way things are presently defined, since HBH extensions are 
added after the OHB.

Perhaps others can suggest when/why we might need E2E RTP header 
extensions.

Paul

------ Original Message ------
From: "Sergio Garcia Murillo" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>; [email-masked]
Sent: 3/30/2017 4:29:08 PM
Subject: Re: [Perc] Double Encryption and header extensions issue

>it is also sent from the sender to the MD, which would be an 
>unnecessary overhead.
>
>>>>>>>The Media Distributor MUST NOT delete any header extensions 
>>>>>>>before the OHB, but MAY add, delete, or modify any that follow 
>>>>>>>the OHB. This is an obvious requirement, as to be able to decrypt 
>>>>>>>the inner crypto, the end receiver must have the same original 
>>>>>>>rtp packet, which includes header extensions.
>>>>>>>

---

From: Nils Ohlmeier <[email-masked]>
Date: Thu, 30 Mar 2017 18:09:56 -0500

Hi,

To me it sounds like we should as the next step look at all header extensions to analyze and write down if they are HBH or E2E. And if they are E2E if they need to be protected against modification by the MD.

Best
  Nils

> On Mar 30, 2017, at 17:54, Paul E. Jones <[email-masked]> wrote:
> 
> Sergio,
> 
> Yeah, all of these are valid points. Likely, none should be E2E extensions, but that would mean that the OHB will always be first in the packet the way things are presently defined, since HBH extensions are added after the OHB.
> 
> Perhaps others can suggest when/why we might need E2E RTP header extensions.
> 
> Paul
> 
> From: "Sergio Garcia Murillo" <[email-masked] <mailto:[email-masked]>>
> To: "Paul E. Jones" <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> One thing I realized is that adding OHB in the payload would mean that it is also sent from the sender to the MD, which would be an unnecessary overhead.
>> 
>> Regarding encrypted  extensions, I think that the question is even more basic, can we have e2e extensions? My view is that it is not possible because extensions and ids are negotiated HBH, not E2E.
>> 
>> If we don't (can't) have E2E extensions, there is no reason at all to mandate OHB to be at any specific position, and we will not change current rtp header extensions, making it much more easy to implement it in current products.
>> 
>> Best regards
>> Sergio
>> 
>>> Moving the OHB to the payload is doable, but perhaps a better solution is simply have the endpoint always insert the OHB as the first header extension.  We could also pre-populate that with every single value that we might ever want to change (i.e., allow it to be a fixed size).  Having a fixed-size was suggested yesterday in the meeting.  It would mean, though, that the header extensions are not E2E authenticated or encrypted.  I don't know how important that might be to anyone.
>>> 
>>> Paul
>>> 
>>> From: "Sergio Garcia Murillo" <[email-masked] <mailto:[email-masked]>>
>>> To: "Paul E. Jones" <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>>>> Re: RTX/FEC, yeah I know, IMHO the problem has the same root cause and solution, but let's keep that discussion on a separate thread.
>>>> 
>>>> Regarding OHB, as a developer, changing meaning of rtp headers depending on the relative position of the OHB feels very unfriendly for me, specially if I have later have to reconstruct the packet and apply padding to keep boundaries. Doesn't seem a clean solution IMHO.
>>>> 
>>>> I would really prefer to not touch the header extensions and move the OHB to the packet payload, which is were it belongs IMHO (same as OSN in normal RTX). That brings another question, which I will open on a new email.
>>>> 
>>>> Best regards
>>>> Sergio
>>>> 
>>>>> For RTX and FEC, I wasn't referring to the header extensions, but rather how those are handled in light of "double."
>>>>> 
>>>>> What you suggest is certainly possible.  We could have the endpoints insert the OHB as the first extension and then have all others follow it.  That would make all extensions HBH, effectively.
>>>>> 
>>>>> Paul
>>>>> 
>>>>> From: "Sergio Garcia Murillo" <[email-masked] <mailto:[email-masked]>>
>>>>> To: "Paul E. Jones" <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>>>>>> Maybe I am jumping to the conclusions too fast, but IMHO both RTX/FEC and header extensions should be HBH and not E2E.
>>>>>> 
>>>>>> For header extensions I don't see a feasible way of negotiating the minimum common header extension subsets and getting all clients use the same extensions with same id. Also, I don't see much value in having the rtp header extensions E2E, as except the video orientation one, most of them are meant to be terminated at the MD (except the video orientation which would just need to be copied by the SFU).
>>>>>> 
>>>>>> Also, I don't see any privacy issue doing extensions HBH, as they are transmitted in clear to the MD, and even more, the main purpose of the rfc6904 for encrypted header extensions was to protect the client to mixer/mixer to client audio indications, which by definition are not E2E and required by an SFU to operate.
>>>>>> 
>>>>>> So IMHO, the inner encryption should be done on a "cloned" packet without extensions, and even more, we could use that encoded packet as the media payload of the outer encryption and forget about OHB completely and solve the RTX/FEC issue altogether. After all, it would be just a matter of adding an extra 12 bytes overhead (the full rtp payload header) vs the current OHB header extension, which could get also up to those 12 bytes if we need to include ssrc and ts.
>>>>>> 
>>>>>> Best regards
>>>>>> Sergio
>>>>>> 
>>>>>>> Your interpretation is correct, I think.  When we submitted the original proposal for PERC (that we called "PRIME"), the RTP payload itself was encrypted using an E2E key, but the headers only authenticated with a HBH key.  That draft was this:
>>>>>>> https://tools.ietf.org/html/draft-jones-avtcore-private-media-framework-00 <https://tools.ietf.org/html/draft-jones-avtcore-private-media-framework-00>
>>>>>>> 
>>>>>>> This was proposed using a single crypto context with an additional E2E key.  Another way to have viewed this (which I think is perhaps easiest to comprehend) is that there were two contexts, one for E2E and one for HBH.  The E2E context would have used, for example, AES-CM with null authentication and the HBH context would have used null encryption and HMAC-SHA1 for authentication.  (Of course, any ciphers or auth functions could have been used.)  This would have allowed the middlebox to change headers as it saw fit, so long as we retained the fields required to re-construct the crypto contexts.  However, the need to maintain SSRC and sequence numbers to reconstruct the crypto context is where a lot of discussion took place that forced some discussion on how we had proposed to do the encryption.
>>>>>>> 
>>>>>>> Double addressed the issue of changing certain critical fields, while also moving toward authenticated encryption.  There were concerns with introducing a new RFC with a split in encryption and authentication, so Double addressed those concerns, too.
>>>>>>> 
>>>>>>> However, you're right that the negotiated values might present a problem.  I've not spent much time thinking about how to solve that.  During this meeting, there were also concerns raised with Double and how it works with RTX and FEC. Obviously, we need to get that right and perhaps those and the RTP header extension concerns you raise should both be topics for discussion in an interim meeting that the chairs will be arranging.
>>>>>>> 
>>>>>>> Paul
>>>>>>> 
>>>>>>> From: "Sergio Garcia Murillo" <[email-masked] <mailto:[email-masked]>>
>>>>>>>> I have been reviewing the documentation for double encryption and I have serious doubts about how the header extensions are handled.
>>>>>>>> 
>>>>>>>> If I have understood it (please correct me if I am wrong) the MD must rely all the header extensions present before the OHB to the other peers:
>>>>>>>> 
>>>>>>>> This is an obvious requirement, as to be able to decrypt the inner crypto, the end receiver must have the same original rtp packet, which includes header extensions.
>>>>>>>> 
>>>>>>>> Sender and receiver may not support same set of header extensions
>>>>>>>> Sender and receiver may have negotiated a different id for same header extension
>>>>>>>> In any of the previous scenarios, the receiver will not be able to parse the packet correctly, and at best case scenario, it will ignore the header extension.
>>>>>>>> 
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc

---

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

I agree

Best regards
Sergio
On 31/03/2017 1:09, Nils Ohlmeier wrote:
> Hi,
>
> To me it sounds like we should as the next step look at all header 
> extensions to analyze and write down if they are HBH or E2E. And if 
> they are E2E if they need to be protected against modification by the MD.
>
> Best
>   Nils
>
>> On Mar 30, 2017, at 17:54, Paul E. Jones <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Sergio,
>>
>> extensions, but that would mean that the OHB will always be first in 
>> the packet the way things are presently defined, since HBH extensions 
>> are added after the OHB.
>>
>> <mailto:[email-masked]>>;[email-masked] <mailto:[email-masked]>
>>> One thing I realized is that adding OHB in the payload would mean 
>>> that it is also sent from the sender to the MD, which would be an 
>>> unnecessary overhead.
>>>
>>> Regarding encrypted  extensions, I think that the question is even 
>>> more basic, can we have e2e extensions? My view is that it is not 
>>> possible because extensions and ids are negotiated HBH, not E2E.
>>>
>>> If we don't (can't) have E2E extensions, there is no reason at all 
>>> to mandate OHB to be at any specific position, and we will not 
>>> change current rtp header extensions, making it much more easy to 
>>> implement it in current products.
>>>
>>> Best regards
>>> Sergio
>>>
>>>> Moving the OHB to the payload is doable, but perhaps a better 
>>>> solution is simply have the endpoint always insert the OHB as the 
>>>> first header extension.  We could also pre-populate that with every 
>>>> single value that we might ever want to change (i.e., allow it to 
>>>> be a fixed size).  Having a fixed-size was suggested yesterday in 
>>>> the meeting.  It would mean, though, that the header extensions are 
>>>> not E2E authenticated or encrypted.  I don't know how important 
>>>> that might be to anyone.
>>>>
>>>> Paul
>>>>
>>>> <mailto:[email-masked]>>;[email-masked] <mailto:[email-masked]>
>>>>> depending on the relative position of the OHB feels very 
>>>>> unfriendly for me, specially if I have later have to reconstruct 
>>>>> the packet and apply padding to keep boundaries. Doesn't seem a 
>>>>> clean solution IMHO.
>>>>>
>>>>> I would really prefer to not touch the header extensions and move 
>>>>> the OHB to the packet payload, which is were it belongs IMHO (same 
>>>>> as OSN in normal RTX). That brings another question, which I will 
>>>>> open on a new email.
>>>>>
>>>>> Best regards
>>>>> Sergio
>>>>>
>>>>>> What you suggest is certainly possible.  We could have the 
>>>>>> endpoints insert the OHB as the first extension and then have all 
>>>>>> others follow it.  That would make all extensions HBH, effectively.
>>>>>>
>>>>>> Paul
>>>>>>
>>>>>> <mailto:[email-masked]>>;[email-masked] <mailto:[email-masked]>
>>>>>>> For header extensions I don't see a feasible way of negotiating 
>>>>>>> the minimum common header extension subsets and getting all 
>>>>>>> clients use the same extensions with same id. Also, I don't see 
>>>>>>> much value in having the rtp header extensions E2E, as except 
>>>>>>> the video orientation one, most of them are meant to be 
>>>>>>> terminated at the MD (except the video orientation which would 
>>>>>>> just need to be copied by the SFU).
>>>>>>>
>>>>>>> Also, I don't see any privacy issue doing extensions HBH, as 
>>>>>>> they are transmitted in clear to the MD, and even more, the main 
>>>>>>> purpose of the rfc6904 for encrypted header extensions was to 
>>>>>>> protect the client to mixer/mixer to client audio indications, 
>>>>>>> which by definition are not E2E and required by an SFU to operate.
>>>>>>>
>>>>>>> So IMHO, the inner encryption should be done on a "cloned" 
>>>>>>> packet without extensions, and even more, we could use that 
>>>>>>> encoded packet as the media payload of the outer encryption and 
>>>>>>> forget about OHB completely and solve the RTX/FEC issue 
>>>>>>> altogether. After all, it would be just a matter of adding an 
>>>>>>> extra 12 bytes overhead (the full rtp payload header) vs the 
>>>>>>> current OHB header extension, which could get also up to those 
>>>>>>> 12 bytes if we need to include ssrc and ts.
>>>>>>>
>>>>>>> Best regards
>>>>>>> Sergio
>>>>>>>
>>>>>>>> This was proposed using a single crypto context with an 
>>>>>>>> additional E2E key.  Another way to have viewed this (which I 
>>>>>>>> think is perhaps easiest to comprehend) is that there were two 
>>>>>>>> contexts, one for E2E and one for HBH.  The E2E context would 
>>>>>>>> have used, for example, AES-CM with null authentication and the 
>>>>>>>> HBH context would have used null encryption and HMAC-SHA1 for 
>>>>>>>> authentication.  (Of course, any ciphers or auth functions 
>>>>>>>> could have been used.)  This would have allowed the middlebox 
>>>>>>>> to change headers as it saw fit, so long as we retained the 
>>>>>>>> fields required to re-construct the crypto contexts.  However, 
>>>>>>>> the need to maintain SSRC and sequence numbers to reconstruct 
>>>>>>>> the crypto context is where a lot of discussion took place that 
>>>>>>>> forced some discussion on how we had proposed to do the encryption.
>>>>>>>>
>>>>>>>> concerns with introducing a new RFC with a split in encryption 
>>>>>>>> and authentication, so Double addressed those concerns, too.
>>>>>>>>
>>>>>>>> However, you're right that the negotiated values might present 
>>>>>>>> a problem.  I've not spent much time thinking about how to 
>>>>>>>> solve that.  During this meeting, there were also concerns 
>>>>>>>> raised with Double and how it works with RTX and FEC. 
>>>>>>>> Obviously, we need to get that right and perhaps those and the 
>>>>>>>> RTP header extension concerns you raise should both be topics 
>>>>>>>> for discussion in an interim meeting that the chairs will be 
>>>>>>>> arranging.
>>>>>>>>
>>>>>>>> Paul
>>>>>>>>
>>>>>>>> To:[email-masked] <mailto:[email-masked]>
>>>>>>>>> I have been reviewing the documentation for double encryption 
>>>>>>>>> and I have serious doubts about how the header extensions are 
>>>>>>>>> handled.
>>>>>>>>>
>>>>>>>>> If I have understood it (please correct me if I am wrong) the 
>>>>>>>>> MD must rely all the header extensions present before the OHB 
>>>>>>>>> to the other peers:
>>>>>>>>>
>>>>>>>>> In any of the previous scenarios, the receiver will not be 
>>>>>>>>> able to parse the packet correctly, and at best case scenario, 
>>>>>>>>> it will ignore the header extension.
>>>>>>>>>
>> [email-masked] <mailto:[email-masked]>