Subject: Re: [Perc] Double Encryption and header extensions issue

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

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

Totally agree - the good news is we have done that and had multiple WG calls on that.

---

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

> On Mar 30, 2017, at 9:16 AM, Sergio Garcia Murillo <[email-masked]> wrote:
> 
> 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.
> 

Which header extensions are in use is negotiated in the SDP.  The conferencing software need to ensure that it only negotiates header extensions such that any device receiving them can process them.

---

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

> Which header extensions are in use is negotiated in the SDP.  The conferencing software need to ensure that it only negotiates header extensions such that any device receiving them can process them.

I don't think it is even viable to implement that:

  * Extensions ids are set by the offerer, so even if a new participant
    has same set of extensions than the conference, it may use different
    ids. This will require the SFU to renegotiate afterwards to set the
    ids to the "common ones" (not sure if it is even possible)
  * With current approach, there are extensions that ar HBH and ones
    that are E2E, but the usage intention is only known by the sender,
    so in the SDP the SFU will not be able to know which are meant to be
    HBH and which ones are E2E, so it will have to restrict them even if
    they are meant to be used HBH (like transport-wide-cc)
  * What would happen when a new participant joins and it does not
    support an extension of common set? Will the SFU have to renegotiate
    will all the participants to remove it or send it to the participant
    anyway? If the later, what is the meaning of having a common set of
    extensions anyway?

Really, I don't see any use case for E2E extensions and the 
implementation seems horrible to me.

Best regards

Sergio

---

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

On 01/04/2017 21:34, Sergio Garcia Murillo wrote:
>>> On Mar 30, 2017, at 9:16 AM, Sergio Garcia Murillo<[email-masked]>  wrote:
>>>
>   * Extensions ids are set by the offerer, so even if a new
>     participant has same set of extensions than the conference, it may
>     use different ids. This will require the SFU to renegotiate
>     afterwards to set the ids to the "common ones" (not sure if it is
>     even possible)
>     so in the SDP the SFU will not be able to know which are meant to
>     be HBH and which ones are E2E, so it will have to restrict them
>     even if they are meant to be used HBH (like transport-wide-cc)
>     support an extension of common set? Will the SFU have to
>     renegotiate will all the participants to remove it or send it to
>     the participant anyway? If the later, what is the meaning of
>     having a common set of extensions anyway?
>

Another issue, what happens when the sender wants to use a HBH header 
extension? currently the only differentiation between the HBH extensions 
and the E2E extensions are based on their relative position to the OHB 
header, which AFAIK is only set by the MD.

So all extensions sent from the sender are E2E, which doesn't make sense 
at all. What happens if the sender needs to use a HBH extension, as the 
transport-wide-cc ones, and then the MD needs to set them also in order 
to make GCC work correctly?

The packet sent from the MD to the receiver will have a duplicated set 
of extension values for the same id, one before the OHB, which is 
useless, and another one after the OHB which is the one meant to be used.

Best regards
Sergio

---

From: Nils Ohlmeier <[email-masked]>
Date: Sat, 1 Apr 2017 14:35:57 -0700

> On Apr 1, 2017, at 12:50, Sergio Garcia Murillo <[email-masked]> wrote:
> 
>>>> On Mar 30, 2017, at 9:16 AM, Sergio Garcia Murillo <[email-masked]> <mailto:[email-masked]> wrote:
>>>> 
>> Extensions ids are set by the offerer, so even if a new participant has same set of extensions than the conference, it may use different ids. This will require the SFU to renegotiate afterwards to set the ids to the "common ones" (not sure if it is even possible)
>> With current approach, there are extensions that ar HBH and ones that are E2E, but the usage intention is only known by the sender, so in the SDP the SFU will not be able to know which are meant to be HBH and which ones are E2E, so it will have to restrict them even if they are meant to be used HBH (like transport-wide-cc)
>> What would happen when a new participant joins and it does not support an extension of common set? Will the SFU have to renegotiate will all the participants to remove it or send it to the participant anyway? If the later, what is the meaning of having a common set of extensions anyway?
>> Really, I don't see any use case for E2E extensions and the implementation seems horrible to me.
> 
> Another issue, what happens when the sender wants to use a HBH header extension? currently the only differentiation between the HBH extensions and the E2E extensions are based on their relative position to the OHB header, which AFAIK is only set by the MD.

That is a concept which I mis-understood initially as well. The OHB can also be set by the originating client. And yes using the OHB as the marker between HBH and E2E header extensions is kind of ugly. Especially as probably most software out there today has no concept of inserting header extensions in a particular order.

