Re: [AVTCORE] RTP Header Extension Encryption

Bernard Aboba <> Thu, 10 September 2020 21:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A1F803A0E52 for <>; Thu, 10 Sep 2020 14:56:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E-ycx17Fy7Pw for <>; Thu, 10 Sep 2020 14:56:39 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 92AAD3A0E4B for <>; Thu, 10 Sep 2020 14:56:38 -0700 (PDT)
Received: by with SMTP id y4so10124593ljk.8 for <>; Thu, 10 Sep 2020 14:56:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <> <>
In-Reply-To: <>
From: Bernard Aboba <>
Date: Thu, 10 Sep 2020 14:56:27 -0700
Message-ID: <>
To: Sergio Garcia Murillo <>
Cc: IETF AVTCore WG <>
Content-Type: multipart/alternative; boundary="00000000000064d3a205aefca487"
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 21:56:41 -0000

Sergio --

Of the encryption coverage options presented in the slides, do you have a

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 Maintenanceavt@ietf.org
> _______________________________________________
> Audio/Video Transport Core Maintenance