Re: [Sframe] Intended DISPATCH outcome / charter

Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 23 July 2020 08:51 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: sframe@ietfa.amsl.com
Delivered-To: sframe@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C353A0A99 for <sframe@ietfa.amsl.com>; Thu, 23 Jul 2020 01:51:11 -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 T_262nPF-2Pm for <sframe@ietfa.amsl.com>; Thu, 23 Jul 2020 01:51:07 -0700 (PDT)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2071.outbound.protection.outlook.com [40.107.22.71]) (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 43D9E3A0A9E for <sframe@ietf.org>; Thu, 23 Jul 2020 01:51:06 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KsG5qc3y63sU3zbEZK9CXG3z2qdRQJ8DjEBH9vCKsQePH8gE8ZuIKGec/nsJ2KaZKS6v49NOums73wkAfb5xVnuFn/gLe6/SwHjDvBttMBJiY+rjJOJ0KoFt2aRKvAYEJLSB/g70OkQITBPP1vVUTyc6ww4Gi1PJTV5hLiK2ROMXm1nQBQVnsIdR/GOzkLA3cxv4CO9oOtCwQlel8iwzTKTxVi/3VTP4nfqOJbQ1076aGT54ADGWdNVMlBpr6ZjtEvbT4BnJ0z6Xz8DNiSTpBfzft9xrOyHQZ5vB7aLqhoeSsQvbT6Sr7lV9KeUMf9X2zu1f28ZMpc1DMp5nimDSWA==
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=QzZU4cRZC1G9HPfYEjbOYU5t63ZrzQm1XB5QKf5Ar6k=; b=nN+LiuhJJalDy18NQcDLaG+zTmZjYaFxar3rUD08BBzJqWpdLynDLZLKAdBsRg5FSQBod9rmqxrqrItPb3IfoSrDUXca1AzbbPF+vGsMSOPL0hgWhe8g0WTi5gJOW31KCwiuA4qlxjik80+9+wPZuOo6edbBxUlitYXhNrmdmYmYECbXYDliE0O0Xth7KnO1QIZGjPVtlyD9Q6+NBklI6U7cWcRnF0aO3jrugZq4/GAhl5Wnj9u50fi2GXt3sc3Mo0AfFqs6metgeW6bzzT5moUWpu7oPq9091AYvZxdqUwlsHLJn3RPoWb4+cVRS8ljLsYo6C4WFGG4heBT7W9zOA==
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=QzZU4cRZC1G9HPfYEjbOYU5t63ZrzQm1XB5QKf5Ar6k=; b=sfaCsKPoUK9HOBn6bbz3gOYXX6l6KgstWnEu8pPfDkKyfbwU7s6dZ1C3h+sjQ/btJDhuFGqqcANt9uqO7pFfA7z96YB6JXCvtHp+VsVoZ8ODqNudEmZtzOyzLfRE10i7KrPAQrf93q2tNBpgAEuILERU3AAeHo3dxq0zgAhVcbY=
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR07MB4441.eurprd07.prod.outlook.com (2603:10a6:7:9f::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.20; Thu, 23 Jul 2020 08:51:04 +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.3216.016; Thu, 23 Jul 2020 08:51:04 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "rlb@ipv.sx" <rlb@ipv.sx>
CC: "sframe@ietf.org" <sframe@ietf.org>
Thread-Topic: [Sframe] Intended DISPATCH outcome / charter
Thread-Index: AQHWX6BVS9ezzWCbUkm5Qx4nCnoBHKkTch8AgABfd4CAAQvzgA==
Date: Thu, 23 Jul 2020 08:51:04 +0000
Message-ID: <1cd38792ed7fe24f48e2dfa1187dbb78affb985f.camel@ericsson.com>
References: <CAL02cgTNad12T8a0V9E5ca6Y7tJYK6-=_c4j1LLiaCM9-DF-=g@mail.gmail.com> <c963c1fc1fd1dbc93e5498e6ae6fd6b4f32f2954.camel@ericsson.com> <CAL02cgRHYY-yW1U6xy3vx6nOktJhnfw6eTCbn5Xq9=deHKTpwA@mail.gmail.com>
In-Reply-To: <CAL02cgRHYY-yW1U6xy3vx6nOktJhnfw6eTCbn5Xq9=deHKTpwA@mail.gmail.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: ipv.sx; dkim=none (message not signed) header.d=none;ipv.sx; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [158.174.130.202]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ab902c70-cb2f-4301-bb3a-08d82ee588a6
x-ms-traffictypediagnostic: HE1PR07MB4441:
x-microsoft-antispam-prvs: <HE1PR07MB444147E18D4E2EA0E79D52E095760@HE1PR07MB4441.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: irSOkc3OACyaDHQ45pdHcNaw9QaPKFpXxh6q6TqIgEZkr5PItWSepZxZzA9YSsD/QtSQuthBqUR0QgqumxOs2bvAHCD4PLAwtr6cCWP09/1gvb8e/T8T+gnmzQr9551lqkC3GQuyShcgs9nxGJDJM/FlZSAL0Gg2sX4VzpDz2JGw/HkPIfy3gntrvmkQXmaXpKFMaSph2ZHKQlHWkEt3EC5spR7Klp1lZ2g50TDxya3lLyL9AlUcP9DnF7LEciEad8CEcK0vRE+/doUuYmD9XyeoKiTsz3vQQYz85v3Ru/vYpjh2PSnvjXXIwioE/sVR4nG3kSz498mK21El7O5CPNgMVvlfuI2deOlB4yflQLx90GemLOOEmdLNaXCYwf4A
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)(376002)(346002)(396003)(136003)(39860400002)(366004)(6512007)(26005)(53546011)(8936002)(316002)(83380400001)(71200400001)(6486002)(186003)(6506007)(8676002)(36756003)(2906002)(5660300002)(4326008)(64756008)(76116006)(478600001)(86362001)(2616005)(66946007)(66476007)(66446008)(44832011)(66556008)(6916009)(966005)(99106002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: okznoQ6Pos03NEmCqqKYD17SJIjZorBEzYTsjRJPUODOtb2Eo12R8ZNLVH+0DVe6XQJhmoyZiqEevsNsDK6xjS2MKFlQ3m5C6oOkGNCX+0ql0F5D26K8Q52hd1Z5sL6pFlno2pD9+NTfzXMIbkXpVKQQtYEccnrIHU46nWNF9TLq5Pe6dhWWynD/fcGeHs735MYB518LJ2H6+DzTOspKmWZ13zO612pBNE1BzLqvjXd5INa/YWnSzjhwLHNEuv9VtClNKzYofo9m04nosx8BaT30qusPRXtIpn30UyN+ReNSbqQciHF4vamcsArH7KIEIarP+z/oEAd+FTm6ZWwazwjcFQdR3E+zcVvVO1fn/uzoE9b3BEjOCnL7YqDOjl5h3GvnVvKgma+nB7SHi3yfK9T1wagXMBccadWO19SaVOvDYFKmPQWX9C59Bx4vjLTDLu7MyVIbZwPopuiiNjQa+p+DOQYRki5ifScZpj/wQ78xRPx2MRV3HqEImEu4fSV8
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <81746839F6D20640898A95EE6082CDD1@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ab902c70-cb2f-4301-bb3a-08d82ee588a6
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2020 08:51:04.6682 (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: Jpv8/iyYpis18RGu6pKF/XsWQuL7GliISdWFBT2Ch8Fxg80xqRiz4MKJpQ6sm3u/mdywDDvF2X9PzDVhv9F447ZmEFg9iEuq4DECHGlgmWo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4441
Archived-At: <https://mailarchive.ietf.org/arch/msg/sframe/81MjGJ6wYzOT_DJsb_zOqHVbKnI>
Subject: Re: [Sframe] Intended DISPATCH outcome / charter
X-BeenThere: sframe@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <sframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sframe>, <mailto:sframe-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sframe/>
List-Post: <mailto:sframe@ietf.org>
List-Help: <mailto:sframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sframe>, <mailto:sframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jul 2020 08:51:12 -0000

On Wed, 2020-07-22 at 12:52 -0400, Richard Barnes wrote:
> Hey Magnus,
> 
> Re signaling / formats: Every byte we add here is pure overhead, so I think my
> opening bid would be to document all the parameters that the senders and
> receivers need to agree on, but punt on actually negotiating/signaling them as
> much as possible.

Ok, I can understand the stance on saying the signalling of the format is for
the transport to carry with the actual SFRAME. However, there is the other
aspect of this question about formats, is if SFRAME will have its own set of
specifications for application data unit formats, and a name space for it.
Encapsulating an RTP payload format is of course possible, and then use that
format name space, but may not be efficient in all cases and duplicates some
functionality that an RTP payload format for SFRAME will need. I want to
understand if the WG intended to create a new name space for format identifiers?

> 
> Re replay: I don't think anything new is needed in the data format (w.r.t.
> current draft), since there's already a counter.  But it would be good to
> recommend that implementations enforce an anti-replay window.

The problematic thing for those who lived through the PERC discussion is that we
have a system where both original sender as well as the SFU may cause
interruption in the transmission schedule. Thus, it is hard to determine if a
gap is reasonable or not and there exist some potentials for attackers to hold
and later play out packets seconds or minutes later. For example if I would say
"no   no" then the attcker could let the first "no" go though. Hold the second
"no" and release that later where it might cause confusion or change the
intended meaning of the conversation. It would not be replay, only delaying. 

Maybe my point is that the WG need to be clear what the security properties and
threat models considered are. 

> 
> Re signatures: I would be comfortable leaving signatures out of scope /
> reserving for future work.  While I agree it would be cool to have the
> additional security property they would provide (per-sender authentication),
> it's not clear to me that it needs to be part of the initial version here.

Just trying to understand scope here. Appears something people need to form a
consensus about in which direction the WG should go here. 

Cheers

Magnus

> 
> --Richard
> 
> On Wed, Jul 22, 2020 at 7:10 AM Magnus Westerlund <
> magnus.westerlund@ericsson.com> wrote:
> > Hi,
> > 
> > Some questions about this charter proposal. It seems to to say simply that
> > the
> > WG will define an encryption and authentication encapsulation of a media
> > ADU. 
> > 
> > It will not take into consideration of how it can be used in any existing
> > real-
> > time media distrubution system, such as transported over RTP signalled by
> > SIP,
> > WebRTC, RTSP etc. Or for that matter how one sticks it in an ISO based media
> > file format that dominates the streaming world, and also live streaming. 
> > 
> > Shouldn't at least this work decide if the content of a SFRAME will contain
> > information to identify the format of the protected ADU, or if that is
> > required
> > to be done externally, or support both? 
> > 
> > I think this is part of a fundamental quesiton about the utility of the
> > format
> > and how one can use it. Having something internally also then raises the
> > question of what namespace to use. 
> > 
> > Also how are other meta data that is relevant to prevent attack such as
> > replay
> > are this included?
> > 
> > I did note that the referenced draft do discuss signatures also. Is this
> > intended to be included or not. With SRTP with the exception of the TESLA
> > cipher
> > SRTP has not really had the property that a receiver can know which sender
> > within a conference that actually sent the media, only that it was someone
> > within the group that had the group key. As signature likely has additional
> > requirement on the key-exchange protocol as it would need to provide
> > assymetric
> > keys for the signature verification for each participant rather than just
> > group
> > keying material I think if this intended to be included should be mentioned
> > explicitly.
> > 
> > Cheers
> > 
> > Magnus
> > 
> > 
> > On Tue, 2020-07-21 at 16:46 -0400, Richard Barnes wrote:
> > > Hey all,
> > > 
> > > I see that SFrame is on the DISPATCH agenda.  Great idea, thanks to
> > whomever
> > > arranged that.
> > > 
> > > In my experience, DISPATCH proposals have gone more smoothly when they've
> > had
> > > a proposed resolution in mind.  Recall that the DISPATCH outcomes are
> > roughly:
> > > 
> > > 0. Do nothing
> > > 1. Existing working group
> > > 2. AD sponsorship
> > > 3. New WG
> > > 
> > > My inclination is that this work is probably about the right size for its
> > own
> > > small, focused working group.  Toward that goal, I've gone ahead and
> > sketched
> > > a charter for the WG here:
> > > 
> > > 
> > 
https://docs.google..com/document/d/10rG8nAR0U6cBBPffzXnLaPPYL4uzxYViAvgiSezoa7o/edit?usp=sharing
> > > 
> > > I think that captures everything I think is important to get done here. 
> > But
> > > please feel free to comment there (or here) if you think the scope is
> > wrong.
> > > 
> > > Cheers,
> > > --Richard
-- 
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
----------------------------------------------------------------------