From nobody Thu Oct 1 14:27:17 2020 Return-Path: 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 DC5103A086B for ; Thu, 1 Oct 2020 14:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Unwxel98XFW1 for ; Thu, 1 Oct 2020 14:27:09 -0700 (PDT) Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87DE13A095F for ; Thu, 1 Oct 2020 14:27:09 -0700 (PDT) Received: by mail-yb1-xb32.google.com with SMTP id x8so5074643ybe.12 for ; Thu, 01 Oct 2020 14:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FwMdrVMrDdv+Y53NiGwvO51/ZjO6x52D74q+xWPFEK8=; b=pVaDAKoZvKoi7gvyHfp/jmD6OAJGyukp9NSD0tqdS/0a5jpCPDzKiUC+HZrL2wUvE6 pBhvKOxYVda32ksgXrpHoKX/ATHgYj7GwS2PSzqsj2CeaUUiTClE/L4u6Cbh/mPRsvqU h+pz7PYJa/kbpa/EkZLbKwy/RAalY82ff7YylH+aLj/AdWcM1oEZBs1RftnqSmVstj9G w9xf1P7IICO6rJCRMou5Pe3PA8vSjhCXVJaom4DBFeqLZynfQVQS0YsWnEVc8XJPZcYP sbRI5j89CPrGkwPk1S40XKRr7JzNKv1EZPLhxq3+cBTXmEbvG12bnV9ghA3THEmYWk1b omzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FwMdrVMrDdv+Y53NiGwvO51/ZjO6x52D74q+xWPFEK8=; b=dRAp+fB0bty3nMcS+tZDnaVdKpMzgpMEvnl+mxXlxRhoox+4PD/T7xq1hn28qUdnYl Z+x+U0D79XOcx9zqQdfaRmA/lvvrIvdU7XYWzl0T9u/Jqq/kX7vTKxryZ6SiDW4+4uUx usWEk+ATR8Qn/2DzpfeYyCJ0f4fjViZ40MP5mXPaVrHG45pcI/GlRJVcPRnLHoplY8Tw 9IP4Vgo6iP2WiMssVQUbnprInHQA6S13AxDeL/gsGweDJ55vBLO2gsaCvOGkcNVotVfw mkT/rjk13Ru/s8SbCx7yANDOrTTyiuJVeONhOkdLWmU1WqkgVigXln5/m18RRo8QxsI2 qbng== X-Gm-Message-State: AOAM533nyTfyTvaQxCjnbTjBjQlxbL4lkD0CiZ7PRErrReAqOL3ldnRj 0U97SwE8gt4XTXUrL6RltyjaRdunZ0w045DDTdjz X-Google-Smtp-Source: ABdhPJwi1BouAmhwE0QXr4xdPj9I7NZffFFeRiA+MuVckAhAS6fKhBJgCPtqaPqG1U1AwKRb6M+edUq0eyBV7ZZI6Aw= X-Received: by 2002:a25:c014:: with SMTP id c20mr12573421ybf.12.1601587628229; Thu, 01 Oct 2020 14:27:08 -0700 (PDT) MIME-Version: 1.0 References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> <5c6c96621b29ebf4b1f84e53ae3a414c9d0ec3a5.camel@ericsson.com> <05085c6c-0c30-a407-8f41-b6c9be8100bc@gmail.com> <49b13e5efa0b2ac0a7b09842dbce8793dfcf6667.camel@ericsson.com> In-Reply-To: From: Emad Omara Date: Thu, 1 Oct 2020 14:26:55 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: Magnus Westerlund , "dispatch@ietf.org" , "sframe@ietf.org" , "rlb@ipv.sx" , "sergio.garcia.murillo@gmail.com" , "iesg@ietf.org" , "sergio.garcia.murillo@cosmosoftware.io" Content-Type: multipart/alternative; boundary="000000000000a8cd9805b0a2adc8" Archived-At: Subject: Re: [Sframe] [dispatch] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 21:27:12 -0000 --000000000000a8cd9805b0a2adc8 Content-Type: text/plain; charset="UTF-8" Hi Murray, I have updated the charter Google doc here Please go ahead and copy it to the datatracker. Thanks Emad On Tue, Sep 29, 2020 at 7:38 AM Murray S. Kucherawy wrote: > On Tue, Sep 29, 2020 at 5:58 AM Magnus Westerlund 40ericsson.com@dmarc.ietf.org> wrote: > >> > Would these address your concerns so we can move forward? Please let me >> know >> > if there is anything else I missed. >> >> Yes, I belief so. >> > > OK, then please let me know when the github version has been updated, and > I'll copy it into the datatracker for the IESG to see. > > -MSK > --000000000000a8cd9805b0a2adc8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Murray,

I have updated the charter G= oogle doc here=C2=A0Please go ahead= and copy it to the datatracker.

Thanks
= Emad

On Tue, Sep 29, 2020 at 7:38 AM Murray S. Kucherawy <superuser@gmail.com> wrote:
On Tue, Sep 29, 2020 at 5:58 AM Magnus Westerlund <magnus.west= erlund=3D40ericsson.com@dmarc.ietf.org> wrote:
> Would these a= ddress your concerns so we can move forward? Please let me know
> if there is anything else I missed.

Yes, I belief so.

OK, then please let = me know when the github version has been updated, and I'll copy it into= the datatracker for the IESG to see.

