Re: [AVTCORE] RTP Header Extension Encryption

Sergio Garcia Murillo <> Thu, 10 September 2020 22:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A1BF83A0EAE for <>; Thu, 10 Sep 2020 15:00:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.045
X-Spam-Status: No, score=-2.045 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 DIc_xGtGIpzH for <>; Thu, 10 Sep 2020 15:00:41 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 756433A0EAC for <>; Thu, 10 Sep 2020 15:00:41 -0700 (PDT)
Received: by with SMTP id w2so2180279wmi.1 for <>; Thu, 10 Sep 2020 15:00:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=g48X5pCpbWJSw668byqvLmdYYRylgYnfW6oUDwUMG94=; b=suwoxk2OU5s0GJSI+b7+Z4J488n79uHN9KtPhN6pzEoEa4kfx49ezTvvETiK92qMCM TGDupE6T3sjqpsRR0geFAQznk+KbZAFCL2Xa2l/7b3xIZ7WkAbEM131CHYHw59rYc7cG 8d5XaamJ9YTi+lDr5W1l6CGHAR/pP7ABRAxdnIsXuiCk5UlHyJyFx84YO5WSZ4tulAXr Fc90JaBOZZ5hojKlfaMcnBWorLrytJIxduRkb5eQsrJNth3e5tPfeRnhqMWaWgIHF3tp mf/34pybJOX2i3z3HodQOJobJAtF5QYPUb2ebRlu7/4T0zRLdK5zevGv8uhqqU3pcQgB RN4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=g48X5pCpbWJSw668byqvLmdYYRylgYnfW6oUDwUMG94=; b=FFt0k6QQJwT/ZvFDIw/ul7yD4DGgRdPtYzXdutwHNqSwd9P2rE8B43I+CORgGTPDo/ nZKT3PJyzJe5G+mEN3jB1FE8l2YyLtfYrXNOn9WeD2Jp4LFgTdP3y8PlXbn4559gPLC/ 5s8EKh1GdNL5UDTvn+vlkznn+E3Ebw7pLbog9kerA0CQ3N3FzqAN3613e+DhfA6lxgLC ffFlgUu9aNaiW2qStuoveyjUbo4XHn3CpgiePJzpkRBwzEYYnl5XTZMv+rh2TttQaoyb 6qQ7ml6KlXco1GhwvVsnM4OF0YefULqVEB9aij/Y/ND5pnnOeysak9r4kxcPhPyiDlTU VBWA==
X-Gm-Message-State: AOAM533oUTlNdB89UCy4wHLKwyknj+IcBD8F/CENUrWHgGRkWQ2zUI7I l0EIKGfY2197ssKDwEYMJvfUAQL89tqx1A==
X-Google-Smtp-Source: ABdhPJxI4jrKEji8kYAUkuxEGJXSJY5J+h6yqs0G01t8jwexSEezCzynTBJ+c1/NkB6pJ9wjp6iRdQ==
X-Received: by 2002:a1c:2e08:: with SMTP id u8mr2188083wmu.156.1599775239663; Thu, 10 Sep 2020 15:00:39 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id p1sm6214120wma.0.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2020 15:00:39 -0700 (PDT)
To: Bernard Aboba <>
Cc: IETF AVTCore WG <>
References: <> <> <> <>
From: Sergio Garcia Murillo <>
Message-ID: <>
Date: Fri, 11 Sep 2020 00:00:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------052918BA1196A79D6A862BF2"
Content-Language: en-US
Archived-At: <>
Subject: Re: [AVTCORE] RTP Header Extension Encryption
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Sep 2020 22:00:44 -0000

C1 Encrypt Extensions + CSRCs would be my choice, it encrypts the most 
metadata while still being easy to implement.

On 10/09/2020 23:56, Bernard Aboba wrote:
> Sergio --
> Of the encryption coverage options presented in the slides, do you 
> have a preference?
> On Thu, Sep 10, 2020 at 2:44 PM Sergio Garcia Murillo 
> < 
> <>> wrote:
>     Fully agree.
>     On 10/09/2020 23:42, Bernard Aboba wrote:
>>     Speaking only for myself (Chair hat off), the lesson from the RFC
>>     6904 implementation experience described in the slides is that
>>     complexity is the enemy of implementation correctness and also
>>     interoperability.   So a goal should be to simplify the new
>>     proposal as much as possible. This includes the potential to
>>     negotiate encryption of all RTP header extensions "on" or "off"
>>     rather than allowing individual RTP header extensions to be
>>     negotiated as encrypted or not.
>>     There was also some discussion of whether encryption could be
>>     negotiated per m-line or just a blanket on/off for all m-lines. 
>>     IMHO, negotiating encryption per m-line is more complex,
>>     particularly if we also choose to extend the scope of encryption,
>>     so as to cover the ID field (e.g. encrypt the entire RTP header
>>     extension block). Extending the scope of encryption means that
>>     the entire MID header extension (including the ID field) could be
>>     encrypted.
>>     Having encryption on for some m-lines and off for other m-lines
>>     seems like it would open up a number of corner cases.  If some
>>     MIDs have RTP header extensions encrypted and others do not, how
>>     does an RTP receiver know whether a particular RTP packet it
>>     receives has RTP header extensions encrypted or not?
>>     To determine this, the receiver needs to determine the MID value,
>>     but for some packets the MID header extension is encrypted, and
>>     for other RTP packets it isn't. The implementer might have to do
>>     some error-prone and potentially non-interoperable gymnastics,
>>     like using heuristics to guess whether the RTP header extension
>>     block is unencrypted or encrypted, or attempting to decrypt the
>>     RTP header extension block on all received RTP packets, then
>>     checking for a MID header extension to confirm that yes, the RTP
>>     header extension block should have been encrypted.
>>     This complexity can be avoided if RTP header extension encryption
>>     is either on or off for all MIDs. It is hard to come up with a
>>     use case in which you'd only want some m-lines to have RTP header
>>     extension encryption on and you'd want other m-lines to have RTP
>>     header extensions sent in the clear. So the added complexity
>>     doesn't seem to have a corresponding benefit.
>>     On Thu, Sep 10, 2020 at 2:14 PM Bernard Aboba
>>     < <>> wrote:
>>         At IETF 108, Justin Uberti lead a side meeting relating to
>>         RTP header extension encryption:
>>         As presented in the slides there are a number of potential
>>         options for moving forward. It is quite likely that we will
>>         discuss this more at IETF 109, but I thought it would be
>>         useful to get mailing list discussion going beforehand.
>>     _______________________________________________
>>     Audio/Video Transport Core Maintenance
>>  <>
>     _______________________________________________
>     Audio/Video Transport Core Maintenance
> <>