Re: [Sframe] WG Action: Formed Secure Media Frames (sframe)

Martin Thomson <mt@lowentropy.net> Sun, 08 November 2020 23:33 UTC

Return-Path: <mt@lowentropy.net>
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 39A8E3A0FD2 for <sframe@ietfa.amsl.com>; Sun, 8 Nov 2020 15:33:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, 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 (2048-bit key) header.d=lowentropy.net header.b=Bq6flvSo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WL1y9mng
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 1HUYODMuVafY for <sframe@ietfa.amsl.com>; Sun, 8 Nov 2020 15:33:19 -0800 (PST)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CABB3A0FD1 for <sframe@ietf.org>; Sun, 8 Nov 2020 15:33:16 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 5F8DAEBC for <sframe@ietf.org>; Sun, 8 Nov 2020 18:33:15 -0500 (EST)
Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Sun, 08 Nov 2020 18:33:15 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm3; bh=l69Ch qJNOjGBCSke63X8ZXtr9TdopGP+lJotjqOLzvk=; b=Bq6flvSogE2/NYK9To0ya 7H1BlQ/WByGdPDVNbJuzjAf1QgwZ/ULDd1bFlNx6wcu/UjtfqmiaNlnEBWUS8ohQ 3LM70mmVFw40EsG84t/cgEiONRjvlNjC760Um0qc145g73Nnf46Zr/glkuRmLGaw RvDhTj7wYZxgXgSksRUfr9LlONK/qaVSll149YFrk1MHCe5+SySmlG68Oa4yckEg uDa91yrv0QPR4zTBb+FeHNMXrRwT+oEQslJYb2VMrl/DKAqZkRVn9zBw7h3SKEGc BgxtjmLTor8ExJD8wXHgsXAZhJniHFPV9F7dDJW5fEDLzJyy3Ha5v3oiNvpKZHkC Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=l69ChqJNOjGBCSke63X8ZXtr9TdopGP+lJotjqOLz vk=; b=WL1y9mngT5nXMoVpDRDT3T4P0Zs/e3AmIIEyOQYW6GwmbcmgndBYvhr4G rCQZaBi753Z70d2WJsIpSctb7jYNxDhHdkrsS/rHHJaAJIgHe9UtT19FDm9NzOHA inmhmcanVNtR6q0bQjTmHWwIvkLD0A+oqc0mnnnZZBT2Rx9gVefdXJalDYZWVigt e8a5DuKbSKlBssUFaFJVzj+52FG7KkUW7IMv/uUwADFDffs2KPw4nBbiB3pfEOG1 AT+/4ULIW2oJKef1ilI7qvcEQ/WGqIUc7ebqzUG3gZJ3VIoFuFIXPAHcf/jAFARd 6Hvvx3vuNFTUR0aHYLwVxWlqDsb8Q==
X-ME-Sender: <xms:OoCoX0i_13qp4Z4n3TKXeBPr9_qyMfXb_R9mEie5DgGy0OEnfUu05g> <xme:OoCoX9A9DTL9JG10YFAzw7e2rpX89JLCScuF3A2rQFq4H1k2OYJH9z7syTBinKCUH IC08rjNTBLZaxXI7HQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddugedgudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepvedtveejudeigffhue eguedvtdfhffeitdekgeeuheffleevjeduvdekfefhieegnecuffhomhgrihhnpehivght fhdrohhrghdpmhgvvghtvggthhhordgtohhmpdhgihhthhhusgdrtghomhenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhht rhhophihrdhnvght
X-ME-Proxy: <xmx:OoCoX8GJTIjxtDQsO8YKZfyviDBNEI3yPZc2fDQb2XJCABgJaTvhmA> <xmx:OoCoX1R5KW1iMMCusvTmAYSCh5irVT8O1NCGT0h1DYZj5VIBQY1GGg> <xmx:OoCoXxzlXaumabcHDXn_RWIWRTpGA6Mi2s_JZoLo66MJUNWtNV1ODQ> <xmx:OoCoXw_LVb8GCOjy8JGzoUI8BwZo5hdnHQUGc2dJL_m_6Gn2Q6QUqQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 847F420093; Sun, 8 Nov 2020 18:33:14 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-570-gba0a262-fm-20201106.001-gba0a2623
Mime-Version: 1.0
Message-Id: <b24516c2-95a8-4efe-8272-b6da0d1c06c1@www.fastmail.com>
In-Reply-To: <160468973464.30968.15143783219177718112@ietfa.amsl.com>
References: <160468973464.30968.15143783219177718112@ietfa.amsl.com>
Date: Mon, 09 Nov 2020 10:32:55 +1100
From: "Martin Thomson" <mt@lowentropy.net>
To: sframe@ietf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sframe/hFJPSYDs5NXqGXIYYbOgNLTbJYs>
Subject: Re: [Sframe] WG Action: Formed Secure Media Frames (sframe)
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: Sun, 08 Nov 2020 23:33:21 -0000

Hey everyone,

After consultation with a few people, I've posted an initial agenda (included below).  If you have any thoughts on this and how we might better use the two hours we have, any input is welcome.

See also https://datatracker.ietf.org/doc/agenda-109-sframe/

