Re: [AVTCORE] Benjamin Kaduk's No Objection on draft-ietf-avtcore-multiplex-guidelines-12: (with COMMENT)

Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 17 June 2020 08:05 UTC

Return-Path: <magnus.westerlund@ericsson.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 3CE0A3A00E0; Wed, 17 Jun 2020 01:05:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=ericsson.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 e9vMap_ophGe; Wed, 17 Jun 2020 01:05:01 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40074.outbound.protection.outlook.com [40.107.4.74]) (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 056AC3A00D6; Wed, 17 Jun 2020 01:05:00 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NMQdtAmvynyUhHL7ZyG7TyN0T19ir0J2++bXnZJpazpr7Baet/2e+azue/pBCQrY9JCwkXM/oISq4FEVBKeOQmG57b3+klXblwib+9sBqPDq3gjeytopwK4PWBI0mlicUXemAZY+esdgp2ulvMCes6zKTyLEajzTCJCW+2ZXTmBdkQ1oqeMeT3Z2kkv5DYWIcGFnLOasd+LvJO2IXHNn29tToTFlnNA8QDGhvaQ91SW3WiC4cMFq4385hhheXK7v7/hn3q4pl3arY7JZLLrnXZIwIul0JM6z5x4jQgqhAm+2cuxt/FcGTOUQtxqxgW46e73EN11GUt5H0b6z+aF3tA==
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=SVdl9mbDQ4tcwP83gGGP7LaaR9TFk1z5PlIB4wDTYjg=; b=mo+wAUjqvfU++98X1fs871u5dw2rOkyOk6Hfpx09KaODZr4HIk03uUJDUF0IviHpEnRwJxp+RpYnFqF8iKkUMySVIgfdX18nrwnlId8bY3upurfNwRHEzTZNlmxS58fm8d4lQzeF27RRYO2K6oTgEikudwrBYOti1MqLw4MkK8dOdqGlSQdzyf/GVKZ3axWAHY+BV1L00nB6JkuF1o/SBGhG7qPKwIkLz5rvLrsm1FaGs5UMlAYLIQE2ODNWsV1cJ7timuBENcBLtMo21d7pMmP+hUeamqbZV4FeDLPk6hWTYzEIRGm2o/hUKxCGmIN5ycSIp/YvE+vCeZJTn7oLFA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SVdl9mbDQ4tcwP83gGGP7LaaR9TFk1z5PlIB4wDTYjg=; b=J6UJvP4hVeYTeAMJ3DWJfW0C6D+Qvpst8nYFEON+jgQxtDWHz2mmdpQafmW+8G8pBypoMZELGW8aDCDEjLJa57hTYzYZep2Fsckem7iXswX1bauW6RWQCirLavmZHGNeNs3eR9p/OzPFdFLIR/ltFWA/6um1bB/lWtMV/eT9s5w=
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR07MB3097.eurprd07.prod.outlook.com (2603:10a6:7:32::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.13; Wed, 17 Jun 2020 08:04:57 +0000
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::546c:3b3:9193:3351]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::546c:3b3:9193:3351%6]) with mapi id 15.20.3109.018; Wed, 17 Jun 2020 08:04:57 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "iesg@ietf.org" <iesg@ietf.org>, "kaduk@mit.edu" <kaduk@mit.edu>
CC: "avtcore-chairs@ietf.org" <avtcore-chairs@ietf.org>, "jonathan.lennox42@gmail.com" <jonathan.lennox42@gmail.com>, "draft-ietf-avtcore-multiplex-guidelines@ietf.org" <draft-ietf-avtcore-multiplex-guidelines@ietf.org>, "avt@ietf.org" <avt@ietf.org>
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-avtcore-multiplex-guidelines-12: (with COMMENT)
Thread-Index: AQHWRFgAFcduj+nKhEufXtlNvRgvmKjcc0aA
Date: Wed, 17 Jun 2020 08:04:57 +0000
Message-ID: <2bee0645cd0bb4aa6c17f676af5a432c3e8ff836.camel@ericsson.com>
References: <159236477330.24380.13617768880911328228@ietfa.amsl.com>
In-Reply-To: <159236477330.24380.13617768880911328228@ietfa.amsl.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [176.10.164.117]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: aa8431df-65bb-40cc-d277-08d812952046
x-ms-traffictypediagnostic: HE1PR07MB3097:
x-microsoft-antispam-prvs: <HE1PR07MB309707CFE2421041A480863B959A0@HE1PR07MB3097.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 04371797A5
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: yLJVQ0NdbAaekzJBKS1eMeX2QEdeCRA1mC6Da5d1KDbRhVf0SItccz3qnXZccCXRvICdPx/NbZ3LG/0GbcW98aVeQYIKPQIHQwgiEbmoikZS3h+10qOtO2kTJrWPFt+17iDClVueY7CsKZA8HxpQFeYndy/+ZnX1fYdcQf2lzDUtCXkmtR+Q+UdPzUb7wbfdBUqCgekPke7UUm9dIDMEOjNu+fhrysquRXQCQQKyhLbrmjd1eq24NHGBe7yBF+thrcx6zMoMDbEZgbUHpc5hA1thfHXkbSQIALrj/mE652orvmqfhB+LOW72wMH+i8l3Yqg1i/fb/xj+vctPnt73tiyU9Ow9k30S5TQSvtPTPiLqe+uCJad8tbskOU7YFuGuuUDEUrfqzLXQm0RjLDjADzcIQp7WAs/MhuA2ezuBuEKilzyViVExMSnU3Xddn6G3dkJBCJdW8L1tHHD7d4ArYQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(136003)(396003)(39860400002)(376002)(366004)(66476007)(83380400001)(6486002)(76116006)(71200400001)(64756008)(66946007)(66446008)(5660300002)(66556008)(316002)(4326008)(2906002)(110136005)(54906003)(8936002)(186003)(36756003)(8676002)(2616005)(478600001)(6512007)(44832011)(86362001)(966005)(6506007)(26005)(99106002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: e9kZpUq0dMgButGoC1zKj8qkqI6wQCTpd99R4lZK/w74aiz1G7w+TgVWrZtb3uqQPOQANCFJLDeM1C5DXeFVVZgXEDFWXjOoV05dHfH441vIRnH93gAsxjW4VXZTo+pqya0KA6HazwGlumy/uCwdDuM9qdJlM3rEDgQW5SUnCPocAE+BkPuLwINLADbBw9lijqngInBdh8c2FEzI6VCJciV0Qzqf30Refux1n9VZkrtYiVizOnWOpHklzogtK1a/dCwTSOwrRUcPi/yOSgtoFD/a6CpEQFkceJ/d3ahjkqyr0IFMZA7+5vJnv08pv0MnPwvZ0gVOtUw8cnYGRr9Lq1zlBRuNzQfUB6Dpus16VZO8cc1TtnhH4YhQDl0Mdviu3I6T3Y+V72GoID5spYzlO4iNsmuLUdbfnDNbREsrFf2UipGzgs4h0dDPzQYlPcOCzSufFab+PRaRCGJHhF23bLJLdZE0YudHnCwGrUqZ8ABIYJG0oQOKt9Enb4IEohOV
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <D5C0A4946BAB684AB5E365D87D25E11D@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: aa8431df-65bb-40cc-d277-08d812952046
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2020 08:04:57.2445 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: AMTxayL+Hs1kTQmkfORG8SFyi7xIShtzxi0NJoOTlYloNHDw3k/Dg+vUggiSYrCagdjuJmZb8NvWRiX31HT7rVVnoSHU260BWwmEkKthm5E=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3097
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/E17BCc07gs6eo9oTIRLbzs9mCek>
Subject: Re: [AVTCORE] Benjamin Kaduk's No Objection on draft-ietf-avtcore-multiplex-guidelines-12: (with COMMENT)
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: Wed, 17 Jun 2020 08:05:04 -0000

On Tue, 2020-06-16 at 20:32 -0700, Benjamin Kaduk via Datatracker wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-avtcore-multiplex-guidelines-12: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to 
> https://protect2.fireeye.com/v1/url?k=0b08921f-55b80f87-0b08d284-861fcb972bfc-1bcefe42a2cf38ea&q=1&e=52b5d9a4-3617-40b8-940a-53b949d7c425&u=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> 
https://protect2.fireeye.com/v1/url?k=3b2e741d-659ee985-3b2e3486-861fcb972bfc-fb880de6ca902fcc&q=1&e=52b5d9a4-3617-40b8-940a-53b949d7c425&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-avtcore-multiplex-guidelines%2F
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for addressing my Discuss point.
> 
> A couple things I noticed while reviewing the diff:
> 
> Section 3.1's "might not be the choice suitable in another
> situation or combination of reasons" seems like it's comparing things of
> different types.

Ok, will try to keep this in mind in AUTH48 and unless the RFC-editors already
catch it. 

> 
> Section 4.3.1 now has:
> 
>    SRTP [RFC3711] as specified uses per SSRC unique keys, however the
>    original assumption was a single session master key from which SSRC
>    specific RTP and RTCP keys where derived.  However, that assumption
>    was proven incorrect, as the application usage and the developed key-
>    mamangement mechanisms have chosen many different methods for
>    ensuring SSRC unique keys.  The key-management functions have
> 
> I didn't try to look at RFC 3711 and see if there was now-believed-to-be-
> incorrect
> text in need of an update or not.  I guess any potential violations of 3711
> are
> in the "application usage and the developed-key-management techniques" that
> we describe, not in this document itself, so there's not really a question of
> this
> document being in conflict with 3711.

So RFC 3711 for example contains the below statement, and if you read more in
section 7 and 8 I think it is fairly clear that the original intention was a
single master key per time periods. 

7.1.  Key derivation

   Key derivation reduces the burden on the key establishment.  As many
   as six different keys are needed per crypto context (SRTP and SRTCP
   encryption keys and salts, SRTP and SRTCP authentication keys), but
   these are derived from a single master key in a cryptographically
   secure way.  Thus, the key management protocol needs to exchange only
   one master key (plus master salt when required), and then SRTP itself
   derives all the necessary session keys (via the first, mandatory
   application of the key derivation function).

So there is one keymanagement solution that is capable of proving only a single
master key, and that is MIKEY in some mode, and something that is requried in
the Broadcast/Multicast keying cases. However, Security Descriptions and DTLS-
SRTP both result in per endpoint master keys. So I would most definitely blame
the keymanagement mechanism. The impact of this I think where minor, simply to
add additional master key selectors in the security context handling so that one
can determine when a new SSRC is received or locally generated that one picks
the right master key to derive the per SSRC keys. 


 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------