Re: [AVTCORE] RTP Header Extension Encryption

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AFCCB3A0E78 for <>; Thu, 10 Sep 2020 14:42:22 -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 6YKnz6S-UZI0 for <>; Thu, 10 Sep 2020 14:42:21 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A37D23A0E19 for <>; Thu, 10 Sep 2020 14:42:19 -0700 (PDT)
Received: by with SMTP id y17so4404172lfa.8 for <>; Thu, 10 Sep 2020 14:42:19 -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; bh=ueGgPOrH6SUvOtwNIZdylida0K8oggEpz7VBSPwY9yg=; b=G2NwpXsp2be8nm4YHleN2FOlnXgvHMsAXQG4PeZrSfZSKwg/qwLMocSRjpPtmWVNkI f414a32eSfl1K8+1cBgFJV0Hh61Vu0O7jkNSsqBAhsFvEBOxvE1i3TCC2Aspy+w9q6g2 Dn4EQ2RdoP7ZOgMcfQuAN5/IIJds9SLxp2l+RwOfhseBFIElXFQ5J73ciGoVfrOrAHZO yU3VZlFz0lym52SpH865vnWZyxvnPpBuuReccOubPkXvDq27umeHvlnQQ/nfV7mbN7rq gObqvWEFh6jUBVu0Qpr+zauI5mtFG8kRZWqaGnup35wJU5ZBo7CdrQf8FLbldAg6aojp gmkw==
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; bh=ueGgPOrH6SUvOtwNIZdylida0K8oggEpz7VBSPwY9yg=; b=nTo4pQFxC2bK3QbtZA7DorD6Xh0TrkXyWkaqK2WeuEWAom6X0XoT9EjKcCrOKh3vkp 122DCYhemlxuSVE0BaXVjhZUWqrwK8ptnrR4QsXRsds63M+Avl+SLCJR0E1EFoJPO6HN 5DNZFhTOi1I3IrlcbBgAu2B/dC8jcPoJ4T39sV7Mi6/EifbOreJkJ1kk6dI67kl1pwGX d0qLHIAM+qIT/iKK7S2hWUVooNBb6fCdf9uH8m4zy2RyeOrGHSCpbgodorDp/tC/my7g VNL2o5BFJq/jrHPlHvCiZWgY5qNyJ7bbZYObq9c96UEocpL9GhJ9F6SHhOXhhpM5+3K/ CVPg==
X-Gm-Message-State: AOAM533qr0L0MXBMu6gLBwYdBtHap3vAdIg0FCdTYmSapfpjVSOkuuZj dWZR3Mbk4VMFqhXRYWw4P2D8+ssAio7DesqgH6u4jTrAt2aczg==
X-Google-Smtp-Source: ABdhPJzZhxf6jgVo8kR3XQ6saRrhRDXneQYpFMXtBC8qet3Oxf5PAYl/kkFB07QhZC10ZJ3fS1xEffiC+nzkq9Vpk50=
X-Received: by 2002:a05:6512:2027:: with SMTP id s7mr5199813lfs.75.1599774137586; Thu, 10 Sep 2020 14:42:17 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Bernard Aboba <>
Date: Thu, 10 Sep 2020 14:42:08 -0700
Message-ID: <>
To: IETF AVTCore WG <>
Content-Type: multipart/alternative; boundary="0000000000003117e705aefc7104"
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:42:23 -0000

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

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