## Meeting Details

Tuesday Session III (16:00-18:00 UTC+7, 09:00-11:00 UTC)
Chairs: Bobo Bose-Kolanu, Martin Thomson

Resources:

* [Minutes](https://codimd.ietf.org/notes-ietf-109-sframe)
* [Chat](xmpp:sframe@jabber.ietf.org?join)
* [Video Stream](https://meetings.conf.meetecho.com/ietf109/?group=sframe&short=&item=1)
* [Calendar](https://datatracker.ietf.org/meeting/109/session/28496.ics)
* [Materials](https://github.com/sframe-wg/wg-materials)


## Agenda

| Item             | People                 | Time |
| :--------------- | :--------------------- | ---: |
| Introduction     | Chairs                 |    5 |
| Charter Review   | Chairs                 |   10 |
| Use Cases        |                        |      |
| - Conferencing   | Emad Omara             |   10 |
| - Streaming      | Dr. Alex Gouaillard    |   10 |
| - WebRTC         | Youenn Fablet          |   10 |
| Protection       | Emad Omara             |   30 |
| - Video Payloads | Sergio Garcia Murrillo |   20 |
| MLS Integration  | Richard Barnes         |   20 |
| AOB              | -                      |    ~ |

## Documents

[draft-omara-sframe](https://datatracker.ietf.org/doc/html/draft-omara-sframe-00)

On Sat, Nov 7, 2020, at 06:08, The IESG wrote:
> A new IETF WG has been formed in the Applications and Real-Time Area. For
> additional information, please contact the Area Directors or the WG Chairs.
> 
> Secure Media Frames (sframe)
> -----------------------------------------------------------------------
> Current status: Proposed WG
> 
> Chairs:
>   Bobo Bose-Kolanu <the.bobo@gmail.com>
>   Martin Thomson <mt@lowentropy.net>
> 
> Assigned Area Director:
>   Murray Kucherawy <superuser@gmail.com>
> 
> Applications and Real-Time Area Directors:
>   Barry Leiba <barryleiba@computer.org>
>   Murray Kucherawy <superuser@gmail.com>
> 
> Mailing list:
>   Address: sframe@ietf.org
>   To subscribe: https://www.ietf.org/mailman/listinfo/sframe
>   Archive: https://mailarchive.ietf.org/arch/browse/sframe/
> 
> Group page: https://datatracker.ietf.org/group/sframe/
> 
> Charter: https://datatracker.ietf.org/doc/charter-ietf-sframe/
> 
> Real-time conferencing sessions increasingly require end-to-end protections
> that prevent intermediary servers from decrypting real-time media.  The PERC
> WG developed a “double encryption” scheme for end-to-end encryption that was
> deeply tied to SRTP as its underlying transport.  This entanglement has
> prevented widespread deployment.
> 
> This working group will define the SFrame secure encapsulation to provide
> authenticated encryption for real-time media content that is independent of
> the underlying transport.  The encapsulation will provide the following
> information to drive the authenticated encryption for each encryption
> operation:
> 
> * Selection among multiple encryption keys in use during a real-time session
> 
> * An algorithm for forming a unique nonce within the scope of the key based
> on information in the encapsulation framing
> 
> The SFrame specification will detail the specific security properties that
> the encapsulation provides, and discuss their implications under common usage
> scenarios / threat models.
> 
> The transport-independence of this encapsulation means that it can be applied
> at a higher level than individual RTP payloads.  For example, it may be
> desirable to encrypt whole frames that span multiple packets in order to
> amortize the overhead from framing and authentication tags.  It may also be
> desirable to encrypt units of intermediate size (e.g., H.264 NALUs or AV1
> OBUs) to allow partial frames to be usable.  The working group will choose
> what levels of granularity can be selected in the protocol.
> 
> An application using SFrame will need to choose several aspects of its
> operation, for example:
> 
> * Selecting whether SFrame is to be used for a given media flow
> 
> * Specifying which encryption algorithm should be used
> 
> * Provisioning keys and key identifiers to endpoints
> 
> * Selecting the granularity at which SFrame encryption is applied (if
> multiple options are available)
> 
> This working group, however, will not specify the signaling required to
> arrange SFrame encryption.  In particular, considerations related to SIP or
> SDP are out of scope.  This is because SFrame is intended to be applied as an
> additional layer on top of the base levels of protection that these protocols
> provide.  This working group will, however, define the guidance for how
> SFrame interacts with RTP (e.g., with regard to packetization,
> depacketization, and recovery algorithms) to ensure that it can be used in
> environments such as WebRTC.  Other WebRTC changes such as the payload format
> and metadata format will be addressed by the AVTCORE working group.
> 
> It is anticipated that several use cases of SFrame will involve its use with
> keys derived from the MLS group key exchange protocol.  The working group
> will define a mechanism for doing SFrame encryption using keys from MLS,
> including, for example, the derivation of SFrame keys per MLS epoch and per
> sender.  The availability of this mechanism for using keys from MLS does not
> preclude the use of other sources of key material.
> 
> Milestones:
> 
>   Jun 2021 - Submit SFrame specification to IESG (Standards Track)
> 
> 
> 
>