Re: [AVTCORE] [Cryptex] PR for recommending Cryptex over RFC 6904

Thank you Bernard and Jonathan!

I have incorporated the changes in the PR
https://github.com/juberti/cryptex/pull/111/files

I will review tomorrow the current draft tomorrow and publish a new version.

Best regards
Sergio

On Wed, Aug 3, 2022 at 7:58 PM Jonathan Lennox <jonathan.lennox@8x8.com>
wrote:

> A slight wordsmithing:
>
> If one of the peers has advertised both the ability to receive cryptex and
> the ability to receive header extensions encrypted as per {{RFC6904}} in
> the SDP exchange, it is RECOMMENDED for the other peer to use Cryptex *rather
> than* {{RFC6904}} when sending RTP packets so all the header extensions
> and CSRCS are encrypted unless there is a compelling reason to use
> {{RFC6904}} (e.g. *a* need for some header extensions to be sent in the
> clear so that so they are processable by RTP middleboxes) in which case, it
> SHOULD use {{RFC6904}} instead.
>
> I’ve changed “over” to “rather than”; I feel like “over” could be
> interpreted as applying Cryptex encryption to the 6904 headers, which is
> clearly not what is intended.
>
> I’ve also added “a” to the beginning of the parenthetical phrase, for
> grammar reasons.
>
> On Aug 3, 2022, at 9:33 AM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
>
> Looks good to me.
>
> On Aug 2, 2022, at 23:29, Sergio Garcia Murillo <
> sergio.garcia.murillo@gmail.com> wrote:
>
> 
> How about this:
>
> If one of the peers has advertised both the ability to receive cryptex and
> the ability to receive header extensions encrypted as per {{RFC6904}} in
> the SDP exchange, it is RECOMMENDED for the other peer to use Cryptex over
> {{RFC6904}} when sending RTP packets so all the header extensions and CSRCS
> are encrypted unless there is a compelling reason to use {{RFC6904}} (e.g.
> need for some header extensions to be sent in the clear so that so they are
> processable by RTP middleboxes) in which case, it SHOULD use {{RFC6904}}
> instead.
>
> I don't think we should add the note about checking that the header
> extensions can be actually sent in clear, as we have put that reason as an
> example.
>
> What do you think?
> Sergio
>
> On Tue, Aug 2, 2022 at 6:30 PM Bernard Aboba <bernard.aboba@gmail.com>
> wrote:
>
>> The wording is a bit confusing, because both the Offerer and Answerer can
>> be "sender and receiver" in this context.
>>
>> You are trying to give guidance on what a peer should send where the
>> other peer has advertised both the ability to receive cryptex and the
>> ability to receive header extensions encrypted as per RFC 6904.
>>
>> The guidance is to send cryptex unless there is a compelling reason to
>> send RFC 6904 (e.g. need for some header extensions in the clear).
>> However, this only makes sense if the header extensions to be sent in the
>> clear can actually be sent (e.g. if they are sendonly or sendrecv on the
>> sending peer and recvonly or sendrecv on the receiving peer).
>>
>> On Tue, Aug 2, 2022 at 2:44 AM Sergio Garcia Murillo <
>> sergio.garcia.murillo@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> As discussed during the last AVTCORE meeting, I have prepared a PR for
>>> adding the recommendation of using Cryptex over RFC6904 adding an exception
>>> in the case of some of the header extensions should be sent in clear for
>>> RTP middleboxes processing:
>>>
>>> If both Cryptex and the Encryption of Header Extensions mechanism
>>> defined in {{RFC6904}} are supported by both the sender and receiver, it is
>>> RECOMMENDED to use Cryptex over {{RFC6904}} so all the header extensions
>>> and CSRCS are encrypted, except when some of the header extensions should
>>> be sent in clear so they are processable by RTP middleboxes, in which case,
>>> it SHOULD use {{RFC6904}} instead.
>>>
>>> https://github.com/juberti/cryptex/pull/111
>>>
>>> Would be great if someone could review the wording as I think it could
>>> be simplified.
>>>
>>> I will be on vacation from next week, so I will merge the PR and submit
>>> a final draft by the end of this week if I don't receive any further
>>> feedback on the draft.
>>>
>>> Best regards
>>> Sergio
>>> _______________________________________________
>>> Audio/Video Transport Core Maintenance
>>> avt@ietf.org
>>> https://www.ietf.org/mailman/listinfo/avt
>>>
>> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>
>
>