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

Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> Wed, 03 August 2022 18:45 UTC

Return-Path: <sergio.garcia.murillo@gmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB75FC14F73D for <avt@ietfa.amsl.com>; Wed, 3 Aug 2022 11:45:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6pNaw_ToL9Y for <avt@ietfa.amsl.com>; Wed, 3 Aug 2022 11:45:54 -0700 (PDT)
Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D89FC14F735 for <avt@ietf.org>; Wed, 3 Aug 2022 11:45:54 -0700 (PDT)
Received: by mail-pg1-x533.google.com with SMTP id i71so10360365pge.9 for <avt@ietf.org>; Wed, 03 Aug 2022 11:45:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=1QByWTnb67BKEd57/RFdktwYxY/SV72Ct1OFsZzUvkE=; b=P0A7aCedxwUDVsp4fTgthTL71rt68JvbidInNqcwjEqbU902uSS6bVIHSWaaefdmGx v0QWV85dz985td4jWHNZ2glnZLtMv1g/fTAIN5vUXdh5Hk/fmh4Yu7qc+Oo1cGpWyFG1 GLdtgUhGsUKHEpcrNWqpqZIbD5Z2UQq5M97indh8sJsE0g8EHa+l/mULHqcqkkD1mgJV F5iDLoI03iuvLBTIcAQXagGlInnNyqJwBwnHzPkHOTAND1wyuVbLCqnm9P3vRcfxDNnx WpdogdnBaPdsqdN7zZ8hBjzOg50J55ylzJAIk1xoBkJK25fPmKyTmeCigrYJNdVKK9Ix MqJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=1QByWTnb67BKEd57/RFdktwYxY/SV72Ct1OFsZzUvkE=; b=dkn2ibc+6s/gsZc5m1htFbrA1vY8EvLzjgHqs0daJyPts62pWNyUJ8FNP946tWikTV HLhiwAEFbtm2XOiHaRpGtUwESnSGzZ13yNfD+stRogUPgFWQ9JqgPqINBfXwpaKoOlr7 lI7iu6oez8CDHE5tRfSjqGX4qhQ9tUdcacoQnTFUEQmB0uXSZwEDhdNO9IuotHMFcqyR NBdiyXpZudte7P1AG42vPvHQzvvcuUtnrGFQ24OPHNK3FCN5+ZDJD/yiT+lgI9qB39q8 A6DAch6qpTvCJUMeWTvyB6QQPQ+N0AlA0p5xOUv5fpPXSGRVx06Y4ws38fUSCWBwbpaQ 9rdw==
X-Gm-Message-State: AJIora9Q/8ugoAWq3/tJUJjXsCnYzjvM41+Od14OcAx4lQ1TUZC4c0C0 owS1wtv4ey9qiFNofs4x8v9hkrJIemqwvAbFX/k=
X-Google-Smtp-Source: AGRyM1sNDA0Lecif0sqfQIyldDhEUOgvAMMZkCyV3bMe2iPW72mQnFqBObOLey7MDSyniZnIeYVH3+pGMJ+9R0nIgHE=
X-Received: by 2002:a05:6a00:e8f:b0:528:a1c7:3d00 with SMTP id bo15-20020a056a000e8f00b00528a1c73d00mr26298637pfb.25.1659552353449; Wed, 03 Aug 2022 11:45:53 -0700 (PDT)
MIME-Version: 1.0
References: <CA+ag07a-W+=9pYazTyS73SD3NMWqG5w23PP2Ky1uNg9RB00LSg@mail.gmail.com> <A344C43C-380B-46FE-B52E-F97E01B7BA51@gmail.com> <7986304B-0A36-4B12-8A90-7CB80D2DD0CB@8x8.com>
In-Reply-To: <7986304B-0A36-4B12-8A90-7CB80D2DD0CB@8x8.com>
From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Date: Wed, 3 Aug 2022 20:45:42 +0200
Message-ID: <CA+ag07Y1LNBLkR7MNW1MLcB_dQCiSboeir-tJg=9Uj+fon-uuQ@mail.gmail.com>
To: Jonathan Lennox <jonathan.lennox@8x8.com>
Cc: Bernard Aboba <bernard.aboba@gmail.com>, IETF AVTCore WG <avt@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000837afa05e55aa4b8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/igIpiliMNjLvSlXrsSLBMoGadR0>
Subject: Re: [AVTCORE] [Cryptex] PR for recommending Cryptex over RFC 6904
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Aug 2022 18:45:56 -0000

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