Re: [AVTCORE] RTP Header Extension Encryption

Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> Thu, 10 September 2020 22:00 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 A1BF83A0EAE for <avt@ietfa.amsl.com>; Thu, 10 Sep 2020 15:00:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.045
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIc_xGtGIpzH for <avt@ietfa.amsl.com>; Thu, 10 Sep 2020 15:00:41 -0700 (PDT)
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 756433A0EAC for <avt@ietf.org>; Thu, 10 Sep 2020 15:00:41 -0700 (PDT)
Received: by mail-wm1-x330.google.com with SMTP id w2so2180279wmi.1 for <avt@ietf.org>; Thu, 10 Sep 2020 15:00:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.googlemail.com with ESMTPSA id p1sm6214120wma.0.2020.09.10.15.00.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2020 15:00:39 -0700 (PDT)
To: Bernard Aboba <bernard.aboba@gmail.com>
Cc: IETF AVTCore WG <avt@ietf.org>
References: <CAOW+2dvo8z422LFeP5S652bq8RkF-SKhik=aXYXpTe9zqBX5yw@mail.gmail.com> <CAOW+2dt_A+A1AVnTUQyB4sTG5hMCv7Gf3-rrBB89LR-oacX=Rg@mail.gmail.com> <ca4ccb1d-3ac8-75c1-9a2a-70bf1c3315b9@gmail.com> <CAOW+2duEfA4QXTGHbp7XdC6G+LoQ+SGjFjJxb92F0wzaPbA0ZQ@mail.gmail.com>
From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Message-ID: <4ccc55a1-e31a-ab2c-750b-18e3d6a21ecf@gmail.com>
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: <CAOW+2duEfA4QXTGHbp7XdC6G+LoQ+SGjFjJxb92F0wzaPbA0ZQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------052918BA1196A79D6A862BF2"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/UaPVM-g-spS-Y24rIQdXXoBEgpI>
Subject: Re: [AVTCORE] RTP Header Extension Encryption
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
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: 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 
> <sergio.garcia.murillo@gmail.com 
> <mailto:sergio.garcia.murillo@gmail.com>> 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
>>     <bernard.aboba@gmail.com <mailto:bernard.aboba@gmail.com>> wrote:
>>
>>         At IETF 108, Justin Uberti lead a side meeting relating to
>>         RTP header extension encryption:
>>         https://www.ietf.org/proceedings/108/slides/slides-108-avtcore-rtp-header-extension-encryption-full-01
>>
>>         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
>>     avt@ietf.org  <mailto:avt@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/avt
>
>
>     _______________________________________________
>     Audio/Video Transport Core Maintenance
>     avt@ietf.org <mailto:avt@ietf.org>
>     https://www.ietf.org/mailman/listinfo/avt
>