-MSK
--000000000000a8cd9805b0a2adc8-- From nobody Tue Oct 13 00:22:45 2020 Return-Path: X-Original-To: sframe@ietf.org Delivered-To: sframe@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C4D3A0EC3; Tue, 13 Oct 2020 00:22:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: sframe-chairs@ietf.org, sframe@ietf.org, dispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <160257375965.19700.2194558246070562506@ietfa.amsl.com> Date: Tue, 13 Oct 2020 00:22:40 -0700 Archived-At: Subject: [Sframe] Magnus Westerlund's No Objection on charter-ietf-sframe-00-02: (with COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 07:22:40 -0000 Magnus Westerlund has entered the following ballot position for charter-ietf-sframe-00-02: 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-sframe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks, this update address my significant issues with the charter. I think the charter might be giving a slightly skewed image of the granularity question. To my understanding the application data units (ADU) combined with SFRAMEs properties and the underlying transport will in combination define what granularity that are practical to accomplish. As an example an RTP payload format for SFRAMEs that would support multiple SFRAME objects for a set of ADUs belonging to the same video frame would provide great flexibility in how many SFRAMEs the ADUs are protected in. If each ADU is split into multiple SFRAMES that could be supported but maybe unnecessary as the codec likely are unable to process sub-ADUs, at the same time putting multiple ADUs into one SFRAME requires a seperation to exist above SFRAMEs. This type of questions will be application specific and dependent on underlying layers where to support which functionality. I have the impression that the proponents for SFRAME have a desire to have minimal support for this in SFRAME and rather rely on how the application and the transport is capable of applying SFRAMEs to achieve its confidentiality goals. From nobody Thu Oct 22 08:48:55 2020 Return-Path: X-Original-To: sframe@ietf.org Delivered-To: sframe@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A124A3A0EE0; Thu, 22 Oct 2020 08:48:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: sframe-chairs@ietf.org, sframe@ietf.org, lflynn@amsl.com, superuser@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160338173358.23382.1688098659598283252@ietfa.amsl.com> Date: Thu, 22 Oct 2020 08:48:53 -0700 Archived-At: Subject: [Sframe] sframe - New Meeting Session Request for IETF 109 X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 15:48:54 -0000 A new meeting session request has just been submitted by Liz Flynn, on behalf of the sframe working group. --------------------------------------------------------- Working Group Name: Secure Media Frames Area Name: Applications and Real-Time Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: Technology Overlap: dispatch dmarc avtcore asap extra emailcore stir wpack People who must be present: Murray Kucherawy Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Oct 22 09:14:28 2020 Return-Path: X-Original-To: sframe@ietf.org Delivered-To: sframe@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3994C3A07BD; Thu, 22 Oct 2020 09:14:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Cc: sframe@ietf.org Reply-To: iesg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <160338326215.22717.15213582346810673989@ietfa.amsl.com> Date: Thu, 22 Oct 2020 09:14:22 -0700 Archived-At: Subject: [Sframe] WG Review: Secure Media Frames (sframe) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 16:14:22 -0000 A new IETF WG has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2020-11-01. Secure Media Frames (sframe) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: TBD Assigned Area Director: Murray Kucherawy Applications and Real-Time Area Directors: Barry Leiba Murray Kucherawy 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 configure 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 configured in the protocol. An application using SFrame will need to configure 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 this is configurable) This working group, however, will not specify the signaling required to configure 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. Input to the WG Proposals already existing relating to this charter proposal: https://datatracker.ietf.org/doc/html/draft-omara-sframe-00 Milestones: Jun 2021 - Submit SFrame specification to IESG (Standards Track) From nobody Fri Oct 23 14:19:40 2020 Return-Path: X-Original-To: sframe@ietf.org Delivered-To: sframe@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA0A3A1396; Fri, 23 Oct 2020 14:16:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: sframe@ietf.org, superuser@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160348777817.5087.4569416693169332254@ietfa.amsl.com> Date: Fri, 23 Oct 2020 14:16:18 -0700 Archived-At: Subject: [Sframe] sframe - Requested session has been scheduled for IETF 109 X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 21:16:21 -0000 Dear Liz Flynn, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. sframe Session 1 (2:00 requested) Tuesday, 17 November 2020, Session III 1600-1800 Room Name: Room 2 size: 502 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/109/sessions/sframe.ics Request Information: --------------------------------------------------------- Working Group Name: Secure Media Frames Area Name: Applications and Real-Time Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: Technology Overlap: dispatch dmarc avtcore asap extra emailcore stir wpack People who must be present: Murray Kucherawy Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Oct 28 07:43:21 2020 Return-Path: X-Original-To: sframe@ietf.org Delivered-To: sframe@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A893A09C5; Wed, 28 Oct 2020 07:43:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba via Datatracker To: "The IESG" Cc: sframe-chairs@ietf.org, sframe@ietf.org, dispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <160389619554.26154.17310005023276866720@ietfa.amsl.com> Date: Wed, 28 Oct 2020 07:43:15 -0700 Archived-At: Subject: [Sframe] Barry Leiba's No Objection on charter-ietf-sframe-00-02: (with COMMENT) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 14:43:16 -0000 Barry Leiba has entered the following ballot position for charter-ietf-sframe-00-02: 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-sframe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I wonder whether this should be chartered in the Sec Area with an ART AD (Murray) set as responsible AD. I also think the last bit: Input to the WG Proposals already existing relating to this charter proposal: https://datatracker.ietf.org/doc/html/draft-omara-sframe-00 ...shouldn't be in the final charter text (it was fine to have it there during review). The draft is referenced in the milestone, and that should cover it.