Re: [AVTCORE] RTP Header Extension Encryption

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 11 September 2020 19:48 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 E54513A0816 for <avt@ietfa.amsl.com>; Fri, 11 Sep 2020 12:48:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.949
X-Spam-Level:
X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu
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 O3jDe5eKDKus for <avt@ietfa.amsl.com>; Fri, 11 Sep 2020 12:48:09 -0700 (PDT)
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2085.outbound.protection.outlook.com [40.107.237.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F223A0895 for <avt@ietf.org>; Fri, 11 Sep 2020 12:48:08 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fYXw+8/8DLsTtxAFvnuy5PGX6fTCdvKiAaQFxtBN+Ri0ogbWxM6YACXbWqzH+Iz5tSoO2xS2HltDW5bTaRhIfSKskW4lbKqGSCnD5SN1P8ubrD091eSFBgeh6R4HjnJQBZ4/Aq8R4o8oE1puEmcEozA7QsQgtPz5IzGoXe8yoekUmeWKEEan/dYBq36P40w6p1pwINAE41a0QoVt8inDcuVMdkgD3GbQ1XUCDbQIU3JGzYxLKqPV2wp3H20Xyetaz+bKO6cVB2yNAiIybGJFrwYMo5SQ6yw9VdjbjA/vMRVJcYpYEoyvhTYRvcHhw5y34TkTkmoF27zJXqTeqMdGfA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g0IukGMihbGNsDPbebYE/kKbMKPy27l1A8MAwR72rfs=; b=HI3+//lko4cfeIEdQCTRulXD3z9m6CyjTGS/7POtcj9yToT6OWxxrx1aCF3sSgF0vhnhj0cRMjXVe/Pfvcgw6YPB0MtA5eav5cI+C/tlfwepHUmdTvtrh6VA3g45BATVZ5JklQIlqDhRCyyXa5qIBEvK1GKh/tCe/bZJIoO9EPNdK+kWxq2Aa6hzpk2OHLSrDdRt0++VguGTbF4HES32dKfMy7rMZXJY05D6qqDegtnx0M2fK+JFnVGoGsO1sE51e8xb40aeZWgyuyuvW/BlDbX0/77QeeYOng+b2NuT2ov7LYKfFkOoNqb82IjPaoHNL6bIu++DTRBYC0jq23Xdsw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=gmail.com smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g0IukGMihbGNsDPbebYE/kKbMKPy27l1A8MAwR72rfs=; b=cjaGLXRArYlgBrAYyN2SYtk7NqX9uhZPxwo+LpbhmAGPlaf1mcz7c2yqzNqYM3T0W88YLVMQ/z2PfsSEs97kz3cB+LkAkAt5b40VeTb78ZNYfk4vd2ENK/eze2vl+lsoyng6lM8P6yuncqkkRgyWouYo7Tg4ncQVAQ8yv6PnT3g=
Received: from MN2PR05CA0020.namprd05.prod.outlook.com (2603:10b6:208:c0::33) by CH2PR12MB4645.namprd12.prod.outlook.com (2603:10b6:610:e::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3370.16; Fri, 11 Sep 2020 19:48:06 +0000
Received: from BL2NAM02FT042.eop-nam02.prod.protection.outlook.com (2603:10b6:208:c0:cafe::f5) by MN2PR05CA0020.outlook.office365.com (2603:10b6:208:c0::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.5 via Frontend Transport; Fri, 11 Sep 2020 19:48:06 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=bestguesspass action=none header.from=alum.mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu;
Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT042.mail.protection.outlook.com (10.152.76.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3370.16 via Frontend Transport; Fri, 11 Sep 2020 19:48:05 +0000
Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 08BJm436009260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 11 Sep 2020 15:48:05 -0400
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> <c390c256-3b4f-5c4d-0e2f-a784acec663c@alum.mit.edu> <CAOW+2dvAJSvAZmwNdYyGASj8Y5dptt8L6B9YrU3RMNrwP2ShGA@mail.gmail.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <e94134bc-e411-1bdb-44cf-3cdf34f38044@alum.mit.edu>
Date: Fri, 11 Sep 2020 15:48:04 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <CAOW+2dvAJSvAZmwNdYyGASj8Y5dptt8L6B9YrU3RMNrwP2ShGA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 6f5a5734-fe17-487a-264b-08d8568b9a22
X-MS-TrafficTypeDiagnostic: CH2PR12MB4645:
X-Microsoft-Antispam-PRVS: <CH2PR12MB46459C42D597BBF42025AECAF9240@CH2PR12MB4645.namprd12.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: e8Py5hu3ET556pmYmsLQwIOA4bxbVBQmyOoAScSupirhnHjvEzdo4kD4hvnpSoT1inTWkGP4i9EAvU76z31rCM5sKDhYR1ln0YhP5t2UYrTTgC2sZ91GHNf28Oj5qKEYGtOoMqsOVbv5+mZ5GlQjtgrvjS2YNtLmlp8+BDv4CAOR1HqRlPxMm7Gf2Uus4FvAJ6A0nGYIP4euPyyoWhN5d0tcMagnKfFfG1i65vV6rtjn0vnTbThrUlNTxY0PazmVCdbBTiIvhzcWmgjNSqbTGGlM5rFK0qQc1ATo8l41Bj5gGYP9SFmzZv9Ka4mxt8F2Dh0KBsMu7XRkcmEdw93919gXZJr4Vj8uXjUPE56MT2MBrbiN/Dx5EZBia57OoBmBsCaRlJA58cmINfzx+Xs+U2nlTwVL1f+DZHlzWo780DYpRb+zahaI2usPwcQ/Xv+0/neEIDg1EJ74u4kcz7Ofw1Ca058t6mtLRHrn/w/sauvJi/KO7MNVUbnh0zPDVCne
X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(136003)(376002)(39860400002)(346002)(396003)(46966005)(70206006)(31686004)(83380400001)(31696002)(47076004)(70586007)(5660300002)(356005)(82740400003)(82310400003)(7596003)(86362001)(478600001)(75432002)(2616005)(956004)(6916009)(966005)(2906002)(186003)(8936002)(336012)(8676002)(53546011)(26005)(786003)(4326008)(316002)(36906005)(43740500002); DIR:OUT; SFP:1101;
X-OriginatorOrg: alum.mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2020 19:48:05.8413 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6f5a5734-fe17-487a-264b-08d8568b9a22
X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu]
X-MS-Exchange-CrossTenant-AuthSource: BL2NAM02FT042.eop-nam02.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4645
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/bd38XrFdWVdq-XqY-LiAWM10xiM>
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: Fri, 11 Sep 2020 19:48:18 -0000

On 9/11/20 3:00 PM, Bernard Aboba wrote:
> Paul said:
> 
> "Can you please clarify the scope for which you want the encryption to be
> consistent? Above you variously mention all MIDs and all m-lines. I'm
> concerned with what "all" applies to.
> 
> I think I can agree if you are talking about "all within a bundle
> group". Anything broader has major problems."
> 
> [BA] Thanks for pointing this out.
> 
> Mixing unencrypted and encrypted RTP header extensions within a bundle 
> group is problematic because all of the RTP packets arrive on the same 
> port, and the receiver needs to know the MID (which could be encrypted) 
> in order to figure out which packets should have encrypted and 
> unencrypted RTP header extensions.  But if you have different bundle 
> groups, then it is possible for each group to have different settings 
> (e.g. encrypted RTP header extensions on one group and unencrypted RTP 
> header extensions on another bundle group) without that problem 
> arising.  So this is an argument only for consistency within each bundle 
> group, not for requiring all bundle groups to have the same setting.

I'm feeling we need a new term here. It has to cover a bundle group as 
well as a single media-description that isn't bundled. Is there a term 
for this within the RTP vocabulary?

	Thanks,
	Paul

> On Fri, Sep 11, 2020 at 11:31 AM Paul Kyzivat <pkyzivat@alum.mit.edu 
> <mailto:pkyzivat@alum.mit.edu>> wrote:
> 
>     Bernard,
> 
>     On 9/10/20 5:42 PM, Bernard Aboba wrote:
> 
>      > 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.
> 
>     Can you please clarify the scope for which you want the encryption
>     to be
>     consistent? Above you variously mention all MIDs and all m-lines. I'm
>     concerned with what "all" applies to.
> 
>     I think I can agree if you are talking about "all within a bundle
>     group". Anything broader has major problems.
> 
>              Thanks,
>              Paul
> 
>     _______________________________________________
>     Audio/Video Transport Core Maintenance
>     avt@ietf.org <mailto:avt@ietf.org>
>     https://www.ietf.org/mailman/listinfo/avt
>