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

Jonathan Lennox <jonathan.lennox@8x8.com> Wed, 03 August 2022 17:58 UTC

Return-Path: <jonathan.lennox@8x8.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 EBD9EC14CF1E for <avt@ietfa.amsl.com>; Wed, 3 Aug 2022 10:58:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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, 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 (1024-bit key) header.d=8x8.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 6lpcgGWWZY7l for <avt@ietfa.amsl.com>; Wed, 3 Aug 2022 10:58:43 -0700 (PDT)
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 C84B6C14CF06 for <avt@ietf.org>; Wed, 3 Aug 2022 10:58:43 -0700 (PDT)
Received: by mail-qk1-x731.google.com with SMTP id f14so13394583qkm.0 for <avt@ietf.org>; Wed, 03 Aug 2022 10:58:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=8x8.com; s=googlemail; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc; bh=+QLHy2K3y5VngSWx49zio9zN3dpIaZxuldG+vgrz+EU=; b=ccq4oQkvr9ZFQIVcdnKG0V5TK4/PeOjC4W54X1/z8kqa1BULMdxzlpB5rmIRFzcvGF ZJZ3BLMvGmzIQ84P/cgqwph22Mut7f864v/y3xWuCaDndmFsc1Wnt1GveIuFhgNZxlMK PulydYEq5+1paXbf/nx3KGnSyZ/jTMju9SKHM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc; bh=+QLHy2K3y5VngSWx49zio9zN3dpIaZxuldG+vgrz+EU=; b=jGjcLR58UXmq4pkgBpHVlYJQ6798VL/cAu0h53ReuqjAMZFfAq52f5+smj2peUljgH b0fKbHxUY3z0IqzwjLXclXFnvtSVN1ObWl7r4sbP76DiN8sEwXQ5wOyBJcp53pZ4LXts rqF0o1+3yOu2wMxqw/8c0hb1f4A949/yBlICNpNGYVc4i7he3ecO308QBKdN+jChudia emUWUfOrctnLkzRXCOzh7Cuy2yRc8BSkGSykdGmZSo3LE6H9Rxv+TC9a396bMAtmM6n+ Z5L+MVPaITFFsDT3iTaAgWtmbdO29xK9A18NX3GwAYlJxnCszdfdH2bHoTKX3GjzSlAo BMGg==
X-Gm-Message-State: AJIora9mcBuD1z2yhcMZn/l9IqZwQlvS+paIci85TKL7i6v5PL2vG/tY XMq0kngnSJF++fCERxFHY3yLpXGRsMCZCQ==
X-Google-Smtp-Source: AGRyM1v+DhreImI9db/yX0X3Q2Nh8T351SwAiwPjrmKpUoQ1HEY3mkodPlRI48LBMcDx/fQIgtdtrA==
X-Received: by 2002:a05:620a:1919:b0:6b5:e309:bc15 with SMTP id bj25-20020a05620a191900b006b5e309bc15mr18613932qkb.404.1659549522728; Wed, 03 Aug 2022 10:58:42 -0700 (PDT)
Received: from smtpclient.apple ([2601:86:101:11e0:81e6:be92:21a1:a64f]) by smtp.gmail.com with ESMTPSA id q18-20020a37f712000000b006b5df4d2c81sm12477261qkj.94.2022.08.03.10.58.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Aug 2022 10:58:42 -0700 (PDT)
From: Jonathan Lennox <jonathan.lennox@8x8.com>
Message-Id: <7986304B-0A36-4B12-8A90-7CB80D2DD0CB@8x8.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_93F817B8-5F2D-44CA-9866-F1D4138FB652"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Date: Wed, 3 Aug 2022 13:58:41 -0400
In-Reply-To: <A344C43C-380B-46FE-B52E-F97E01B7BA51@gmail.com>
Cc: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, IETF AVTCore WG <avt@ietf.org>
To: Bernard Aboba <bernard.aboba@gmail.com>
References: <CA+ag07a-W+=9pYazTyS73SD3NMWqG5w23PP2Ky1uNg9RB00LSg@mail.gmail.com> <A344C43C-380B-46FE-B52E-F97E01B7BA51@gmail.com>
X-Mailer: Apple Mail (2.3696.100.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/GPVdzN-aVhnDqB--CU1vijugVAg>
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 17:58:48 -0000

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 <mailto: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 <mailto: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 <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 <mailto:avt@ietf.org>
>> https://www.ietf.org/mailman/listinfo/avt <https://www.ietf.org/mailman/listinfo/avt>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt