Re: [AVTCORE] RTP Header Extension Encryption

Bernard Aboba <bernard.aboba@gmail.com> Thu, 10 September 2020 21:56 UTC

Return-Path: <bernard.aboba@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 A1F803A0E52 for <avt@ietfa.amsl.com>; Thu, 10 Sep 2020 14:56:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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 E-ycx17Fy7Pw for <avt@ietfa.amsl.com>; Thu, 10 Sep 2020 14:56:39 -0700 (PDT)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 92AAD3A0E4B for <avt@ietf.org>; Thu, 10 Sep 2020 14:56:38 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id y4so10124593ljk.8 for <avt@ietf.org>; Thu, 10 Sep 2020 14:56:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ATZd1hFQf6xOXHYXlulcnd6h+kPh49tI3gaFZealF6U=; b=hcZFfZ8WUwaheHDgR49IybPZOfZ00XBiy5LjVZY8nV6SN+b8jF4u38QfRaW5bBUSL6 O3CuhccYSMU2XUg3DD9LvnFzfuSc2wqYp8N4+M/yqd7dYSz6OA92D0S6ExtaN4RcHpJk T9WSwx/1ae6n48GrG9b+t8lPW5zce64kZURy8sfqBV440cZKKiGnYPX+vuDs1ctlWPyl K1sC2oVl8JJ2O05trE2R5Lrwv2KrheweYER1vOV/Bf/zw/p0bObCuw8DbQHHEXfmSNhA I4BnUR0fIWBnx3mEUSjtRNm5yxE/CwODXfQKkP6JQoup3r5cKuMrRl9TV4q7zYauOxTo 7NKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ATZd1hFQf6xOXHYXlulcnd6h+kPh49tI3gaFZealF6U=; b=lbt2vSZd+BwYQPQBvkBgJcJ/s7GhUc48ILlswwiFhFD9lgSRjxG/B9E2ewazuV3wpF 4pDakpc3V6i6WlCbR7Q3495JmYN/KZHmT/piBJzkbX2BPiLl95Mf6oQ9Y3mlCRjgUZ74 C8RiZQqTiq24gL1FYwaFIGJmgwmwiqH/WjNwpJWn+5UsSQq0ce7CEuFF5GHnvPDAAa5v nbbc8eSqfCFLqjqiaSs4TCpeaJvZKFiPN0gQM/l+gNSy5uJvnU5jIr+M3+Tqc9aw39Ge UzoZ2PPtJgF+VWWyEcUXGOS8cgnw36g3fgVheik2JlEUHCG+tQKlc3RhpNjnK9zXnQYq RzVg==
X-Gm-Message-State: AOAM533HSpIBuUYLzv9I+cUPMPL6lsMsiaHpaRVzKcBRFCPHEp8KnR+a qkL2K6bLlpbv4R8MUd8l9PHmPi5KNZRekmgCxFY=
X-Google-Smtp-Source: ABdhPJyDooyubnAcI6s6dSHWR/fH6iGnctkwzahYzHKXTzzHRkzRcFPJEOM4ojHLpwsGuqO2cA3vFODfKMn5d6fCpG4=
X-Received: by 2002:a2e:b4c8:: with SMTP id r8mr5804772ljm.37.1599774996614; Thu, 10 Sep 2020 14:56:36 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <ca4ccb1d-3ac8-75c1-9a2a-70bf1c3315b9@gmail.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Thu, 10 Sep 2020 14:56:27 -0700
Message-ID: <CAOW+2duEfA4QXTGHbp7XdC6G+LoQ+SGjFjJxb92F0wzaPbA0ZQ@mail.gmail.com>
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Cc: IETF AVTCore WG <avt@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000064d3a205aefca487"
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/NYOdmzA0l8mEZY28CluRlFkoI9U>
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 21:56:41 -0000

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