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

Bernard Aboba <> Tue, 02 August 2022 16:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 742A6C14CF18 for <>; Tue, 2 Aug 2022 09:30:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Status: No, score=-2.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_NONE=-0.0001, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fFwNhVMlhfj2 for <>; Tue, 2 Aug 2022 09:30:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::62f]) (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 (Postfix) with ESMTPS id A692BC14F742 for <>; Tue, 2 Aug 2022 09:30:44 -0700 (PDT)
Received: by with SMTP id a7so13936685ejp.2 for <>; Tue, 02 Aug 2022 09:30:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=0gamzQvxddFdYLjJ0KSuyDGLfRt7SaHT/QYzF6AEk8M=; b=Q8tIA8vYRS2kebO//v1XWDRGRAZFloMAOVUai+CFuII6HJLy+6cHGbDN8FWT/aTUF6 3A5/wsm9Kiv2C2ppMHNBnxLIatfzwdzNbDQHCpZMn/weZwpODMGJXRMNou+FdiWfcA/h td5NDSynUgT4B7r3+21LUz4/2/SpB8yW6XZtnzytbgc4IPA/I1uGlL7WiT5PwfubwWJ9 Rrqn3/Q4mBzRRcj7prN81AhfYcAJvfRoFJ/Sq1/nx7BOw1j/p1b+jSMVlFTDtRAzu8w9 ADBXskioQEmVp1iY/PjpNfH0H2LQyIV29BpfzkOX0LVpCw6OQup5uuPGpqzg03RVAfud ETaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=0gamzQvxddFdYLjJ0KSuyDGLfRt7SaHT/QYzF6AEk8M=; b=TULG/PEM+JbFvS4xmtkFu8Lea8Qy945ddg6sXCqheepoGouG9ULwotDYCkZoh5ZFAO vThlVd8NbIk88IwNdpxX694nPukmvFLViQDGd9LZ5MtlMJpnojDcO868KSfrxrgs+nBx WjpAj8q8SKYQrJhCX1OfILf5Ky8kh4XvhEQqrqbha1CngRA0zWE1rKstgWPttt+EY8zg Ci+38Ll46HSFNny5Pt52btgyUy6ZtfqcViJWo3sUrYyGnoFtpSacNeszC4D3FThqUOgg M4p+4Hqq2ayOIdXAGP2SS2PiyT8ACvqU9A2Ci9IEPpgG+IldQWf8EE0S8iEoy3EGtTAP O7Xg==
X-Gm-Message-State: ACgBeo2CFv5PL5a8Em4lkU/MHUxYBwVww6nW76w4Ox697R4f+JgAr/Qs hEUoy5TZNEVG7r/Pf17DGTS+UlEIOdacOq5qin3CIPP/
X-Google-Smtp-Source: AA6agR4geLo99eo10IfbRoIAI1rnGgQH59S8S8+ouE40Lo02fZT3eAYkr+Ry5DqfSwEJaLMq2oGx9MUw869Yx+IlBek=
X-Received: by 2002:a17:907:2be3:b0:730:6866:a9b1 with SMTP id gv35-20020a1709072be300b007306866a9b1mr2464727ejc.693.1659457842400; Tue, 02 Aug 2022 09:30:42 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Bernard Aboba <>
Date: Tue, 2 Aug 2022 09:30:31 -0700
Message-ID: <>
To: Sergio Garcia Murillo <>
Cc: IETF AVTCore WG <>
Content-Type: multipart/alternative; boundary="00000000000037560205e544a3b9"
Archived-At: <>
Subject: Re: [AVTCORE] [Cryptex] PR for recommending Cryptex over RFC 6904
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Aug 2022 16:30:48 -0000

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