I tend to think that the originating client should always insert the OHB just to make things easier. This way the originating client no longer needs to differentiate if it needs to insert the OHB only if uses HBH and E2E extension, it will always set the OHB for all double encrypted streams. Thus you might also use the OHB as kind of marker to differentiate double encrypted streams from single encrypted once.
And the receiver part of the MD would also become less complex as it can rely on the fact that an OHB needs to be present.

> So all extensions sent from the sender are E2E, which doesn't make sense at all. What happens if the sender needs to use a HBH extension, as the transport-wide-cc ones, and then the MD needs to set them also in order to make GCC work correctly?
> 
> The packet sent from the MD to the receiver will have a duplicated set of extension values for the same id, one before the OHB, which is useless, and another one after the OHB which is the one meant to be used.

Since transport-wide-cc applies to a transport only, I would assume that transport-wide-cc is HBH only. So the originating client inserts it after its OHB header extension. MD removes the transport-wide-cc, since the transport to the receiver is a different transport. And the MD inserts its own transport-wide-cc after the OHB again.

Best
  Nils Ohlmeier

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sun, 2 Apr 2017 00:09:45 +0200

On 01/04/2017 23:35, Nils Ohlmeier wrote:
> I tend to think that the originating client should always insert the 
> OHB just to make things easier. This way the originating client no 
> longer needs to differentiate if it needs to insert the OHB only if 
> uses HBH and E2E extension, it will always set the OHB for all double 
> encrypted streams. Thus you might also use the OHB as kind of marker 
> to differentiate double encrypted streams from single encrypted once.
> And the receiver part of the MD would also become less complex as it 
> can rely on the fact that an OHB needs to be present.

If sender is going to send the OHB data required to decrypt the payload, 
i think it would be a better idea to include it on the payload (and 
remove the E2E extensions completely). That would make it trivial to 
implement double-ecryption on the MD (in fact, you will need to do nothing).

That way, the payload could be used in other scenarios, for example, 
recordings or to broadcast the conference via mpeg-dash in conjunction 
with W3C media source extensions/encrypted media extensions by anyone 
knowing the inner key/salt.

Best regards
Sergio

---

From: Boris Grozev <[email-masked]>
Date: Sat, 01 Apr 2017 21:39:40 +0000

On Sat, Apr 1, 2017 at 3:50 PM Sergio Garcia Murillo <
[email-masked]> wrote:

> On Mar 30, 2017, at 9:16 AM, Sergio Garcia Murillo <[email-masked]> <[email-masked]> wrote:
>
>    - Extensions ids are set by the offerer, so even if a new participant
>    has same set of extensions than the conference, it may use different ids.
>    This will require the SFU to renegotiate afterwards to set the ids to the
>    "common ones" (not sure if it is even possible)
>    - With current approach, there are extensions that ar HBH and ones
>    that are E2E, but the usage intention is only known by the sender, so in
>    the SDP the SFU will not be able to know which are meant to be HBH and
>    which ones are E2E, so it will have to restrict them even if they are meant
>    to be used HBH (like transport-wide-cc)
>    - What would happen when a new participant joins and it does not
>    support an extension of common set? Will the SFU have to renegotiate will
>    all the participants to remove it or send it to the participant anyway? If
>    the later, what is the meaning of having a common set of extensions anyway?
>
> transport-wide-cc ones, and then the MD needs to set them also in order to
> make GCC work correctly?
>

My understanding is that in this case the sender would insert an OHB
followed by a transport-cc extension. The MD would then be able to modify
and/or remove the transport-cc extension.

Boris

>
> The packet sent from the MD to the receiver will have a duplicated set of
> extension values for the same id, one before the OHB, which is useless, and
> another one after the OHB which is the one meant to be used.
>
> Best regards
>
> Sergio
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc
>

---

From: Emil Ivov <[email-masked]>
Date: Mon, 3 Apr 2017 09:09:21 -0500

> Totally agree - the good news is we have done that and had multiple WG calls on that.

It would be helpful if, when making claims like this, you could back
them up with links to the ML archive.

In this case specifically, we obviously haven't done a great job
analysing the problem, since we have no solutions to the issues Sergio
is raising.

Emil

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Mon, 3 Apr 2017 09:25:26 -0500

> Which header extensions are in use is negotiated in the SDP.  The conferencing software need to ensure that it only negotiates header extensions such that any device receiving them can process them.

Great idea! Only problem is that Offer/Answer doesn't allow said
conferencing software to guarantee consistent use of extension IDs
across the entire call.

Even without that, asserting use of the same extension across the
entire conference would be  rather painful as it would mean that
non-supporting clients would either need to be left out, or supporting
clients may have to be forced to turn them off at any time. Is this
worth the trouble?

What is the downside of having all extensions be HBH as per Sergio's proposal?

Emil

-- 
https://jitsi.org