From nobody Sun Oct 10 16:36:26 2021 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 421C93A1272 for ; Sun, 10 Oct 2021 16:36:23 -0700 (PDT) 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=W2Kf5p3Y; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bnhUEIep 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 kGcYKJP5CbhQ for ; Sun, 10 Oct 2021 16:36:17 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 683FC3A126E for ; Sun, 10 Oct 2021 16:36:17 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id AAA95320051E for ; Sun, 10 Oct 2021 19:36:14 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Sun, 10 Oct 2021 19:36:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm3; bh=V/cqWMaKyGO06P2DY4zIt/CTY69Rton3WJlChzXjRYI=; b=W2Kf5p3Y uwXyFydJxJQPQfLpoDORnlEV8UXrwNJn4aHRKA19Aet63Bwhe4QBaClt+Cv2rhcN ygSplF5IOCTL4O3xqYOnwufbbEARGiJgFFpnxl9AG8iyLgNs+jlOUvHOm+cARjfd 61m1FCMZmjQHrVzPbqTVFpBcymHShghJPfyNw3aFsK0d7OcT+fVEcJ4tjlf8rNf8 SbYDPYypuHHeIdsltM+S3zxU9G5mHs/Aox/UxX5b7rzLOiSe0nUI6WMwqhRMkhC7 M21hRMiAcQXx25MjuPFT36xvYlJZNZmup5S42zPY0oSEASyCBAqZhajaL0uop1/h Y2z2B0+mNosJVA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=V/cqWMaKyGO06P2DY4zIt/CTY69Rt on3WJlChzXjRYI=; b=bnhUEIep36V1T2h+adFB0A+Jczx1B4Zfo+5h7Z1eIK6E3 3kuTIabbQyb/CPDIIebNcK1LjVAAgNE4DFxcu2WIYLPnwazFNJdnyVs6RhU0FIGa +Q5n3p+XU9dNUlyWLZ3wvBG/oASwWAKzASxvUrWrfRH483gry4kI33qNi2Et/1Z7 KdgRvZDU8tAfs+PMWbNKaPVaLyQg2JWt7QtjwPL75O5FOk2dl6KqrS83m0aU9LOu b7umWB5FjnW7/veMdYaS9QHSCpZU1OWJXxG9zq5rYg0ewuuIlt7YN/0wleYC0vcA gdXupy6VkTylRMGIE1tOmdawlFBZH47d6u1lE0WwQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddthedgvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsehttdertd erredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigv nhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpefgheeigefgieelkefhtdfhtd ffgeejffdvkedufffgledtudejhfeiiefhhfevgeenucffohhmrghinhepihgvthhfrdho rhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmh htsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1B76C3C0246; Sun, 10 Oct 2021 19:36:14 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1331-g5ae342296a-fm-20211005.001-g5ae34229 Mime-Version: 1.0 Message-Id: <7e721f57-e7ee-4f47-8663-2b485aeabd1a@www.fastmail.com> Date: Mon, 11 Oct 2021 10:35:54 +1100 From: "Martin Thomson" To: sframe@ietf.org Content-Type: text/plain Archived-At: Subject: [Sframe] Adoption call for draft-omara-sframe-01 X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2021 23:36:24 -0000 https://datatracker.ietf.org/doc/html/draft-omara-sframe-01 Please respond to this email before AOE 31 October 2021 if you support adopting draft-omara-sframe (currently -01) as a working group item. If you would prefer we not adopt this work, please respond with an explanation of why and ideally what you would like to see addressed before we do that. We're running this a tiny bit longer than a typical adoption call. Last time we talked about adoption there were a few concerns raised about the draft. We want to make sure those concerns are addressed, or at least those with concerns are satisfied that their concerns could be addressed. Martin, for the chairs From nobody Mon Oct 11 01:38:10 2021 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 77D6D3A0BCE for ; Mon, 11 Oct 2021 01:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=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=jitsi-org.20210112.gappssmtp.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 cAJd7Z6fABvc for ; Mon, 11 Oct 2021 01:38:04 -0700 (PDT) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 B8C813A0BCC for ; Mon, 11 Oct 2021 01:38:03 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id p13so65325703edw.0 for ; Mon, 11 Oct 2021 01:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20210112.gappssmtp.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=MCJj7ofmudo+Nd44zl7ecdA0rmB5QrzFr7w/eUYocjA=; b=nVarpeCWjhWsIXhpTWU876ysqA7z174li/Z3DTC426KemTLOShGRKgnDkOU5ZsyEGd B68B8wxRXlSn249kjwVPA6VL/jkFIbXhlQNIdJmjmWee9QJrku38hursxq2EpI4FD7tk VUvB+yPwsq0tDzOJtj465EAtrvynUKUUYTaDW9R8Q2gi5fjqVq8hEytUJXZncP7Lbt3M Ltjxhy5dOLAEeVnrOc6gj/JpZnFYzbCi5oiWMUMlMP2ZGnBmlzbZ+lqLkwojnFTMeCIq x61h+8JG8ZvXiGtXFWr25GYucWxQ0KmRnW/BUKrOcdJGkAXdkNdU0ZnHW1d25x+cLm3e /y8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MCJj7ofmudo+Nd44zl7ecdA0rmB5QrzFr7w/eUYocjA=; b=Fa+qREZHODBw/eeXPzpQ0UX/J8dUtqwckm5ZnA/H1d49bGYD5ts1CPIf7uAgrnZPdc az/N31bQiiHnwQc7QLVKlqoOVrS8F7EhLmqAliVgv2bc1p6QygrjMfaD7Azxh5bSAGCQ tC8fosSxl80GkRYVlbAjL08kLZzak8ve4trqk6msoFXzWYwURcnyYIgNP4S8bE0eNzEB hG0BtFLj8uBx/8nE7dQ8BFWSpSe2uFeeh0zNRYYCmfX400oK/vf+umauLQWOzOc6S/5x sUPRO2UWGCRz4s2+96T3xxAPDpUD6C9+DMkM2FdzBJvG8kf7VHbozyTRk1Zue0iUSVhq SrfA== X-Gm-Message-State: AOAM530uKJWchNOvgHaqwWdn6wwppr+d4Vr0d9cAf91FITrb2X9yLS9r L1n1kdcMw7y+97BnhabfUFUqNltkM/u+Lw== X-Google-Smtp-Source: ABdhPJxfMK9Ep/mYVrn3o+pS0xjFlppPV6z8kxPWz8W63wL5kwUoVECDt6PU/TsXumcXDjskkTPGmQ== X-Received: by 2002:a50:e14c:: with SMTP id i12mr38914899edl.125.1633941481022; Mon, 11 Oct 2021 01:38:01 -0700 (PDT) Received: from xray.local (a118231.upc-a.chello.nl. [62.163.118.231]) by smtp.gmail.com with ESMTPSA id v23sm199128ejf.68.2021.10.11.01.38.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Oct 2021 01:38:00 -0700 (PDT) To: Martin Thomson , sframe@ietf.org References: <7e721f57-e7ee-4f47-8663-2b485aeabd1a@www.fastmail.com> From: =?UTF-8?Q?Sa=c3=bal_Ibarra_Corretg=c3=a9?= Message-ID: <3ca7b744-10f6-61e3-f2a1-ac621b1ec468@jitsi.org> Date: Mon, 11 Oct 2021 10:37:57 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <7e721f57-e7ee-4f47-8663-2b485aeabd1a@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Sframe] Adoption call for draft-omara-sframe-01 X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2021 08:38:09 -0000 On 11/10/2021 01:35, Martin Thomson wrote: > https://datatracker.ietf.org/doc/html/draft-omara-sframe-01 > > Please respond to this email before AOE 31 October 2021 if you support adopting draft-omara-sframe (currently -01) as a working group item. If you would prefer we not adopt this work, please respond with an explanation of why and ideally what you would like to see addressed before we do that. > > We're running this a tiny bit longer than a typical adoption call. Last time we talked about adoption there were a few concerns raised about the draft. We want to make sure those concerns are addressed, or at least those with concerns are satisfied that their concerns could be addressed. > > Martin, for the chairs > I do support (speaking for Jitsi here) the adoption of the draft. Quick question though: any reason why -01 and not the latest version? Cheers, -- Saúl From nobody Mon Oct 11 02:19:16 2021 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 E21073A0DFE for ; Mon, 11 Oct 2021 02:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_H3=0.001, RCVD_IN_MSPIKE_WL=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=RC8GIU/z; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OuPO0FF9 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 xrVDXXdSmXgo for ; Mon, 11 Oct 2021 02:19:10 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3670B3A0DF3 for ; Mon, 11 Oct 2021 02:19:10 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 9B4D35C00D4; Mon, 11 Oct 2021 05:19:09 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Mon, 11 Oct 2021 05:19:09 -0400 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=rBrB9 IlHdMq+FSkr71IoAzMvCdNoscvd0uyRkZfJ1GU=; b=RC8GIU/zoZakcbhykEJk6 gGxlBJUJOwYtfddpPOon4XErf1UOZCO28SsYrs2wBcwsAk9dLIkq32xzz3WJ2Az2 PUqefmRLW9cqtQg+LnbuQyXVIbZC4X4xrKLbGgdw7U6go1S2apGHOwpwgt9phi24 s7+TvzrRG7QV5Yvi1bffRrE/nitwqaSfYmmSzwAbkMl4+1k0Lv81n1AmLdmQ2els xhvvdicb6ejZxOMHLA2qg1e8D3dwM7XGyL17kLxnreqFMTLyO6wa4qz+ALbH9YQi aPvBMxVswnWyxZCvXtiH23EAfv1C3W6Jbo3D2Cmj7MpNLy6xrFimFRnUut9sRtwf A== 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=rBrB9IlHdMq+FSkr71IoAzMvCdNoscvd0uyRkZfJ1 GU=; b=OuPO0FF9T4yqowB6KultOVcgqeFZwEiX3CSFMmV00imDune+7PQtoUk0Z A+S6Rq7/rA/GmhU15Jetu94/u1H3AJ3rCs3vTPfJGgQ081OyeqSsXctWS392lbZz QSVY9pbjHYR17+Kro/cDMil9hwZXNghZifWf6q10MqOvX4WPtSfV0nyaQN0kvMk2 o4VVpJCGPDoXOEipgMuEDdEA2NYzf7zhQhCvMS7zUz3AjxKGdcFCjpXDYi6aaurq 2G6F2Ke/HBkJ3QYhep6+IdisWTCVy1U7jpVMOizHSeLTiTFxU2l0L/ci+6p68Akn HWKYxrLQpIK9OTn0Dths/PCnuNjng== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddtiedguddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepgfejueduieffledtge elheejvdettdejudduhefggeefgfekgfeuieetgefftddtnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnh gvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5A5CC3C0246; Mon, 11 Oct 2021 05:19:09 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1345-g8441cd7852-fm-20211006.001-g8441cd78 Mime-Version: 1.0 Message-Id: <88b2c300-d0e5-42f1-b77c-2c7ab4a5d09e@www.fastmail.com> In-Reply-To: <3ca7b744-10f6-61e3-f2a1-ac621b1ec468@jitsi.org> References: <7e721f57-e7ee-4f47-8663-2b485aeabd1a@www.fastmail.com> <3ca7b744-10f6-61e3-f2a1-ac621b1ec468@jitsi.org> Date: Mon, 11 Oct 2021 20:18:50 +1100 From: "Martin Thomson" To: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= , sframe@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sframe] Adoption call for draft-omara-sframe-01 X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2021 09:19:15 -0000 On Mon, Oct 11, 2021, at 19:37, Sa=C3=BAl Ibarra Corretg=C3=A9 wrote: > Quick question though: any reason why -01 and not the latest version? My mistake. I meant to cite the latest. From nobody Thu Oct 14 16:30:17 2021 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 8A7D83A1803 for ; Thu, 14 Oct 2021 16:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 upiucyIzMWaM for ; Thu, 14 Oct 2021 16:30:10 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 940AE3A1805 for ; Thu, 14 Oct 2021 16:30:10 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id f3so14595875uap.6 for ; Thu, 14 Oct 2021 16:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A9J5p/pUP8xnsQCzZCCprGgGT+MSL3f1HtI/1yGeqj8=; b=fE63rklJOVHxE2I3jIWnhn7eqUAWgOa9BPSgQVPSzLvGk7xBTtZEs6BpIlg+8okm+r c2s+04xPVTzGqjI5Tc4MTpgHcJWvflgPRV7DNI36I6csJ1GVXTuRqRifJVb+aWnVrSCc igkVRT8R2kl2smBPuoi/gzaWJtY1NMWd6EDe4nHkpbD25CRTs6K8rI99lgobcfPwfcvu 9JmY4U4Brz2cjS1UFcpxJ94mUzUvDYLzyZ8ZZLId+JHDcmUDPnfgsKOb2jm9KB8T9pjJ av9BxjEvlvGYkAYDz8VZUeisT5rv6wuhpr4b9Keu65d6g3CYmNDNRWSy/y/0oB61psBW fg6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A9J5p/pUP8xnsQCzZCCprGgGT+MSL3f1HtI/1yGeqj8=; b=KP9450T/oiKTikCIPwjjaTEs//Jvk9yIpZtggY31SZK8akZxbwuSHhUuj4G4sykABI Ekz9BTtuKk5yiUP72n72EkjT9+nt412ao507j4Jgx+OQduM6VOrOu7pgOR7VdR4fzbJ5 q044hf5mr0DwmDTZnRTvOnLGUsnO0q6h3g9adDi3TlT7+Z7iojLRORL/Le5EBpSeI0j5 rA2mz4nvubfmcaizK0i460eoXJUbJ6rbtiO8vNqnLEL4gEBnreTZg/YhXpp8laP26u9J kO0+pUqP0wN/PfJfTB+xCz+cG1R9GQrxN1EygW0ZIchoHYXDAipNiSoWiOvIwfD/hOpk 5ZnA== X-Gm-Message-State: AOAM532j2OTzWGV04ACH9Kqo1MoQcWAirwQRgoKw+kfQXpWRu+/XfxBm z+hYyWTx9VPdRCq4EtTJEqghWgL7Szeo+dbX1bdKspB5chs= X-Google-Smtp-Source: ABdhPJzBa51q0SSizVd614zzRt9/hXIIaMD5vcVVPVp7BIz3ovp1DOdDz7ZGsuyqdV2fMJl/3oyhwK3bE5ALhLrphCk= X-Received: by 2002:ab0:540e:: with SMTP id n14mr10231833uaa.73.1634254208558; Thu, 14 Oct 2021 16:30:08 -0700 (PDT) MIME-Version: 1.0 References: <7e721f57-e7ee-4f47-8663-2b485aeabd1a@www.fastmail.com> In-Reply-To: <7e721f57-e7ee-4f47-8663-2b485aeabd1a@www.fastmail.com> From: Bernard Aboba Date: Thu, 14 Oct 2021 16:29:57 -0700 Message-ID: To: Martin Thomson Cc: sframe@ietf.org Content-Type: multipart/alternative; boundary="00000000000092e80a05ce5875bf" Archived-At: Subject: Re: [Sframe] Adoption call for draft-omara-sframe-01 X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 23:30:16 -0000 --00000000000092e80a05ce5875bf Content-Type: text/plain; charset="UTF-8" Here is my review. Overall, I do not feel that this document is ready for adoption. Viewed purely as a document focusing on defining the SFrame format, it is adequate. Currently, the document mixes format considerations with key management concerns while not adequately covering the full range of non-RTP use cases. By trying to do too much, the document falls short enough to be potentially detrimental to long term success. In particular, the goals of the effort, the threat model and the use cases are not articulated well enough. My advice would be to pare the draft down to its bare essentials, spinning off material not directly relevant to the SFrame format into a separate document. The non-RTP use cases (and potential integration with the Web media model) in particular seem like they deserve more attention. Section 1 states: In order for the SFU to work properly though, it needs to be able to access RTP metadata and RTCP feedback messages, which is not possible if all RTP/RTCP traffic is end-to-end encrypted.... This document proposes a new end-to-end encryption mechanism known as SFrame, specifically designed to work in group conference calls with SFUs. Later in Section 1, Figure 1 is included, showing the SRTP packet format. So Section 1 is very RTP (and conferencing) centric. Yet at the same time, Section 3 includes the following goals: 2. Decouple media encryption from key management to allow SFrame to be used with an arbitrary KMS. 4. Independence from the underlying transport, including use in non- RTP transports, e.g., WebTransport. Is SFrame serious about these goals? Personally, I hope so - but if so, integration with the existing Web media framework as well as new APIs (such as WebCodecs) needs to be considered. In doing so, use cases will likely expand beyond conferencing, to things like low-latency streaming (for things like events, webinars, game watching, etc.) The existing Web media framework (as embodied by APIs such as MSE and EME) supports both transport and key management independence, so seeking these same goals for SFRAME seems quite natural. For example, today it is possible to transport containerized media for a wide range of codecs using any transport, including WebTransport and RTCData channel. Once transported, the media is decoded and rendered using MSE. And of course, the containerized media can also be protected. Note that the protection model addresses additional classes of attack beyond those that might be executed by an SFU. For example, cleartext media is not accessible to Javascript, mitigating against attacks such as "deep fakes". Why bother to consider these use cases for SFrame? APIs such as WebCodecs do not operate on containerized media, so there is a need to define a format allowing encrypted but non-containerized media to be carried over the wire. If that format is not SFrame, then an equivalent will need to be invented, covering the same codecs that SFrame seeks to support (e.g. Opus, H.264, VP8, VP9, AV1) plus maybe a few others (e.g. AAC). The benefit of working towards integration with the existing Web media framework is that this will be more likely to lead to implementation and deployment. This shouldn't be hard to accommodate within a document that focuses purely on the format, allowing the use cases and threat models to be articulated elsewhere. On Sun, Oct 10, 2021 at 4:36 PM Martin Thomson wrote: > https://datatracker.ietf.org/doc/html/draft-omara-sframe-01 > > Please respond to this email before AOE 31 October 2021 if you support > adopting draft-omara-sframe (currently -01) as a working group item. If > you would prefer we not adopt this work, please respond with an explanation > of why and ideally what you would like to see addressed before we do that. > > We're running this a tiny bit longer than a typical adoption call. Last > time we talked about adoption there were a few concerns raised about the > draft. We want to make sure those concerns are addressed, or at least > those with concerns are satisfied that their concerns could be addressed. > > Martin, for the chairs > > -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --00000000000092e80a05ce5875bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here is my review.=C2=A0

Overall, I do = not feel that this document is ready for adoption.=C2=A0 Viewed purely as a= document focusing on defining the SFrame format, it is adequate.=C2=A0 Cur= rently, the document mixes format considerations with key management concer= ns while not=C2=A0adequately covering the full range of non-RTP use cases.= =C2=A0 By trying to do too much, the document falls short enough to be pote= ntially detrimental to long term success.=C2=A0

In= particular, the goals of the effort, the threat model and the use cases ar= e not articulated well enough. My advice would be to pare the draft down to= its bare essentials, spinning off material not directly relevant to the SF= rame format into a separate document.

The non= -RTP use cases (and potential integration with the Web media model) in part= icular seem like they deserve more attention.=C2=A0

Section 1 states:=C2=A0

   In order for the SFU to work
   properly though, it needs to be able to access RTP metadata and RTCP
   feedback messages, which is not possible if all RTP/RTCP traffic is
   end-to-end encrypted....

   This document proposes a new end-to-=
end encryption mechanism known as
   SFrame, specifically designed to work in group conference calls with
   SFUs.

Later in Section 1, Figure 1 is included, showing the=C2=A0SRT=
P packet format.=C2=A0 So Section 1 is very RTP (and conferencing) centric.=
=C2=A0 Yet at the same time, Section 3 includes the following goals:=C2=A0<=
/span>

   2.  Decouple media =
encryption from key management to allow SFrame to
       be used with an arbitrary KMS.

   4.=
  Independence from the underlying transport, including use in non-
       RTP transports, e.g., WebTransport.

Is SFrame serious abo=
ut these goals?=C2=A0 Personally, I hope so - but if so, integration with t=
he existing Web media framework as well as new APIs (such as WebCodecs) nee=
ds to be considered.=C2=A0 In doing so, use cases will likely expand beyond=
 conferencing, to things like low-latency streaming (for things like events=
, webinars, game watching, etc.)

=

The existing Web media framework (as embodied by APIs suc=
h as MSE and EME) supports both transport and key management independence, =
so seeking these same goals for SFRAME seems quite natural.=C2=A0 For examp=
le, today it is possible to transport containerized media for a wide range =
of codecs using any transport, including WebTransport and RTCData channel.=
=C2=A0 Once transported, the media is decoded and rendered using MSE.=C2=A0=
 And of course, the containerized media can also be protected. Note that th=
e protection model addresses additional classes of attack beyond those that=
 might be executed by an SFU. For example, cleartext media is not accessibl=
e to Javascript, mitigating against attacks such as "deep fakes".=
=C2=A0

Why bother to c=
onsider these use cases for SFrame?=C2=A0 APIs such as WebCodecs do not ope=
rate on containerized media, so there is a need to define a format allowing=
 encrypted but non-containerized media to be carried over the wire. If that=
 format is not SFrame, then an equivalent will need to be invented, coverin=
g the same codecs that SFrame seeks to support (e.g. Opus, H.264, VP8, VP9,=
 AV1) plus maybe a few others (e.g. AAC).=C2=A0
The benefit of working towards integration with t=
he existing Web media framework is that this will be more likely to lead to=
 implementation and deployment.=C2=A0 This shouldn't be hard to accommo=
date within a document that focuses purely on the format, allowing the use =
cases and threat models to be articulated elsewhere.=C2=A0







On Sun, Oct 10, 2021 at 4:36 PM Martin Thomso= n <mt@lowentropy.net> wrote:=
https://datatracker.ietf.org/doc/html/draft-omara-sframe= -01

Please respond to this email before AOE 31 October 2021 if you support adop= ting draft-omara-sframe (currently -01) as a working group item.=C2=A0 If y= ou would prefer we not adopt this work, please respond with an explanation = of why and ideally what you would like to see addressed before we do that.<= br>
We're running this a tiny bit longer than a typical adoption call.=C2= =A0 Last time we talked about adoption there were a few concerns raised abo= ut the draft.=C2=A0 We want to make sure those concerns are addressed, or a= t least those with concerns are satisfied that their concerns could be addr= essed.

Martin, for the chairs

--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--00000000000092e80a05ce5875bf-- From nobody Thu Oct 14 23:34:22 2021 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 4456F3A1488 for ; Thu, 14 Oct 2021 23:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=cosmosoftware-io.20210112.gappssmtp.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 MRSKq5vrqKoE for ; Thu, 14 Oct 2021 23:28:56 -0700 (PDT) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 DB94E3A0A70 for ; Thu, 14 Oct 2021 23:28:55 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id gn3so1013689pjb.0 for ; Thu, 14 Oct 2021 23:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cosmosoftware-io.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WbCOIXzF5FaLwFagq7lgM8wZ7rruHynbwxhA72cUtwc=; b=vM7H1R4bqbbXEMp4MxJnaHG3VX3OEYmG4+z0bUe5jkLGZwmnNbeE04fgRV6O/hi4JJ fk14yzjNIXlk214YrBT1LfONhwfG/P2U8ksN6ypw4U2+rCuLxYS39f+1fZOhWhQN28Zj p6ZfABlqQ1aAx1wqvCW/6zNZjfRH8/JhUVBWCC+YzRkuQRwRO2zUEdZ0eeSB0FwO3RFk Z8Xq2Kda1ZDvcEVIMlw3Ai32G+xKvWnKNli7tsVdhjICFBsmEZQgtL+tZZVjlbqz9/wx 4DKQkMKuqjOLVwGz2j4ObYnnhLcEGoSrEM/Gu1A4HbPVngbKTOsPCi5gv9NouHLBK2PW KTBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WbCOIXzF5FaLwFagq7lgM8wZ7rruHynbwxhA72cUtwc=; b=xklopH3AjTLm7XGMQmkntBlB+j1hkA+VMHMAen6TAi3NXe55jKcd2ZXwwjU2m5f9ce 68gERM3OxJXRSrVkFW10FtlPotLDp/n9qJJlUmp6O9YwEcDr8nAkWWnmsGXlPNNAaDiU gCmolYG+4MJXPblWZPSAo5Px1Pw8N+4QL1R2h9dzOfq3FGPfjL6Gw+pLCrR1IfAcMoB8 EUNp50TmWYV+9NMHrYJ0Z4o0QiDNkrmfEJK3f++DXHkVqdjMKECM/wQm6xTraVlKoxGq uPED9jHEs5113SBUg307iVOpCuEHHEF7/UIH8Utr37XUXM8SsOI/N351xlCChQ7Km5yL 0Pjw== X-Gm-Message-State: AOAM530R860GPbsxm+i2sL5EwQyJXh5wrO/pll0wr1dC+ickJvr1eZ5g gYgH0F6lLXEzqPK/b2BinJ0F3K9wypUsctBTrAcBXQ== X-Google-Smtp-Source: ABdhPJxfW+An4nv+ToyseWTzPVPU6swR0yb3E1QUAA6h0k1AwT0iBwm1qumOxCMWWobkthKSYl5xHobKZOxzqOoaF6A= X-Received: by 2002:a17:902:d501:b0:13f:1b44:baa2 with SMTP id b1-20020a170902d50100b0013f1b44baa2mr9370091plg.56.1634279334804; Thu, 14 Oct 2021 23:28:54 -0700 (PDT) MIME-Version: 1.0 References: <7e721f57-e7ee-4f47-8663-2b485aeabd1a@www.fastmail.com> In-Reply-To: From: Sergio Garcia Murillo Date: Fri, 15 Oct 2021 08:28:43 +0200 Message-ID: To: Bernard Aboba Cc: Martin Thomson , sframe@ietf.org Content-Type: multipart/alternative; boundary="0000000000003713ce05ce5e4f44" Archived-At: Subject: Re: [Sframe] Adoption call for draft-omara-sframe-01 X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 06:29:01 -0000 --0000000000003713ce05ce5e4f44 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bernard, Trying to understand the changes that would be required in order to address your concerns. If I understand correctly, you are proposing splitting the document in 3 or 4 documents: - SFrame architecture & overview, explaining the use cases, thread models and key management considerations - SFrame format and encryption process (based on the current draft) - SFrame usage within WebRTC - SFrame usage within frame based transports Is that correct? Regarding the integration with frame based transports (i.e. quic or webtransport, webrtc DC or even rtmp), the charter only mentions that WebRTC end to end solution for webrtc should be explicitly addressed. This is mainly because applying SFrame to webtransport/quic should be straightforward and trivial. What topics do you think needs to be addressed or explained in detail for web transport for example? Best regards Sergio On Fri, Oct 15, 2021 at 1:30 AM Bernard Aboba wrote: > Here is my review. > > Overall, I do not feel that this document is ready for adoption. Viewed > purely as a document focusing on defining the SFrame format, it is > adequate. Currently, the document mixes format considerations with key > management concerns while not adequately covering the full range of non-R= TP > use cases. By trying to do too much, the document falls short enough to = be > potentially detrimental to long term success. > > In particular, the goals of the effort, the threat model and the use case= s > are not articulated well enough. My advice would be to pare the draft dow= n > to its bare essentials, spinning off material not directly relevant to th= e > SFrame format into a separate document. > > The non-RTP use cases (and potential integration with the Web media model= ) > in particular seem like they deserve more attention. > > Section 1 states: > > In order for the SFU to work > properly though, it needs to be able to access RTP metadata and RTCP > feedback messages, which is not possible if all RTP/RTCP traffic is > end-to-end encrypted.... > > > This document proposes a new end-to-end encryption mechanism known as > SFrame, specifically designed to work in group conference calls with > SFUs. > > > Later in Section 1, Figure 1 is included, showing the SRTP packet format.= So Section 1 is very RTP (and conferencing) centric. Yet at the same tim= e, Section 3 includes the following goals: > > > 2. Decouple media encryption from key management to allow SFrame to > be used with an arbitrary KMS. > > > 4. Independence from the underlying transport, including use in non- > RTP transports, e.g., WebTransport. > > > Is SFrame serious about these goals? Personally, I hope so - but if so, = integration with the existing Web media framework as well as new APIs (such= as WebCodecs) needs to be considered. In doing so, use cases will likely = expand beyond conferencing, to things like low-latency streaming (for thing= s like events, webinars, game watching, etc.) > > > The existing Web media framework (as embodied by APIs such as MSE and EME= ) supports both transport and key management independence, so seeking these= same goals for SFRAME seems quite natural. For example, today it is possi= ble to transport containerized media for a wide range of codecs using any t= ransport, including WebTransport and RTCData channel. Once transported, th= e media is decoded and rendered using MSE. And of course, the containerize= d media can also be protected. Note that the protection model addresses add= itional classes of attack beyond those that might be executed by an SFU. Fo= r example, cleartext media is not accessible to Javascript, mitigating agai= nst attacks such as "deep fakes". > > > Why bother to consider these use cases for SFrame? APIs such as WebCodec= s do not operate on containerized media, so there is a need to define a for= mat allowing encrypted but non-containerized media to be carried over the w= ire. If that format is not SFrame, then an equivalent will need to be inven= ted, covering the same codecs that SFrame seeks to support (e.g. Opus, H.26= 4, VP8, VP9, AV1) plus maybe a few others (e.g. AAC). > > > The benefit of working towards integration with the existing Web media fr= amework is that this will be more likely to lead to implementation and depl= oyment. This shouldn't be hard to accommodate within a document that focus= es purely on the format, allowing the use cases and threat models to be art= iculated elsewhere. > > > > > > > > > On Sun, Oct 10, 2021 at 4:36 PM Martin Thomson wrote: > >> https://datatracker.ietf.org/doc/html/draft-omara-sframe-01 >> >> Please respond to this email before AOE 31 October 2021 if you support >> adopting draft-omara-sframe (currently -01) as a working group item. If >> you would prefer we not adopt this work, please respond with an explanat= ion >> of why and ideally what you would like to see addressed before we do tha= t. >> >> We're running this a tiny bit longer than a typical adoption call. Last >> time we talked about adoption there were a few concerns raised about the >> draft. We want to make sure those concerns are addressed, or at least >> those with concerns are satisfied that their concerns could be addressed= . >> >> Martin, for the chairs >> >> -- >> Sframe mailing list >> Sframe@ietf.org >> https://www.ietf.org/mailman/listinfo/sframe >> > > --0000000000003713ce05ce5e4f44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Bernard,

= Trying to understand the changes that would be required in order to address= your concerns. If I understand correctly, you are proposing splitting=C2= =A0the document in 3 or 4 documents:

- SFrame arch= itecture & overview, explaining the use cases, thread models and key ma= nagement considerations
- SFrame format and encryption process (b= ased on the current draft)
- SFrame usage within WebRTC
- SFrame usage within frame based transports

Is t= hat correct?

Regarding the integration with frame = based transports (i.e. quic or webtransport, webrtc DC or even rtmp), the c= harter only mentions that WebRTC end to end solution for webrtc should be e= xplicitly=C2=A0addressed. This is mainly because applying SFrame to webtran= sport/quic=C2=A0should be straightforward and trivial.=C2=A0

=
What topics do you think needs to be addressed or explained in d= etail for web transport for example?

Best regards<= /div>
Sergio

On Fri, Oct 15, 2021 at 1:30 AM Bernard Aboba <bernard.aboba@gmail.com> wrot= e:
Here is my review.=C2=A0

Overall, I do not feel that= this document is ready for adoption.=C2=A0 Viewed purely as a document foc= using on defining the SFrame format, it is adequate.=C2=A0 Currently, the d= ocument mixes format considerations with key management concerns while not= =C2=A0adequately covering the full range of non-RTP use cases.=C2=A0 By try= ing to do too much, the document falls short enough to be potentially detri= mental to long term success.=C2=A0

In particular, = the goals of the effort, the threat model and the use cases are not articul= ated well enough. My advice would be to pare the draft down to its bare ess= entials, spinning off material not directly relevant to the SFrame format i= nto a separate document.

The non-RTP use case= s (and potential integration with the Web media model) in particular seem l= ike they deserve more attention.=C2=A0

Section 1 s= tates:=C2=A0

   In ord=
er for the SFU to work
   properly though, it needs to be able to access RTP metadata and RTCP
   feedback messages, which is not possible if all RTP/RTCP traffic is
   end-to-end encrypted....

   This document proposes a new end-to-end encryption mechanism=
 known as
   SFrame, specifically designed to work in group conference calls with
   SFUs.

Later in Section 1, Figure 1 is inc=
luded, showing the=C2=A0SRTP packet format.=C2=A0 So Section 1 is very RTP =
(and conferencing) centric.=C2=A0 Yet at the same time, Section 3 includes =
the following goals:=C2=A0

   2.  Decouple media encryption from key management to allow SFram=
e to
       be used with an arbitrary KMS.

  =
 4.  Independence from the underlying transport, including use in non-
       RTP transports, e.g., WebTransport.

Is SFrame serious about these goals?=C2=A0 Personally, I hope so - bu=
t if so, integration with the existing Web media framework as well as new A=
PIs (such as WebCodecs) needs to be considered.=C2=A0 In doing so, use case=
s will likely expand beyond conferencing, to things like low-latency stream=
ing (for things like events, webinars, game watching, etc.)

The=
 existing Web media framework (as embodied by APIs such as MSE and EME) sup=
ports both transport and key management independence, so seeking these same=
 goals for SFRAME seems quite natural.=C2=A0 For example, today it is possi=
ble to transport containerized media for a wide range of codecs using any t=
ransport, including WebTransport and RTCData channel.=C2=A0 Once transporte=
d, the media is decoded and rendered using MSE.=C2=A0 And of course, the co=
ntainerized media can also be protected. Note that the protection model add=
resses additional classes of attack beyond those that might be executed by =
an SFU. For example, cleartext media is not accessible to Javascript, mitig=
ating against attacks such as "deep fakes".=C2=A0

Why bother=
 to consider these use cases for SFrame?=C2=A0 APIs such as WebCodecs do no=
t operate on containerized media, so there is a need to define a format all=
owing encrypted but non-containerized media to be carried over the wire. If=
 that format is not SFrame, then an equivalent will need to be invented, co=
vering the same codecs that SFrame seeks to support (e.g. Opus, H.264, VP8,=
 VP9, AV1) plus maybe a few others (e.g. AAC).=C2=A0

The benefit of wo=
rking towards integration with the existing Web media framework is that thi=
s will be more likely to lead to implementation and deployment.=C2=A0 This =
shouldn't be hard to accommodate within a document that focuses purely =
on the format, allowing the use cases and threat models to be articulated e=
lsewhere.=C2=A0






On Sun, = Oct 10, 2021 at 4:36 PM Martin Thomson <mt@lowentropy.net> wrote:
h= ttps://datatracker.ietf.org/doc/html/draft-omara-sframe-01

Please respond to this email before AOE 31 October 2021 if you support adop= ting draft-omara-sframe (currently -01) as a working group item.=C2=A0 If y= ou would prefer we not adopt this work, please respond with an explanation = of why and ideally what you would like to see addressed before we do that.<= br>
We're running this a tiny bit longer than a typical adoption call.=C2= =A0 Last time we talked about adoption there were a few concerns raised abo= ut the draft.=C2=A0 We want to make sure those concerns are addressed, or a= t least those with concerns are satisfied that their concerns could be addr= essed.

Martin, for the chairs

--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe

--0000000000003713ce05ce5e4f44-- From nobody Thu Oct 14 23:47:07 2021 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 264EB3A187C for ; Thu, 14 Oct 2021 23:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=gmail.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 8Q9ujs5627y7 for ; Thu, 14 Oct 2021 23:47:01 -0700 (PDT) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 BFECB3A187B for ; Thu, 14 Oct 2021 23:47:00 -0700 (PDT) Received: by mail-ua1-x932.google.com with SMTP id i15so16169091uap.0 for ; Thu, 14 Oct 2021 23:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Oo/OwOGfURcd5Q7WW+wasiX1ugvSeagIMB0yipFIfKM=; b=k4RIhJdT84XmI7idW8Ca3B3pYbNE6QGxpiDH3WW7BFPsyWZNADGIjjmoFD8E0Lffw1 yBslaUpCHSMc61D/fC7Eq7s2S1DS6NFtRRvxuQw4I2ly93JEEbAiei1IZERc9rDoFkQM jVgrP2QYv/3PPmCG78BLfobVImmU+8653U6/LuZUKrlXLL5+SLb9eZAr5n3bcW/mQJ8h LWWA+t1yGFnxUdOfcMzY/spNZNTlr/B+3aHT5PEhnv/bOrKGztvuIPEUjprJChNoBQJM AZSvu4MOaY6k1DFiE5+3gXABXhE4SQ+9BVbHwY9Efpj5OVr8vStpPSVo5PwUJOcv6TUF CaZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Oo/OwOGfURcd5Q7WW+wasiX1ugvSeagIMB0yipFIfKM=; b=Xfi4xW7wkiPu/l82MugGRibS8AVTYdmFbaqYNVm+Y72LSvzcMnlvwyLfSo6d4TwzaX 3r2ghoxyWOaK4VapnaIdlIi/NM+rXWGmr08+6mkOPSmHVFpMQ7LqJAQUM4Uq+v/OeqA9 SB1Nq968eQ8E+j0hmVIWxwTbwPJcftuxIbB3bv6qo/+lEjgVY0Qunj//ch8/WDc621qA 8UbvH5q4t6poDeumicZXCAEHBxW8zEgRdBNqVlodG1E7619s7mv/DAEnuqgVa+6r6IQI tiwmCY19TZbhUqE/d4/+Hd0zceAPZ315XpRAotb4eKNrhgl9BzF6SfuPP8Qy+nwcdWOx se5Q== X-Gm-Message-State: AOAM530gc4sBzV6iDYNnoCihuDjPIb+H7bYk6nc76g1bNfxVfI6zwTuM Co80Ie+5GNjb04RXAnJssuUmNhc+G6iyp6aFdkI= X-Google-Smtp-Source: ABdhPJw9Tc3vswaOqUJEiPxE3Ok0tnNxcSsxl8+HMzNgooX0ewuY5VLennaVp8ErDW9LH8ojxH+5J7nKPxqI8gfeAyo= X-Received: by 2002:a05:6102:274e:: with SMTP id p14mr11924062vsu.24.1634280419291; Thu, 14 Oct 2021 23:46:59 -0700 (PDT) MIME-Version: 1.0 References: <7e721f57-e7ee-4f47-8663-2b485aeabd1a@www.fastmail.com> In-Reply-To: From: Bernard Aboba Date: Thu, 14 Oct 2021 23:46:47 -0700 Message-ID: To: Sergio Garcia Murillo Cc: Martin Thomson , sframe@ietf.org Content-Type: multipart/alternative; boundary="000000000000dafd9305ce5e8fb7" Archived-At: Subject: Re: [Sframe] Adoption call for draft-omara-sframe-01 X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 06:47:06 -0000 --000000000000dafd9305ce5e8fb7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Comments below. On Thu, Oct 14, 2021 at 23:28 Sergio Garcia Murillo < sergio.garcia.murillo@cosmosoftware.io> wrote: > > Hi Bernard, > > Trying to understand the changes that would be required in order to > address your concerns. If I understand correctly, you are proposing > splitting the document in 3 or 4 documents: > > - SFrame architecture & overview, explaining the use cases, thread models > and key management considerations > - SFrame format and encryption process (based on the current draft) > - SFrame usage within WebRTC > - SFrame usage within frame based transports > > Is that correct? > Two documents would probably be sufficient for now - the frame format (the current draft) and an overview/framework document. > Regarding the integration with frame based transports (i.e. quic or > webtransport, webrtc DC or even rtmp), the charter only mentions that > WebRTC end to end solution for webrtc should be explicitly addressed. Thi= s > is mainly because applying SFrame to webtransport/quic should be > straightforward and trivial. > Applying SFrame to WebTransport/quic is neither trivial nor straightforward= . To enable SFrame over non-RTP alternatives, you=E2=80=99d need to explain t= he use cases, as well as defining the formats and key management requirements. For example, is the WebTransport use case conferencing, or something else, such as low-latency streaming. BTW, it=E2=80=99s not at all clear to me that conferencing over WebTranspor= t is viable, given the lack of support for RTC congestion control within the browser implementations of WebTransport. Low latency streaming from the cloud to the browser is more credible since in that use case WebTransport CC would be replaced by something more like an RMCAT algorithm. However, in that use case we wouldn=E2=80=99t be talking about MLS key management, but = rather one of the algorithms supported by EME. Also, the threat model would be quite different from the RTP/SFU use case. > What topics do you think needs to be addressed or explained in detail for > web transport for example? > The most important is probably to explain the use case - since it=E2=80=99s= most likely *not* conferencing. > Best regards > Sergio > > On Fri, Oct 15, 2021 at 1:30 AM Bernard Aboba > wrote: > >> Here is my review. >> >> Overall, I do not feel that this document is ready for adoption. Viewed >> purely as a document focusing on defining the SFrame format, it is >> adequate. Currently, the document mixes format considerations with key >> management concerns while not adequately covering the full range of non-= RTP >> use cases. By trying to do too much, the document falls short enough to= be >> potentially detrimental to long term success. >> >> In particular, the goals of the effort, the threat model and the use >> cases are not articulated well enough. My advice would be to pare the dr= aft >> down to its bare essentials, spinning off material not directly relevant= to >> the SFrame format into a separate document. >> >> The non-RTP use cases (and potential integration with the Web media >> model) in particular seem like they deserve more attention. >> >> Section 1 states: >> >> In order for the SFU to work >> properly though, it needs to be able to access RTP metadata and RTCP >> feedback messages, which is not possible if all RTP/RTCP traffic is >> end-to-end encrypted.... >> >> >> This document proposes a new end-to-end encryption mechanism known as >> SFrame, specifically designed to work in group conference calls with >> SFUs. >> >> >> Later in Section 1, Figure 1 is included, showing the SRTP packet format= . So Section 1 is very RTP (and conferencing) centric. Yet at the same ti= me, Section 3 includes the following goals: >> >> >> 2. Decouple media encryption from key management to allow SFrame to >> be used with an arbitrary KMS. >> >> >> 4. Independence from the underlying transport, including use in non- >> RTP transports, e.g., WebTransport. >> >> >> Is SFrame serious about these goals? Personally, I hope so - but if so,= integration with the existing Web media framework as well as new APIs (suc= h as WebCodecs) needs to be considered. In doing so, use cases will likely= expand beyond conferencing, to things like low-latency streaming (for thin= gs like events, webinars, game watching, etc.) >> >> >> The existing Web media framework (as embodied by APIs such as MSE and EM= E) supports both transport and key management independence, so seeking thes= e same goals for SFRAME seems quite natural. For example, today it is poss= ible to transport containerized media for a wide range of codecs using any = transport, including WebTransport and RTCData channel. Once transported, t= he media is decoded and rendered using MSE. And of course, the containeriz= ed media can also be protected. Note that the protection model addresses ad= ditional classes of attack beyond those that might be executed by an SFU. F= or example, cleartext media is not accessible to Javascript, mitigating aga= inst attacks such as "deep fakes". >> >> >> Why bother to consider these use cases for SFrame? APIs such as WebCode= cs do not operate on containerized media, so there is a need to define a fo= rmat allowing encrypted but non-containerized media to be carried over the = wire. If that format is not SFrame, then an equivalent will need to be inve= nted, covering the same codecs that SFrame seeks to support (e.g. Opus, H.2= 64, VP8, VP9, AV1) plus maybe a few others (e.g. AAC). >> >> >> The benefit of working towards integration with the existing Web media f= ramework is that this will be more likely to lead to implementation and dep= loyment. This shouldn't be hard to accommodate within a document that focu= ses purely on the format, allowing the use cases and threat models to be ar= ticulated elsewhere. >> >> >> >> >> >> >> >> >> On Sun, Oct 10, 2021 at 4:36 PM Martin Thomson wrote= : >> >>> https://datatracker.ietf.org/doc/html/draft-omara-sframe-01 >>> >>> Please respond to this email before AOE 31 October 2021 if you support >>> adopting draft-omara-sframe (currently -01) as a working group item. I= f >>> you would prefer we not adopt this work, please respond with an explana= tion >>> of why and ideally what you would like to see addressed before we do th= at. >>> >>> We're running this a tiny bit longer than a typical adoption call. Las= t >>> time we talked about adoption there were a few concerns raised about th= e >>> draft. We want to make sure those concerns are addressed, or at least >>> those with concerns are satisfied that their concerns could be addresse= d. >>> >>> Martin, for the chairs >>> >>> -- >>> Sframe mailing list >>> Sframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/sframe >>> >> >> --000000000000dafd9305ce5e8fb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Comments below.=C2=A0

On Thu, Oct 14, 2021 at 23:28 S= ergio Garcia Murillo <sergio.garcia.murillo@cosmosoftware.io> wrote:

Hi B= ernard,

Trying to understand the changes that would be r= equired in order to address your concerns. If I understand correctly, you a= re proposing splitting=C2=A0the document in 3 or 4 documents:
- SFrame architecture & overview, explaining the use cases,= thread models and key management considerations
- SFrame format = and encryption process (based on the current draft)
- SFrame usag= e within WebRTC
- SFrame usage within frame based transports

Is that correct?

Two documents would probably be sufficient= for now - the frame format (the current draft) and an overview/framework d= ocument.


Regarding the in= tegration with frame based transports (i.e. quic or webtransport, webrtc DC= or even rtmp), the charter only mentions that WebRTC end to end solution f= or webrtc should be explicitly=C2=A0addressed. This is mainly because apply= ing SFrame to webtransport/quic=C2=A0should be straightforward and trivial.= =C2=A0

Applying SFrame to WebTransport/quic is neither trivial nor st= raightforward.
To enable SFrame over non-RTP alterna= tives, you=E2=80=99d need to explain the use cases, as well as defining the= formats and key management requirements. For example, is the WebTransport = use case conferencing, or something else, such as low-latency streaming.=C2= =A0

BTW, it=E2=80=99s no= t at all clear to me that conferencing over WebTransport is viable, given t= he lack of support for RTC congestion control within the browser implementa= tions of WebTransport.=C2=A0 Low latency streaming from the cloud to the br= owser is more credible since in that use case WebTransport CC would be repl= aced by something more like an RMCAT algorithm. However, in that use case w= e wouldn=E2=80=99t be talking about MLS key management, but rather one of t= he algorithms supported by EME. Also, the threat model would be quite diffe= rent from the RTP/SFU use case.


What topics do yo= u think needs to be addressed or explained in detail for web transport for = example?

The most important is probably to explain the use case - since it=E2=80= =99s most likely *not* conferencing.

Best regards
Sergio
=
On Fri= , Oct 15, 2021 at 1:30 AM Bernard Aboba <bernard.aboba@gmail.com> wrote:
Here = is my review.=C2=A0

Overall, I do not feel that this doc= ument is ready for adoption.=C2=A0 Viewed purely as a document focusing on = defining the SFrame format, it is adequate.=C2=A0 Currently, the document m= ixes format considerations with key management concerns while not=C2=A0adeq= uately covering the full range of non-RTP use cases.=C2=A0 By trying to do = too much, the document falls short enough to be potentially detrimental to = long term success.=C2=A0

In particular, the goals = of the effort, the threat model and the use cases are not articulated well = enough. My advice would be to pare the draft down to its bare essentials, s= pinning off material not directly relevant to the SFrame format into a sepa= rate document.

The non-RTP use cases (and pot= ential integration with the Web media model) in particular seem like they d= eserve more attention.=C2=A0

Section 1 states:=C2= =A0

   In order for th=
e SFU to work
   properly though, it needs to be able to access RTP metadata and RTCP
   feedback messages, which is not possible if all RTP/RTCP traffic is
   end-to-end encrypted....

   This document proposes a new end-to-end encryption mechanism=
 known as
   SFrame, specifically designed to work in group conference calls with
   SFUs.

Later in Section 1, Figure 1 is inc=
luded, showing the=C2=A0SRTP packet format.=C2=A0 So Section 1 is very RTP =
(and conferencing) centric.=C2=A0 Yet at the same time, Section 3 includes =
the following goals:=C2=A0

   2.  Decouple media encryption from key management to allow SFram=
e to
       be used with an arbitrary KMS.

  =
 4.  Independence from the underlying transport, including use in non-
       RTP transports, e.g., WebTransport.

Is SFrame serious about these goals?=C2=A0 Personally, I hope so - bu=
t if so, integration with the existing Web media framework as well as new A=
PIs (such as WebCodecs) needs to be considered.=C2=A0 In doing so, use case=
s will likely expand beyond conferencing, to things like low-latency stream=
ing (for things like events, webinars, game watching, etc.)

The=
 existing Web media framework (as embodied by APIs such as MSE and EME) sup=
ports both transport and key management independence, so seeking these same=
 goals for SFRAME seems quite natural.=C2=A0 For example, today it is possi=
ble to transport containerized media for a wide range of codecs using any t=
ransport, including WebTransport and RTCData channel.=C2=A0 Once transporte=
d, the media is decoded and rendered using MSE.=C2=A0 And of course, the co=
ntainerized media can also be protected. Note that the protection model add=
resses additional classes of attack beyond those that might be executed by =
an SFU. For example, cleartext media is not accessible to Javascript, mitig=
ating against attacks such as "deep fakes".=C2=A0

Why bother=
 to consider these use cases for SFrame?=C2=A0 APIs such as WebCodecs do no=
t operate on containerized media, so there is a need to define a format all=
owing encrypted but non-containerized media to be carried over the wire. If=
 that format is not SFrame, then an equivalent will need to be invented, co=
vering the same codecs that SFrame seeks to support (e.g. Opus, H.264, VP8,=
 VP9, AV1) plus maybe a few others (e.g. AAC).=C2=A0

The benefit of wo=
rking towards integration with the existing Web media framework is that thi=
s will be more likely to lead to implementation and deployment.=C2=A0 This =
shouldn't be hard to accommodate within a document that focuses purely =
on the format, allowing the use cases and threat models to be articulated e=
lsewhere.=C2=A0






On Sun, = Oct 10, 2021 at 4:36 PM Martin Thomson <mt@lowentropy.net> wrote:
h= ttps://datatracker.ietf.org/doc/html/draft-omara-sframe-01

Please respond to this email before AOE 31 October 2021 if you support adop= ting draft-omara-sframe (currently -01) as a working group item.=C2=A0 If y= ou would prefer we not adopt this work, please respond with an explanation = of why and ideally what you would like to see addressed before we do that.<= br>
We're running this a tiny bit longer than a typical adoption call.=C2= =A0 Last time we talked about adoption there were a few concerns raised abo= ut the draft.=C2=A0 We want to make sure those concerns are addressed, or a= t least those with concerns are satisfied that their concerns could be addr= essed.

Martin, for the chairs

--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe

--000000000000dafd9305ce5e8fb7-- From nobody Fri Oct 15 00:29:45 2021 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 98F453A1874 for ; Fri, 15 Oct 2021 00:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=cosmosoftware-io.20210112.gappssmtp.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 UUoT_34RhS2I for ; Fri, 15 Oct 2021 00:29:37 -0700 (PDT) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 05C873A0C3D for ; Fri, 15 Oct 2021 00:29:36 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id 133so7846971pgb.1 for ; Fri, 15 Oct 2021 00:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cosmosoftware-io.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+AQO/yTp606GCR8mr5tguYDLCX+eK3loqlILQgNliJQ=; b=BSZ2QBSKLmigX22KdSudVC2moe6ErcPDsdWiFyhFRZJ24PUpmHc/x7VPHgeWPQo9Yc EKau8JL0yag8HNB8rY7OhZ2NzqMR7NViKkszOOF3tJSDPYvKjzO1H+K4giu9qvMn7IEd mXVfg+l19Cyib2XSwCHM2wtK4ZI7hvKdfoDar0bIVNHXF90v19dyV7Ijs+OGg/WscQSL VH6T6rZAFsazNIIPCIHuwqMIyZ79+ZrNAO9kc2Q14MD7lXviwKNLoLn0dC/D5t4oehFF 4jPBX7Jkv9ZpbEyNDisLgASHve0prEKaBE92cv9ktVGZnJxIZuafHWAqlp2cRboE0Aq1 44vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+AQO/yTp606GCR8mr5tguYDLCX+eK3loqlILQgNliJQ=; b=Fo8yzbpmpli1ilvhZOsHK6u2fJeLmeCr9ymxpJu9CC1UIbpKj3EVlNKpSzmQH4WJxx BpPDKqYHK7QNzfUM2aOuWgDMS4ZRAV09GYA/L/wbu8j1pt2cUXJm7gH5QUMWDFAvIZGs PW3AICFdwb2tYuS0lUiwWuAMqao5n6d+KcUDRtnR/N8YvoaXwSCv5WvowRgxNkI/92eO exiPkmWye70oOOx8OucCP3COrImdXk58HgQgBFj1r3o9Qb93ryIApBdOhl4JeCQVgHdk x/bGR1uORGdspPWKOketUSF1VaFJeC1Wym8VYrF9lnW3GwJs0XTzgiDGZyMH5eYK2Vce qUog== X-Gm-Message-State: AOAM53201OLuEaxqItNtGA35O7JwvRjlVCDQ9ptHrjue+XOMmG79Bncz YYL22+9TbGcVIW0lgNovcjgNGK90aihMo54gF3KLBxeGaq4Kgw== X-Google-Smtp-Source: ABdhPJw4Q/Dmfpc31ZrAJx9OgbmQnjAn7vmUUX8LCz9JbiwDFQqwBeU79SiEcojjm911bS8yeD2s43TGCNOh8bFTcCQ= X-Received: by 2002:a05:6a00:1911:b0:44d:7f2d:4184 with SMTP id y17-20020a056a00191100b0044d7f2d4184mr7087860pfi.17.1634282976182; Fri, 15 Oct 2021 00:29:36 -0700 (PDT) MIME-Version: 1.0 References: <7e721f57-e7ee-4f47-8663-2b485aeabd1a@www.fastmail.com> In-Reply-To: From: Sergio Garcia Murillo Date: Fri, 15 Oct 2021 09:29:24 +0200 Message-ID: To: Bernard Aboba Cc: Martin Thomson , sframe@ietf.org Content-Type: multipart/alternative; boundary="000000000000421fcd05ce5f28eb" Archived-At: Subject: Re: [Sframe] Adoption call for draft-omara-sframe-01 X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 07:29:43 -0000 --000000000000421fcd05ce5f28eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable IMO key management and key exchange are out of the scope of the SFRAME WG, the charter only mentions that we should provide a way to use MLS keys within the SFrame. Addressing the non-videoconferencing use case (i.e. streaming/broadcasting) is an absolute must, and something Alex and I have been advocating since the beginning (it is the only use case we care about in fact). But this should be done in a transport agnostic way as it is not webtransport/quic specific, that is, doing massive broadcasting/streaming in webrtc is possible =F0=9F=98=89 Best regards Sergio On Fri, Oct 15, 2021 at 8:46 AM Bernard Aboba wrote: > >> Regarding the integration with frame based transports (i.e. quic or >> webtransport, webrtc DC or even rtmp), the charter only mentions that >> WebRTC end to end solution for webrtc should be explicitly addressed. Th= is >> is mainly because applying SFrame to webtransport/quic should be >> straightforward and trivial. >> > > Applying SFrame to WebTransport/quic is neither trivial nor > straightforward. > To enable SFrame over non-RTP alternatives, you=E2=80=99d need to explain= the use > cases, as well as defining the formats and key management requirements. F= or > example, is the WebTransport use case conferencing, or something else, su= ch > as low-latency streaming. > > > BTW, it=E2=80=99s not at all clear to me that conferencing over WebTransp= ort is > viable, given the lack of support for RTC congestion control within the > browser implementations of WebTransport. Low latency streaming from the > cloud to the browser is more credible since in that use case WebTransport > CC would be replaced by something more like an RMCAT algorithm. However, = in > that use case we wouldn=E2=80=99t be talking about MLS key management, bu= t rather > one of the algorithms supported by EME. Also, the threat model would be > quite different from the RTP/SFU use case. > > >> What topics do you think needs to be addressed or explained in detail fo= r >> web transport for example? >> > > The most important is probably to explain the use case - since it=E2=80= =99s most > likely *not* conferencing. > > >> Best regards >> Sergio >> >> On Fri, Oct 15, 2021 at 1:30 AM Bernard Aboba >> wrote: >> >>> Here is my review. >>> >>> Overall, I do not feel that this document is ready for adoption. Viewe= d >>> purely as a document focusing on defining the SFrame format, it is >>> adequate. Currently, the document mixes format considerations with key >>> management concerns while not adequately covering the full range of non= -RTP >>> use cases. By trying to do too much, the document falls short enough t= o be >>> potentially detrimental to long term success. >>> >>> In particular, the goals of the effort, the threat model and the use >>> cases are not articulated well enough. My advice would be to pare the d= raft >>> down to its bare essentials, spinning off material not directly relevan= t to >>> the SFrame format into a separate document. >>> >>> The non-RTP use cases (and potential integration with the Web media >>> model) in particular seem like they deserve more attention. >>> >>> Section 1 states: >>> >>> In order for the SFU to work >>> properly though, it needs to be able to access RTP metadata and RTCP >>> feedback messages, which is not possible if all RTP/RTCP traffic is >>> end-to-end encrypted.... >>> >>> >>> This document proposes a new end-to-end encryption mechanism known a= s >>> SFrame, specifically designed to work in group conference calls with >>> SFUs. >>> >>> >>> Later in Section 1, Figure 1 is included, showing the SRTP packet forma= t. So Section 1 is very RTP (and conferencing) centric. Yet at the same t= ime, Section 3 includes the following goals: >>> >>> >>> 2. Decouple media encryption from key management to allow SFrame to >>> be used with an arbitrary KMS. >>> >>> >>> 4. Independence from the underlying transport, including use in non= - >>> RTP transports, e.g., WebTransport. >>> >>> >>> Is SFrame serious about these goals? Personally, I hope so - but if so= , integration with the existing Web media framework as well as new APIs (su= ch as WebCodecs) needs to be considered. In doing so, use cases will likel= y expand beyond conferencing, to things like low-latency streaming (for thi= ngs like events, webinars, game watching, etc.) >>> >>> >>> The existing Web media framework (as embodied by APIs such as MSE and E= ME) supports both transport and key management independence, so seeking the= se same goals for SFRAME seems quite natural. For example, today it is pos= sible to transport containerized media for a wide range of codecs using any= transport, including WebTransport and RTCData channel. Once transported, = the media is decoded and rendered using MSE. And of course, the containeri= zed media can also be protected. Note that the protection model addresses a= dditional classes of attack beyond those that might be executed by an SFU. = For example, cleartext media is not accessible to Javascript, mitigating ag= ainst attacks such as "deep fakes". >>> >>> >>> Why bother to consider these use cases for SFrame? APIs such as WebCod= ecs do not operate on containerized media, so there is a need to define a f= ormat allowing encrypted but non-containerized media to be carried over the= wire. If that format is not SFrame, then an equivalent will need to be inv= ented, covering the same codecs that SFrame seeks to support (e.g. Opus, H.= 264, VP8, VP9, AV1) plus maybe a few others (e.g. AAC). >>> >>> >>> The benefit of working towards integration with the existing Web media = framework is that this will be more likely to lead to implementation and de= ployment. This shouldn't be hard to accommodate within a document that foc= uses purely on the format, allowing the use cases and threat models to be a= rticulated elsewhere. >>> >>> >>> >>> >>> >>> >>> >>> >>> On Sun, Oct 10, 2021 at 4:36 PM Martin Thomson >>> wrote: >>> >>>> https://datatracker.ietf.org/doc/html/draft-omara-sframe-01 >>>> >>>> Please respond to this email before AOE 31 October 2021 if you support >>>> adopting draft-omara-sframe (currently -01) as a working group item. = If >>>> you would prefer we not adopt this work, please respond with an explan= ation >>>> of why and ideally what you would like to see addressed before we do t= hat. >>>> >>>> We're running this a tiny bit longer than a typical adoption call. >>>> Last time we talked about adoption there were a few concerns raised ab= out >>>> the draft. We want to make sure those concerns are addressed, or at l= east >>>> those with concerns are satisfied that their concerns could be address= ed. >>>> >>>> Martin, for the chairs >>>> >>>> -- >>>> Sframe mailing list >>>> Sframe@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfram >>>> >>> >>> --000000000000421fcd05ce5f28eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
IMO key management and key exchange are = out of the scope of the SFRAME WG, the charter only mentions that we should= provide a way to use MLS keys within the SFrame.
Addressing the non-videoconferencing use case (i.e.= streaming/broadcasting) is an absolute must, and something Alex and I have= been advocating since the beginning (it is the only use case we care about= in fact). But this should be done in a transport agnostic way as it is not= webtransport/quic specific, that is, doing massive broadcasting/streaming = in webrtc is possible =F0=9F=98=89

Best regards
Sergio=C2=A0





On Fri, Oct 15, 2021 at 8:46 AM Bernard Abob= a <bernard.aboba@gmail.com> wrote:

Regarding the integration with frame based transports (i.e. quic or webt= ransport, webrtc DC or even rtmp), the charter only mentions that WebRTC en= d to end solution for webrtc should be explicitly=C2=A0addressed. This is m= ainly because applying SFrame to webtransport/quic=C2=A0should be straightf= orward and trivial.=C2=A0

Applying SFrame to WebTransport/quic is nei= ther trivial nor straightforward.
To enable SFrame o= ver non-RTP alternatives, you=E2=80=99d need to explain the use cases, as w= ell as defining the formats and key management requirements. For example, i= s the WebTransport use case conferencing, or something else, such as low-la= tency streaming.=C2=A0


=C2=A0
BTW, it=E2=80=99s not at all clear to me that conferencing over= WebTransport is viable, given the lack of support for RTC congestion contr= ol within the browser implementations of WebTransport.=C2=A0 Low latency st= reaming from the cloud to the browser is more credible since in that use ca= se WebTransport CC would be replaced by something more like an RMCAT algori= thm. However, in that use case we wouldn=E2=80=99t be talking about MLS key= management, but rather one of the algorithms supported by EME. Also, the t= hreat model would be quite different from the RTP/SFU use case.


What topics do you think needs to be addr= essed or explained in detail for web transport for example?

The most important i= s probably to explain the use case - since it=E2=80=99s most likely *not* c= onferencing.


Best regards
Sergio

<= div class=3D"gmail_quote">
On Fri, Oct= 15, 2021 at 1:30 AM Bernard Aboba <bernard.aboba@gmail.com>= wrote:
Here is my review.=C2=A0

Overall, I do not feel= that this document is ready for adoption.=C2=A0 Viewed purely as a documen= t focusing on defining the SFrame format, it is adequate.=C2=A0 Currently, = the document mixes format considerations with key management concerns while= not=C2=A0adequately covering the full range of non-RTP use cases.=C2=A0 By= trying to do too much, the document falls short enough to be potentially d= etrimental to long term success.=C2=A0

In particul= ar, the goals of the effort, the threat model and the use cases are not art= iculated well enough. My advice would be to pare the draft down to its bare= essentials, spinning off material not directly relevant to the SFrame form= at into a separate document.

The non-RTP use = cases (and potential integration with the Web media model) in particular se= em like they deserve more attention.=C2=A0

Section= 1 states:=C2=A0

   In=
 order for the SFU to work
   properly though, it needs to be able to access RTP metadata and RTCP
   feedback messages, which is not possible if all RTP/RTCP traffic is
   end-to-end encrypted....

   This document proposes a new end-to-end encryption mechanism=
 known as
   SFrame, specifically designed to work in group conference calls with
   SFUs.

Later in Section 1, Figure 1 is inc=
luded, showing the=C2=A0SRTP packet format.=C2=A0 So Section 1 is very RTP =
(and conferencing) centric.=C2=A0 Yet at the same time, Section 3 includes =
the following goals:=C2=A0

   2.  Decouple media encryption from key management to allow SFram=
e to
       be used with an arbitrary KMS.

  =
 4.  Independence from the underlying transport, including use in non-
       RTP transports, e.g., WebTransport.

Is SFrame serious about these goals?=C2=A0 Personally, I hope so - bu=
t if so, integration with the existing Web media framework as well as new A=
PIs (such as WebCodecs) needs to be considered.=C2=A0 In doing so, use case=
s will likely expand beyond conferencing, to things like low-latency stream=
ing (for things like events, webinars, game watching, etc.)

The=
 existing Web media framework (as embodied by APIs such as MSE and EME) sup=
ports both transport and key management independence, so seeking these same=
 goals for SFRAME seems quite natural.=C2=A0 For example, today it is possi=
ble to transport containerized media for a wide range of codecs using any t=
ransport, including WebTransport and RTCData channel.=C2=A0 Once transporte=
d, the media is decoded and rendered using MSE.=C2=A0 And of course, the co=
ntainerized media can also be protected. Note that the protection model add=
resses additional classes of attack beyond those that might be executed by =
an SFU. For example, cleartext media is not accessible to Javascript, mitig=
ating against attacks such as "deep fakes".=C2=A0

Why bother=
 to consider these use cases for SFrame?=C2=A0 APIs such as WebCodecs do no=
t operate on containerized media, so there is a need to define a format all=
owing encrypted but non-containerized media to be carried over the wire. If=
 that format is not SFrame, then an equivalent will need to be invented, co=
vering the same codecs that SFrame seeks to support (e.g. Opus, H.264, VP8,=
 VP9, AV1) plus maybe a few others (e.g. AAC).=C2=A0

The benefit of wo=
rking towards integration with the existing Web media framework is that thi=
s will be more likely to lead to implementation and deployment.=C2=A0 This =
shouldn't be hard to accommodate within a document that focuses purely =
on the format, allowing the use cases and threat models to be articulated e=
lsewhere.=C2=A0






On Sun, = Oct 10, 2021 at 4:36 PM Martin Thomson <mt@lowentropy.net> wrote:<= br>
https://datatracker.ietf.org/doc/html/draft-om= ara-sframe-01

Please respond to this email before AOE 31 October 2021 if you support adop= ting draft-omara-sframe (currently -01) as a working group item.=C2=A0 If y= ou would prefer we not adopt this work, please respond with an explanation = of why and ideally what you would like to see addressed before we do that.<= br>
We're running this a tiny bit longer than a typical adoption call.=C2= =A0 Last time we talked about adoption there were a few concerns raised abo= ut the draft.=C2=A0 We want to make sure those concerns are addressed, or a= t least those with concerns are satisfied that their concerns could be addr= essed.

Martin, for the chairs

--
Sframe mailing list
Sfr= ame@ietf.org
https://www.ietf.org/mailman/listinfo/sfram
--000000000000421fcd05ce5f28eb-- From nobody Fri Oct 15 00:48:24 2021 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 E91EC3A189A for ; Fri, 15 Oct 2021 00:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=gmail.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 ANejvk2bZInD for ; Fri, 15 Oct 2021 00:48:09 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 BC3CD3A0E45 for ; Fri, 15 Oct 2021 00:48:08 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id j8so16253708uak.9 for ; Fri, 15 Oct 2021 00:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qCGVzVbVTYaKtT0/TgMM/3dAJC0/6ai63Cn5IIAjxc4=; b=PTc8714pZD2KrC9/zEi5XSD1DA7IQ2EiEJR+oSgyrrQC/xwEBPLOsMudwhZpAWhX3L OhIsP8QgQhDuHqP1rQOQq9PQP7p7BJtFxAQnvNTrOv7QjjEeeujqFmgKRKGygONtKLl8 N1AmfefmowIQnSKtZmNW56qU/wK1xGuUvBvTKbabiamDSRtuuoh9rO3a8TLGFJiQznQd I16mOs1SXRrszOAEPSON1ukObaY8IifTnUO91aW5TES4pFreAAUCq2CWrSaXmPKtL9nA tDUdSIbfMpTSftn/xn6DmjpGlyL2D6CBJjFHuzpZ10XMh0BB6Qd0m1+VbSSosjPH2+Za zBdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qCGVzVbVTYaKtT0/TgMM/3dAJC0/6ai63Cn5IIAjxc4=; b=SvYquhhleYrq3ZiJzNP1SmYRgNgdG9OHJAxx018sh1BCkogKpceAR6AW5ecg/lWunw yzZvSgkLLVRn3GfFK5GaELBepuAyc7Ut4KOyqLB5VRpHkL1MjchMgbBsMKB3gw/Pl9Qw LJKdcVs5awJcnmstKyTSav/ea7QmwOAG+acbsxmpmGgBfOueOSLm88ElopPVx8WREnXE 8foCuSgYIScqF6vfhwDSpe+qGS7C/m3XHp3fMbXb2z/s3YS3jUAI0RcnqB7ZbiqYYM3I ccQSu3znwzxlDSAUt9y4bxEkfiVOCcvfURIJxJyy/DiqICzWsb1OveGf1ZJyUuYXlWgK gB6A== X-Gm-Message-State: AOAM532BXPMDF1IFSFU06YNsVQbm3rcfTwlMYs3Bv6sdVvMsGNaWPypi 0x+xeBcsk3R0/we2yj9ru4/mXolluK/Zy5w7QR27BIaA X-Google-Smtp-Source: ABdhPJygAWtkvx2/9KLRyG8qnx+srVyxJwOyBnPnO2LDqN+mm7cRVLF8FWI+maeeDFRhrRYZs7k427uhhcAne69fgME= X-Received: by 2002:a67:e0d1:: with SMTP id m17mr12455874vsl.22.1634284087166; Fri, 15 Oct 2021 00:48:07 -0700 (PDT) MIME-Version: 1.0 References: <7e721f57-e7ee-4f47-8663-2b485aeabd1a@www.fastmail.com> In-Reply-To: From: Bernard Aboba Date: Fri, 15 Oct 2021 00:47:56 -0700 Message-ID: To: Sergio Garcia Murillo Cc: Martin Thomson , sframe@ietf.org Content-Type: multipart/alternative; boundary="0000000000007a4d1a05ce5f6a12" Archived-At: Subject: Re: [Sframe] Adoption call for draft-omara-sframe-01 X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 07:48:18 -0000 --0000000000007a4d1a05ce5f6a12 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Comments below. On Fri, Oct 15, 2021 at 00:29 Sergio Garcia Murillo < sergio.garcia.murillo@cosmosoftware.io> wrote: > IMO key management and key exchange are out of the scope of the SFRAME WG= , > That=E2=80=99s fine, because there are already other standards available to= address that (e.g. MLS, EME). Addressing the non-videoconferencing use case (i.e. streaming/broadcasting) > is an absolute must, and something Alex and I have been advocating since > the beginning (it is the only use case we care about in fact). But this > should be done in a transport agnostic way as it is not webtransport/quic > specific, that is, doing massive broadcasting/streaming in webrtc is > possible =F0=9F=98=89 > Indeed, but the SFrame threat model is quite different for non-RTP transport scenarios. For example, consider a Concert or Sporting event. The video upload, handled via WISH (RTP) or RUSH (QUIC), may not utilize Sframe protection, either because the uploader trusts the video ingestion site or because the ingestor is transcoding or compositing the video feeds (e.g. superimposing fans on the seats in the stadium obtained from the on-field camera). However, SFrame is desired on the downlink in order to protect the composited content from being modified or copied. This could be done today without SFrame by transporting containerized media over RTCDataChannel/WebTransport and rendering with MSE, but if WebCodecs is used for rendering instead, then containerization is just a waste of CPU cycles. > Best regards > Sergio > > > > > > On Fri, Oct 15, 2021 at 8:46 AM Bernard Aboba > wrote: > >> >>> Regarding the integration with frame based transports (i.e. quic or >>> webtransport, webrtc DC or even rtmp), the charter only mentions that >>> WebRTC end to end solution for webrtc should be explicitly addressed. T= his >>> is mainly because applying SFrame to webtransport/quic should be >>> straightforward and trivial. >>> >> >> Applying SFrame to WebTransport/quic is neither trivial nor >> straightforward. >> To enable SFrame over non-RTP alternatives, you=E2=80=99d need to explai= n the use >> cases, as well as defining the formats and key management requirements. = For >> example, is the WebTransport use case conferencing, or something else, s= uch >> as low-latency streaming. >> >> > > >> BTW, it=E2=80=99s not at all clear to me that conferencing over WebTrans= port is >> viable, given the lack of support for RTC congestion control within the >> browser implementations of WebTransport. Low latency streaming from the >> cloud to the browser is more credible since in that use case WebTranspor= t >> CC would be replaced by something more like an RMCAT algorithm. However,= in >> that use case we wouldn=E2=80=99t be talking about MLS key management, b= ut rather >> one of the algorithms supported by EME. Also, the threat model would be >> quite different from the RTP/SFU use case. >> >> >>> What topics do you think needs to be addressed or explained in detail >>> for web transport for example? >>> >> >> The most important is probably to explain the use case - since it=E2=80= =99s most >> likely *not* conferencing. >> >> >>> Best regards >>> Sergio >>> >>> On Fri, Oct 15, 2021 at 1:30 AM Bernard Aboba >>> wrote: >>> >>>> Here is my review. >>>> >>>> Overall, I do not feel that this document is ready for adoption. >>>> Viewed purely as a document focusing on defining the SFrame format, it= is >>>> adequate. Currently, the document mixes format considerations with ke= y >>>> management concerns while not adequately covering the full range of no= n-RTP >>>> use cases. By trying to do too much, the document falls short enough = to be >>>> potentially detrimental to long term success. >>>> >>>> In particular, the goals of the effort, the threat model and the use >>>> cases are not articulated well enough. My advice would be to pare the = draft >>>> down to its bare essentials, spinning off material not directly releva= nt to >>>> the SFrame format into a separate document. >>>> >>>> The non-RTP use cases (and potential integration with the Web media >>>> model) in particular seem like they deserve more attention. >>>> >>>> Section 1 states: >>>> >>>> In order for the SFU to work >>>> properly though, it needs to be able to access RTP metadata and RTC= P >>>> feedback messages, which is not possible if all RTP/RTCP traffic is >>>> end-to-end encrypted.... >>>> >>>> >>>> This document proposes a new end-to-end encryption mechanism known = as >>>> SFrame, specifically designed to work in group conference calls wit= h >>>> SFUs. >>>> >>>> >>>> Later in Section 1, Figure 1 is included, showing the SRTP packet form= at. So Section 1 is very RTP (and conferencing) centric. Yet at the same = time, Section 3 includes the following goals: >>>> >>>> >>>> 2. Decouple media encryption from key management to allow SFrame t= o >>>> be used with an arbitrary KMS. >>>> >>>> >>>> 4. Independence from the underlying transport, including use in no= n- >>>> RTP transports, e.g., WebTransport. >>>> >>>> >>>> Is SFrame serious about these goals? Personally, I hope so - but if s= o, integration with the existing Web media framework as well as new APIs (s= uch as WebCodecs) needs to be considered. In doing so, use cases will like= ly expand beyond conferencing, to things like low-latency streaming (for th= ings like events, webinars, game watching, etc.) >>>> >>>> >>>> The existing Web media framework (as embodied by APIs such as MSE and = EME) supports both transport and key management independence, so seeking th= ese same goals for SFRAME seems quite natural. For example, today it is po= ssible to transport containerized media for a wide range of codecs using an= y transport, including WebTransport and RTCData channel. Once transported,= the media is decoded and rendered using MSE. And of course, the container= ized media can also be protected. Note that the protection model addresses = additional classes of attack beyond those that might be executed by an SFU.= For example, cleartext media is not accessible to Javascript, mitigating a= gainst attacks such as "deep fakes". >>>> >>>> >>>> Why bother to consider these use cases for SFrame? APIs such as WebCo= decs do not operate on containerized media, so there is a need to define a = format allowing encrypted but non-containerized media to be carried over th= e wire. If that format is not SFrame, then an equivalent will need to be in= vented, covering the same codecs that SFrame seeks to support (e.g. Opus, H= .264, VP8, VP9, AV1) plus maybe a few others (e.g. AAC). >>>> >>>> >>>> The benefit of working towards integration with the existing Web media= framework is that this will be more likely to lead to implementation and d= eployment. This shouldn't be hard to accommodate within a document that fo= cuses purely on the format, allowing the use cases and threat models to be = articulated elsewhere. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Sun, Oct 10, 2021 at 4:36 PM Martin Thomson >>>> wrote: >>>> >>>>> https://datatracker.ietf.org/doc/html/draft-omara-sframe-01 >>>>> >>>>> Please respond to this email before AOE 31 October 2021 if you suppor= t >>>>> adopting draft-omara-sframe (currently -01) as a working group item. = If >>>>> you would prefer we not adopt this work, please respond with an expla= nation >>>>> of why and ideally what you would like to see addressed before we do = that. >>>>> >>>>> We're running this a tiny bit longer than a typical adoption call. >>>>> Last time we talked about adoption there were a few concerns raised a= bout >>>>> the draft. We want to make sure those concerns are addressed, or at = least >>>>> those with concerns are satisfied that their concerns could be addres= sed. >>>>> >>>>> Martin, for the chairs >>>>> >>>>> -- >>>>> Sframe mailing list >>>>> Sframe@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfram >>>>> >>>> >>>> --0000000000007a4d1a05ce5f6a12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Comments below.=C2=A0

On Fri, Oct 15, 2021 at 00:29 S= ergio Garcia Murillo <sergio.garcia.murillo@cosmosoftware.io> wrote:
IMO key manag= ement and key exchange are out of the scope of the SFRAME WG,
<= /blockquote>

That=E2=80=99s fi= ne, because there are already other standards available to address that (e.= g. MLS, EME).=C2=A0

Addressing the non-videoconfere= ncing use case (i.e. streaming/broadcasting) is an absolute must, and somet= hing Alex and I have been advocating since the beginning (it is the only us= e case we care about in fact). But this should be done in a transport agnos= tic way as it is not webtransport/quic specific, that is, doing massive bro= adcasting/streaming in webrtc is possible =F0=9F=98=89

Indeed, but the SFram= e threat model is quite different for non-RTP transport scenarios.=C2=A0 Fo= r example, consider a Concert or Sporting event.=C2=A0 The video upload, ha= ndled via WISH (RTP) or RUSH (QUIC), may not utilize Sframe protection, eit= her because the uploader trusts the video ingestion site or because the ing= estor is transcoding or compositing the video feeds (e.g. superimposing fan= s on the seats in the stadium obtained from the on-field camera).=C2=A0 How= ever, SFrame is desired on the downlink in order to protect the composited = content from being modified or copied. This could be done today without SFr= ame by transporting containerized media over RTCDataChannel/WebTransport an= d rendering with MSE, but if WebCodecs is used for rendering instead, then = containerization is just a waste of CPU cycles.

=

Best= regards
Sergio=C2=A0





On Fri, Oct 15, 2021 at 8:46 AM Bernard Aboba <be= rnard.aboba@gmail.com> wrote:

Regarding = the integration with frame based transports (i.e. quic or webtransport, web= rtc DC or even rtmp), the charter only mentions that WebRTC end to end solu= tion for webrtc should be explicitly=C2=A0addressed. This is mainly because= applying SFrame to webtransport/quic=C2=A0should be straightforward and tr= ivial.=C2=A0

Applying SFrame to WebTransport/quic is neither trivial = nor straightforward.
To enable SFrame over non-RTP a= lternatives, you=E2=80=99d need to explain the use cases, as well as defini= ng the formats and key management requirements. For example, is the WebTran= sport use case conferencing, or something else, such as low-latency streami= ng.=C2=A0

=C2=A0
=
B= TW, it=E2=80=99s not at all clear to me that conferencing over WebTransport= is viable, given the lack of support for RTC congestion control within the= browser implementations of WebTransport.=C2=A0 Low latency streaming from = the cloud to the browser is more credible since in that use case WebTranspo= rt CC would be replaced by something more like an RMCAT algorithm. However,= in that use case we wouldn=E2=80=99t be talking about MLS key management, = but rather one of the algorithms supported by EME. Also, the threat model w= ould be quite different from the RTP/SFU use case.
<= br>

What topics do you think needs to be addressed or expl= ained in detail for web transport for example?

The most important is probably to= explain the use case - since it=E2=80=99s most likely *not* conferencing.<= /div>


Best r= egards
Sergio

On Fri, Oct 15, 2021 at = 1:30 AM Bernard Aboba <bernard.aboba@gmail.com> wrote:
Here= is my review.=C2=A0

Overall, I do not feel that this do= cument is ready for adoption.=C2=A0 Viewed purely as a document focusing on= defining the SFrame format, it is adequate.=C2=A0 Currently, the document = mixes format considerations with key management concerns while not=C2=A0ade= quately covering the full range of non-RTP use cases.=C2=A0 By trying to do= too much, the document falls short enough to be potentially detrimental to= long term success.=C2=A0

In particular, the goals= of the effort, the threat model and the use cases are not articulated well= enough. My advice would be to pare the draft down to its bare essentials, = spinning off material not directly relevant to the SFrame format into a sep= arate document.

The non-RTP use cases (and po= tential integration with the Web media model) in particular seem like they = deserve more attention.=C2=A0

Section 1 states:=C2= =A0

   In order for th=
e SFU to work
   properly though, it needs to be able to access RTP metadata and RTCP
   feedback messages, which is not possible if all RTP/RTCP traffic is
   end-to-end encrypted....

   This document proposes a new end-to-end encryption mechanism=
 known as
   SFrame, specifically designed to work in group conference calls with
   SFUs.

Later in Section 1, Figure 1 is inc=
luded, showing the=C2=A0SRTP packet format.=C2=A0 So Section 1 is very RTP =
(and conferencing) centric.=C2=A0 Yet at the same time, Section 3 includes =
the following goals:=C2=A0

   2.  Decouple media encryption from key management to allow SFram=
e to
       be used with an arbitrary KMS.

  =
 4.  Independence from the underlying transport, including use in non-
       RTP transports, e.g., WebTransport.

Is SFrame serious about these goals?=C2=A0 Personally, I hope so - bu=
t if so, integration with the existing Web media framework as well as new A=
PIs (such as WebCodecs) needs to be considered.=C2=A0 In doing so, use case=
s will likely expand beyond conferencing, to things like low-latency stream=
ing (for things like events, webinars, game watching, etc.)

The=
 existing Web media framework (as embodied by APIs such as MSE and EME) sup=
ports both transport and key management independence, so seeking these same=
 goals for SFRAME seems quite natural.=C2=A0 For example, today it is possi=
ble to transport containerized media for a wide range of codecs using any t=
ransport, including WebTransport and RTCData channel.=C2=A0 Once transporte=
d, the media is decoded and rendered using MSE.=C2=A0 And of course, the co=
ntainerized media can also be protected. Note that the protection model add=
resses additional classes of attack beyond those that might be executed by =
an SFU. For example, cleartext media is not accessible to Javascript, mitig=
ating against attacks such as "deep fakes".=C2=A0

Why bother=
 to consider these use cases for SFrame?=C2=A0 APIs such as WebCodecs do no=
t operate on containerized media, so there is a need to define a format all=
owing encrypted but non-containerized media to be carried over the wire. If=
 that format is not SFrame, then an equivalent will need to be invented, co=
vering the same codecs that SFrame seeks to support (e.g. Opus, H.264, VP8,=
 VP9, AV1) plus maybe a few others (e.g. AAC).=C2=A0

The benefit of wo=
rking towards integration with the existing Web media framework is that thi=
s will be more likely to lead to implementation and deployment.=C2=A0 This =
shouldn't be hard to accommodate within a document that focuses purely =
on the format, allowing the use cases and threat models to be articulated e=
lsewhere.=C2=A0






On Sun, = Oct 10, 2021 at 4:36 PM Martin Thomson <mt@lowentropy.net> wrote:<= br>
https://datatracker.ietf.org/doc/html/draft-om= ara-sframe-01

Please respond to this email before AOE 31 October 2021 if you support adop= ting draft-omara-sframe (currently -01) as a working group item.=C2=A0 If y= ou would prefer we not adopt this work, please respond with an explanation = of why and ideally what you would like to see addressed before we do that.<= br>
We're running this a tiny bit longer than a typical adoption call.=C2= =A0 Last time we talked about adoption there were a few concerns raised abo= ut the draft.=C2=A0 We want to make sure those concerns are addressed, or a= t least those with concerns are satisfied that their concerns could be addr= essed.

Martin, for the chairs

--
Sframe mailing list
Sfr= ame@ietf.org
https://www.ietf.org/mailman/listinfo/sfram
--0000000000007a4d1a05ce5f6a12-- From nobody Fri Oct 15 05:49:57 2021 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 DACB13A0778 for ; Fri, 15 Oct 2021 05:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cosmosoftware-io.20210112.gappssmtp.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 xF5JQS7mCy4z for ; Fri, 15 Oct 2021 05:49:51 -0700 (PDT) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 3C6783A0774 for ; Fri, 15 Oct 2021 05:49:51 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id t11so6313868plq.11 for ; Fri, 15 Oct 2021 05:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cosmosoftware-io.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2mtKODHGG1F22XCPcmD74sMc6IQkQEKTD27VV6aKiuI=; b=FEN/2DfrnyNoP+r65jiBQeQl4YxrXEdzqBI38quNp/pUUu1QfGg+RMnUqhSYCBTPa6 mp1poL+Y5YAMWMCO7lAkpbhTB+dPCQH2WiFdEGiMsGloRrNcoT717Et3Mi88q71Sy0GF 3zEVdTtNiGmk9mXPLStqswGzklzmy8VPWsVQr6ajtlbOnbgE/r8mzW3dDLo+ByD8/a3u N4UDJFjmEzYTi51rU/ng3EMkoQfY1RjwQTtv2Dcus9xi6NsvF4mpczYB61QR3SaGpRGW 0k2wE05Tvg4J3O/0vsbRu/MwvBlipY6pWRpbQ/x+NLno9J9OIdzLci6aeeqAGd4IjyH0 dzrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2mtKODHGG1F22XCPcmD74sMc6IQkQEKTD27VV6aKiuI=; b=L5QhsYzvjdi4GR+KYSVXtbNZAXVdegEWC2MzWwNczCFH2qaZEYPdCwrSKeBA10XOBT ItFA4xXzHNZ8hgb0mxZJLeO+WoqeDT+IRkMZ9xJrYYLo7tYIneEVQKHZ1SCeg8ScSmLy eOgw6Ghp261dh/vMGY2R/+GP+iTeaJ5tHt8syn9lyuN2tpXK2ozHmvyGMRZc7rxCAbp1 vxvOHkb170FCyMXJZarvFt76duOr/FVzT8o9q/oeuvctruoDyfUybp5YpJY/h0o6XlkC OhLo1qpVv4CfwwWYm92sdiMimG5s/H8AE0xvAKy64EmW9UU3CxUdjQsyRKoyk9lCorgF 7CMg== X-Gm-Message-State: AOAM532KEkCrbQmxiisTpSt/BO2Gzfs0C2SwkQHftMXuNbV/6RmUk2V/ 7QXQWBP+qdJqSHCRULnjmCLWEnxzNw9fmnP2SSm09g== X-Google-Smtp-Source: ABdhPJzGUDNrwY/sv81bgAu4TLsuER+fFNQDD7DGpdvC2zOV7VQjyWUKLVTOypv4XiiUGZk13s/Yg5s7fQpwGzju5JA= X-Received: by 2002:a17:902:d501:b0:13f:1b44:baa2 with SMTP id b1-20020a170902d50100b0013f1b44baa2mr10819389plg.56.1634302190352; Fri, 15 Oct 2021 05:49:50 -0700 (PDT) MIME-Version: 1.0 References: <7e721f57-e7ee-4f47-8663-2b485aeabd1a@www.fastmail.com> In-Reply-To: From: Sergio Garcia Murillo Date: Fri, 15 Oct 2021 14:49:38 +0200 Message-ID: To: Bernard Aboba Cc: Martin Thomson , sframe@ietf.org Content-Type: multipart/alternative; boundary="00000000000083135b05ce63a142" Archived-At: Subject: Re: [Sframe] Adoption call for draft-omara-sframe-01 X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 12:49:56 -0000 --00000000000083135b05ce63a142 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Addressing the non-videoconferencing use case (i.e. >> streaming/broadcasting) is an absolute must, and something Alex and I ha= ve >> been advocating since the beginning (it is the only use case we care abo= ut >> in fact). But this should be done in a transport agnostic way as it is n= ot >> webtransport/quic specific, that is, doing massive broadcasting/streamin= g >> in webrtc is possible =F0=9F=98=89 >> > > Indeed, but the SFrame threat model is quite different for non-RTP > transport scenarios. For example, consider a Concert or Sporting event. > The video upload, handled via WISH (RTP) or RUSH (QUIC), may not utilize > Sframe protection, either because the uploader trusts the video ingestion > site or because the ingestor is transcoding or compositing the video feed= s > (e.g. superimposing fans on the seats in the stadium obtained from the > on-field camera). However, SFrame is desired on the downlink in order to > protect the composited content from being modified or copied. This could = be > done today without SFrame by transporting containerized media over > RTCDataChannel/WebTransport and rendering with MSE, but if WebCodecs is > used for rendering instead, then containerization is just a waste of CPU > cycles. > > The SFrame WG charter explicitly states that the intention of SFRAME is protecting the media to be decrypted by intermediary servers to provide end to end encryption. So, SFRAME scope and protection/security properties end when the media frame is transformed by the decryption process. DRM or content protection is applied after that point and IMO out of the scope of the SFRAME WG. Not saying that it would not be interesting to explore the possibility of using SFRAME for more extended usages, but I don't feel that requiring SFRAME to cover this use case as a prerequisite to be adopted is the right way to go. Best regards Sergio --00000000000083135b05ce63a142 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=

Addressing the non-videoconfe= rencing use case (i.e. streaming/broadcasting) is an absolute must, and som= ething Alex and I have been advocating since the beginning (it is the only = use case we care about in fact). But this should be done in a transport agn= ostic way as it is not webtransport/quic specific, that is, doing massive b= roadcasting/streaming in webrtc is possible =F0=9F=98=89

Indeed, but the SFr= ame threat model is quite different for non-RTP transport scenarios.=C2=A0 = For example, consider a Concert or Sporting event.=C2=A0 The video upload, = handled via WISH (RTP) or RUSH (QUIC), may not utilize Sframe protection, e= ither because the uploader trusts the video ingestion site or because the i= ngestor is transcoding or compositing the video feeds (e.g. superimposing f= ans on the seats in the stadium obtained from the on-field camera).=C2=A0 H= owever, SFrame is desired on the downlink in order to protect the composite= d content from being modified or copied. This could be done today without S= Frame by transporting containerized media over RTCDataChannel/WebTransport = and rendering with MSE, but if WebCodecs is used for rendering instead, the= n containerization is just a waste of CPU cycles.

The SFrame WG charter = explicitly=C2=A0states=C2=A0 that the intention of SFRAME is protecting the= media to be decrypted by intermediary servers to=C2=A0provide end to end e= ncryption. So, SFRAME scope and protection/security properties end when the= media frame is transformed by the decryption process. DRM or content prote= ction is applied after that point and IMO out of the scope of the SFRAME WG= .=C2=A0

Not saying that it would not be interestin= g to explore the possibility=C2=A0of using SFRAME for more extended usages,= but I don't feel that requiring SFRAME to cover this use case as a pre= requisite to be adopted is the right way to go.

Be= st regards
Sergio


--00000000000083135b05ce63a142-- From nobody Fri Oct 15 07:42:18 2021 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 91CAE3A08E7 for ; Fri, 15 Oct 2021 07:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=ipv-sx.20210112.gappssmtp.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 WetcQXs4SfdP for ; Fri, 15 Oct 2021 07:42:13 -0700 (PDT) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 3F9E43A08EB for ; Fri, 15 Oct 2021 07:42:13 -0700 (PDT) Received: by mail-qv1-xf32.google.com with SMTP id z15so5843170qvj.7 for ; Fri, 15 Oct 2021 07:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Zmt7AsXrxMUdLYacw1C/wFFL1bleKK/xSYjr8NbUoe4=; b=Ucp4zZHyNccnlfJLwXw9GVvQ+xzQ27VkjAeGSgtG7f6jym9IMuJvZkg45RfzToPlxE zawtDu1RaBow83NhYOk/6ewdBwIn5gnzcPg4rSN4joU0ZHF3IiJleFMUsz/aQMX8WkO3 E6uBmXLooE+4No8HoR2a8W/hgBhJZp5N9g2ihYdk4msD+8Z7/MNFUB1jLvX5SQpfukhG u/eMumZzt6sap6whxnJsYJLoYNZCoaAdEHuBXNYJKaiy8wAuLmATQr6KUBiSeCiD7Srz I4VFAgsicJ0tdNgRMAEQwYNm26hjGfAC8scCc7O/RpcbvjHJSi78e2bziZLcun/Jo1iT LLQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Zmt7AsXrxMUdLYacw1C/wFFL1bleKK/xSYjr8NbUoe4=; b=jjbEm3S43gZHUPoLqD48tkfmg994mgy6VKbMQ4o1acmgx/y5IPjGThrK8yVCeZSN/b 3/smEj4RYm90uMGnjm97i9ZoEltsLl5FiX16SmlPSiI5uaUm3RYLVTQyQgU67JX435W8 yjOAjx2kIWnsmuw/eT053ytejtzdWZyRKU9Cx5JbE0l2bxFczx4NW18A1ycAD5naAqr5 EwwtX5SDosOaeLLwt+eqP2CjvQtvDKD9AP0xFkYlCaxY041rYKMM9VS/vkLceJZlzIfO 2fMBBXD4JOOqrcXMp9np2LhUFYq0et4fTSf2vH5zYZh4MqC0ef+seTQRLePrONb5mJQR pYqQ== X-Gm-Message-State: AOAM531OYuRqRlKl/6sB+MD6IW3Y4lxjAPWtzVY02o28t8n/I+OWAG/z Z2Vnw1oEt9w5KkDpKK+x0lJ6kc1PHNhEBgPHOIgyGQ== X-Google-Smtp-Source: ABdhPJxrztVoRQwgwRxPmEM4Yi/gfToudsToNPhbBUfbOiDs2UaIGYHpMo+fRkDc48b9pODyZdrH1QxHQPCG4nN/kNE= X-Received: by 2002:a0c:ffa9:: with SMTP id d9mr11846439qvv.53.1634308931937; Fri, 15 Oct 2021 07:42:11 -0700 (PDT) MIME-Version: 1.0 References: <7e721f57-e7ee-4f47-8663-2b485aeabd1a@www.fastmail.com> <3ca7b744-10f6-61e3-f2a1-ac621b1ec468@jitsi.org> In-Reply-To: <3ca7b744-10f6-61e3-f2a1-ac621b1ec468@jitsi.org> From: Richard Barnes Date: Fri, 15 Oct 2021 10:42:00 -0400 Message-ID: To: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Cc: Martin Thomson , sframe@ietf.org Content-Type: multipart/alternative; boundary="00000000000057771f05ce653349" Archived-At: Subject: Re: [Sframe] Adoption call for draft-omara-sframe-01 X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 14:42:18 -0000 --00000000000057771f05ce653349 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support adopting this draft. Bernard is correct to point out that it needs some polishing, but that's what we do in a WG. Even with the rough edges, it captures the core of what we want to get to. In other words, the core technical bits around how to do the actual framing and encryption are largely right, we just need to put them in the right context. And now that we've had a couple of rounds of SDP/RTP conversation (with a few more to go), it seems like we have a pretty good idea of where the cut lines should be, so I have confidence that the WG will be able to come to consensus. --Richard On Mon, Oct 11, 2021 at 4:38 AM Sa=C3=BAl Ibarra Corretg=C3=A9 wrote: > On 11/10/2021 01:35, Martin Thomson wrote: > > https://datatracker.ietf.org/doc/html/draft-omara-sframe-01 > > > > Please respond to this email before AOE 31 October 2021 if you support > adopting draft-omara-sframe (currently -01) as a working group item. If > you would prefer we not adopt this work, please respond with an explanati= on > of why and ideally what you would like to see addressed before we do that= . > > > > We're running this a tiny bit longer than a typical adoption call. Las= t > time we talked about adoption there were a few concerns raised about the > draft. We want to make sure those concerns are addressed, or at least > those with concerns are satisfied that their concerns could be addressed. > > > > Martin, for the chairs > > > > I do support (speaking for Jitsi here) the adoption of the draft. > > Quick question though: any reason why -01 and not the latest version? > > > Cheers, > > -- > Sa=C3=BAl > > -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --00000000000057771f05ce653349 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support adopting this draft.

Bernard is correct to point out that it needs some polishing, but that&#= 39;s what we do in a WG.=C2=A0 Even with the rough edges, it captures the c= ore of what we want to get to.=C2=A0 In other words, the core technical bit= s around how to do the actual framing and encryption are largely right, we = just need to put them in the right context.=C2=A0 And now that we've ha= d a couple of rounds of SDP/RTP conversation (with a few more to go), it se= ems like we have a pretty good idea of where the cut lines should be, so I = have confidence that the WG will be able to come to consensus.
--Richard

On Mon, Oct 11, 2021 at 4:38 AM Sa=C3=BAl I= barra Corretg=C3=A9 <saghul@jitsi.or= g> wrote:
On 11/10/2021 01:35, Martin Thomson wrote:
> https://datatracker.ietf.org/doc/htm= l/draft-omara-sframe-01
>
> Please respond to this email before AOE 31 October 2021 if you support= adopting draft-omara-sframe (currently -01) as a working group item.=C2=A0= If you would prefer we not adopt this work, please respond with an explana= tion of why and ideally what you would like to see addressed before we do t= hat.
>
> We're running this a tiny bit longer than a typical adoption call.= =C2=A0 Last time we talked about adoption there were a few concerns raised = about the draft.=C2=A0 We want to make sure those concerns are addressed, o= r at least those with concerns are satisfied that their concerns could be a= ddressed.
>
> Martin, for the chairs
>

I do support (speaking for Jitsi here) the adoption of the draft.

Quick question though: any reason why -01 and not the latest version?


Cheers,

--
Sa=C3=BAl

--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--00000000000057771f05ce653349-- From nobody Fri Oct 15 10:05:56 2021 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 BF2383A08C5 for ; Fri, 15 Oct 2021 10:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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=apple.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 X4Z4BlHQXBIX for ; Fri, 15 Oct 2021 10:05:48 -0700 (PDT) Received: from rn-mailsvcp-ppex-lapp35.apple.com (rn-mailsvcp-ppex-lapp35.rno.apple.com [17.179.253.44]) (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 9BDFE3A08D3 for ; Fri, 15 Oct 2021 10:05:48 -0700 (PDT) Received: from pps.filterd (rn-mailsvcp-ppex-lapp35.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp35.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 19FGqf5G012798 for ; Fri, 15 Oct 2021 10:05:48 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : date : references : to : in-reply-to : message-id; s=20180706; bh=SsnHPZvepQdbg4J+gQUePX1AjDvq/UUn5Uq2tmOk4VU=; b=bzwWSnl463zWwz0BchFtsRlt2E9/1DUwnAEbPhb2UST2NdVy45mJfAW7j2D9bOuGCguN b8W+ZEjwIVAHSQswrNjTA203bphaNkINXeqcOD5fcsTC8ZEkriXlLsNINBv79Z7wtxkO 7u7mgTSIEV2ZJLCcIDoiUAoDUWlRNvkQOrC2DzcP5vpYlNvCzLveMl7Z3Tuagp6K1H87 9b7xlnfWfJc7Ic+9qZw0qvT0GtdewGKtaU7UTEwbNvmC3gyoVmySZkpK/FhxGCcB6RdZ ayqhsTbL620iWqtEMirzdRDyqOxzL+fqDAYizQMNOLW2WcksFt9iHA0YdOTzo13yEUjH /g== Received: from crk-mailsvcp-mta-lapp02.euro.apple.com (crk-mailsvcp-mta-lapp02.euro.apple.com [17.66.55.14]) by rn-mailsvcp-ppex-lapp35.rno.apple.com with ESMTP id 3bq3xu9jp8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 15 Oct 2021 10:05:48 -0700 Received: from crk-mailsvcp-mmp-lapp02.euro.apple.com (crk-mailsvcp-mmp-lapp02.euro.apple.com [17.72.136.16]) by crk-mailsvcp-mta-lapp02.euro.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R110036C3HM7E00@crk-mailsvcp-mta-lapp02.euro.apple.com> for sframe@ietf.org; Fri, 15 Oct 2021 18:05:46 +0100 (IST) Received: from process_milters-daemon.crk-mailsvcp-mmp-lapp02.euro.apple.com by crk-mailsvcp-mmp-lapp02.euro.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R1100D0034E0X00@crk-mailsvcp-mmp-lapp02.euro.apple.com> for sframe@ietf.org; Fri, 15 Oct 2021 18:05:46 +0100 (IST) X-Va-A: X-Va-T-CD: 82d136be8d29894cd8ebb4823be734da X-Va-E-CD: 32226c6fd1ca3a0f8cf3bf4b30472e4a X-Va-R-CD: 66c2a1cf38dce55cd8b43932d6aed894 X-Va-CD: 0 X-Va-ID: 9de5bcf0-4bb7-40ad-a9de-7fafc53eb4a5 X-V-A: X-V-T-CD: 82d136be8d29894cd8ebb4823be734da X-V-E-CD: 32226c6fd1ca3a0f8cf3bf4b30472e4a X-V-R-CD: 66c2a1cf38dce55cd8b43932d6aed894 X-V-CD: 0 X-V-ID: b9d3bdbe-ec57-4189-9131-1d2b1fdc1d94 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-10-15_05:2021-10-14, 2021-10-15 signatures=0 Received: from smtpclient.apple ([17.235.205.147]) by crk-mailsvcp-mmp-lapp02.euro.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R110056O3HJJM00@crk-mailsvcp-mmp-lapp02.euro.apple.com> for sframe@ietf.org; Fri, 15 Oct 2021 18:05:46 +0100 (IST) From: Youenn Fablet Content-type: multipart/alternative; boundary="Apple-Mail=_7822907F-2EC3-4A9B-96DD-4BBF37E5F728" MIME-version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.21\)) Date: Fri, 15 Oct 2021 19:05:41 +0200 References: <7e721f57-e7ee-4f47-8663-2b485aeabd1a@www.fastmail.com> To: sframe@ietf.org In-reply-to: Message-id: X-Mailer: Apple Mail (2.3693.20.0.1.21) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-10-15_05:2021-10-14, 2021-10-15 signatures=0 Archived-At: Subject: Re: [Sframe] Adoption call for draft-omara-sframe-01 X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 17:05:55 -0000 --Apple-Mail=_7822907F-2EC3-4A9B-96DD-4BBF37E5F728 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I support adopting this draft as a working group item. The SFrame format, or variants of it, are being deployed in existing = applications. This gives confidence in the fact that the SFrame format described in = the document is solving real problems. The current draft document allowed to implement it in at least two = independent implementations (Cisco and Safari), both implementations = passing the same test suite. This gives confidence in the level of details used to describe the = SFrame format. I look forward for additional work in the area, to address Bernard=E2=80=99= s points and more. The suggestion to move part of the current document in a separate = document seems a good idea. This modularity would for instance be useful in W3C specifications = building on the SFrame format, in particular the being standardised = SFrameTransform. I do not think that this is a blocker for adopting the document as is. Adoption by the WG is just a starting point, and I believe that = contributors of this document are aware that more work is needed. Thanks, Y > ---------- Forwarded message --------- > From: Martin Thomson > > Date: Sun, Oct 10, 2021 at 7:36 PM > Subject: [Sframe] Adoption call for draft-omara-sframe-01 > To: > >=20 >=20 > https://datatracker.ietf.org/doc/html/draft-omara-sframe-01 = >=20 > Please respond to this email before AOE 31 October 2021 if you support = adopting draft-omara-sframe (currently -01) as a working group item. If = you would prefer we not adopt this work, please respond with an = explanation of why and ideally what you would like to see addressed = before we do that. >=20 > We're running this a tiny bit longer than a typical adoption call. = Last time we talked about adoption there were a few concerns raised = about the draft. We want to make sure those concerns are addressed, or = at least those with concerns are satisfied that their concerns could be = addressed. >=20 > Martin, for the chairs >=20 > --=20 > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe = --Apple-Mail=_7822907F-2EC3-4A9B-96DD-4BBF37E5F728 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = support adopting this draft as a working group item.

The SFrame format, or variants of it, are being = deployed in existing applications.
This gives confidence in = the fact that the SFrame format described in the document is solving = real problems.
The current draft document allowed = to implement it in at least two independent implementations (Cisco and = Safari), both implementations passing the same test suite.
This gives confidence in the level of details used to = describe the SFrame format.

I look forward for additional work in the area, to address = Bernard=E2=80=99s points and more.
The suggestion = to move part of the current document in a separate document seems a good = idea.
This modularity would for instance be useful = in W3C specifications building on the SFrame format, in particular the = being standardised SFrameTransform.

I do not think that this is a blocker = for adopting the document as is.
Adoption by = the WG is just a starting point, and I believe that contributors of this = document are aware that more work is needed.

Thanks,
Y

---------- Forwarded message = ---------
From: Martin Thomson <mt@lowentropy.net>
Date: Sun, Oct = 10, 2021 at 7:36 PM
Subject: [Sframe] Adoption call for = draft-omara-sframe-01
To: <sframe@ietf.org>


https://datatracker.ietf.org/doc/html/draft-omara-sframe-01=

Please respond to this email before AOE 31 October 2021 if you support = adopting draft-omara-sframe (currently -01) as a working group = item.  If you would prefer we not adopt this work, please respond = with an explanation of why and ideally what you would like to see = addressed before we do that.

We're running this a tiny bit longer than a typical adoption call.  = Last time we talked about adoption there were a few concerns raised = about the draft.  We want to make sure those concerns are = addressed, or at least those with concerns are satisfied that their = concerns could be addressed.

Martin, for the chairs

--
Sframe mailing list
Sframe@ietf.org
https://www.ietf.org/mailman/listinfo/sframe
=

= --Apple-Mail=_7822907F-2EC3-4A9B-96DD-4BBF37E5F728-- From nobody Fri Oct 15 10:14:24 2021 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 7B6723A08D3 for ; Fri, 15 Oct 2021 10:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=gmail.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 hBLM6nfiMJMp for ; Fri, 15 Oct 2021 10:14:16 -0700 (PDT) Received: from mail-oo1-xc36.google.com (mail-oo1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) (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 A36863A08BD for ; Fri, 15 Oct 2021 10:14:08 -0700 (PDT) Received: by mail-oo1-xc36.google.com with SMTP id u5-20020a4ab5c5000000b002b6a2a05065so3219597ooo.0 for ; Fri, 15 Oct 2021 10:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=VAbOxMXH7WbWL9x/l509zaHFSAYrWBLlxyFwrPX+bns=; b=REN8ZXpadarScmhWNlMZJqG+zYbDoZ/lqK2RVAmIWD52kURjE/qDZipjiv7ZvKMJAw 4P2Rjgt0LGMh6irkYpdMkPh1FyudtU4PrT27t2mL50kJiJxGJJOHCI2GO1ORpzPmU5gp NsK8CiDdsLq415IcJm5hBr6OnpefhkcC7cO5Qs2sTyvNCS7C0pnWf19MZiI8J2PhskHe yQJnLn+BATLSo+BQ5A3/ak8Cmb8wPsK9p10qQQGNFD+a/F+nslXSRbBHronZU3bloovl WXmQIWgQ70Kvf3IfKjlhDZ9b58LM6F3uMOuI98tWym1jA8Mcrw0i6qT5eKBLpe3LvEbT c80w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=VAbOxMXH7WbWL9x/l509zaHFSAYrWBLlxyFwrPX+bns=; b=Q2wPq2uMHSSxmcGvI8VqHuzvNOkHUUyKfVwok7IcnNTY/C0f+43EIG9p4GhD43Udx8 lSPXn8kkVuxttNV3tyjPoYoFGC2DZAD3FeBCaOTh94ZvGcS16CDeCBRYrRpQt0meZie+ Sx4hFa2hGHV9yO8eoOj7Hk9sPY/wt9LWs/nSBH+dHN5VZ6++rQA74984/rsx5VogjAAY 22MGuw3xsBnqIvwtLuU7C4rUWthihAjEjE9JsdXPj02WQ3hLV8Y1rdhC+Lulyi0b3yQg PL9iAUcjhw/BsinIBY3jHYaNlfr47S7psIc8LutzRC1ETEtPGLf2HD2vq5YtrIYWFkqL XKrQ== X-Gm-Message-State: AOAM5306ucGsy+qH0gxI/WSjAQkq6yqvf9BlU8TdyKjzm1zYlucE2yGJ 3/uYQ9ZM036aflEOtGeY+Wi0XFMHcGJdBOwU26/BNMt5RHo= X-Google-Smtp-Source: ABdhPJwiKUBa6fUmOkHpJqISSfffyKMARNYAb1aP2b6PXAwPyY+JhsEtFK2vjJDYOs60+EckWML+VwriSh0WBTVKcq0= X-Received: by 2002:a4a:c808:: with SMTP id s8mr1557687ooq.8.1634318047407; Fri, 15 Oct 2021 10:14:07 -0700 (PDT) MIME-Version: 1.0 References: <7e721f57-e7ee-4f47-8663-2b485aeabd1a@www.fastmail.com> In-Reply-To: From: Emad Omara Date: Fri, 15 Oct 2021 10:13:56 -0700 Message-ID: To: sframe@ietf.org Content-Type: multipart/alternative; boundary="000000000000aa70d305ce6752f9" Archived-At: Subject: Re: [Sframe] Adoption call for draft-omara-sframe-01 X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 17:14:22 -0000 --000000000000aa70d305ce6752f9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support adopting this draft as a working group item. On Fri, Oct 15, 2021 at 10:05 AM Youenn Fablet wrote: > I support adopting this draft as a working group item. > > The SFrame format, or variants of it, are being deployed in existing > applications. > This gives confidence in the fact that the SFrame format described in the > document is solving real problems. > The current draft document allowed to implement it in at least two > independent implementations (Cisco and Safari), both implementations > passing the same test suite. > This gives confidence in the level of details used to describe the SFrame > format. > > I look forward for additional work in the area, to address Bernard=E2=80= =99s > points and more. > The suggestion to move part of the current document in a separate documen= t > seems a good idea. > This modularity would for instance be useful in W3C specifications > building on the SFrame format, in particular the being standardised > SFrameTransform. > > I do not think that this is a blocker for adopting the document as is. > Adoption by the WG is just a starting point, and I believe that > contributors of this document are aware that more work is needed. > > Thanks, > Y > > ---------- Forwarded message --------- > From: Martin Thomson > Date: Sun, Oct 10, 2021 at 7:36 PM > Subject: [Sframe] Adoption call for draft-omara-sframe-01 > To: > > > https://datatracker.ietf.org/doc/html/draft-omara-sframe-01 > > Please respond to this email before AOE 31 October 2021 if you support > adopting draft-omara-sframe (currently -01) as a working group item. If > you would prefer we not adopt this work, please respond with an explanati= on > of why and ideally what you would like to see addressed before we do that= . > > We're running this a tiny bit longer than a typical adoption call. Last > time we talked about adoption there were a few concerns raised about the > draft. We want to make sure those concerns are addressed, or at least > those with concerns are satisfied that their concerns could be addressed. > > Martin, for the chairs > > -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > > > -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --000000000000aa70d305ce6752f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support adopting this draft as a working group item.
=



On Fri, Oct 15, 2021 at 10:05 AM Youenn Fable= t <youenn=3D40apple.com@dm= arc.ietf.org> wrote:
I support adopting th= is draft as a working group item.

=
The SFrame format, or variants of it, are b= eing deployed in existing applications.
This gives confidence in the fact that the SFrame format described in the= document is solving real problems.
The current draft document al= lowed to implement it in at least two independent implementations (Cisco an= d Safari), both implementations passing the same test suite.
This= gives confidence in the level of details used to describe the SFrame forma= t.

I look forward for additional work in the area,= to address Bernard=E2=80=99s points and more.
The suggestion to = move part of the current document in a separate document seems a good idea.=
This modularity would for instance be useful in W3C specificatio= ns building on the SFrame format, in particular the being standardised SFra= meTransform.

I do not think that this is a blocker= for adopting the document as is.
Adoption by the WG is just= a starting point, and I believe that contributors of this document are awa= re that more work is needed.

Thanks,
Y

---------- Forwarded message ---------
From: = Martin Thomson <mt@lowentr= opy.net>
Date: Sun, Oct 10, 2021 at 7:36 PM
Subject: [S= frame] Adoption call for draft-omara-sframe-01
To: <sframe@ietf.org>

<= br>https://datatracker.ietf.org/doc/html/= draft-omara-sframe-01

Please respond to this email before AOE 31 October 2021 if you support adop= ting draft-omara-sframe (currently -01) as a working group item.=C2=A0 If y= ou would prefer we not adopt this work, please respond with an explanation = of why and ideally what you would like to see addressed before we do that.<= br>
We're running this a tiny bit longer than a typical adoption call.=C2= =A0 Last time we talked about adoption there were a few concerns raised abo= ut the draft.=C2=A0 We want to make sure those concerns are addressed, or a= t least those with concerns are satisfied that their concerns could be addr= essed.

Martin, for the chairs

--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe

--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--000000000000aa70d305ce6752f9-- From nobody Fri Oct 15 10:16:08 2021 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 C38103A08D3 for ; Fri, 15 Oct 2021 10:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 XZPsZkP4cctO for ; Fri, 15 Oct 2021 10:16:01 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 6706C3A08BD for ; Fri, 15 Oct 2021 10:16:01 -0700 (PDT) IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A07oagKnyGS3IRuq1GkwMm5nFkbnpDfI13DAb?= =?us-ascii?q?v31ZSRFFG/Fw9vrFoB1173/JYVoqM03I5+ruBEDwex7hHPdOiOEs1PWZMjUO01?= =?us-ascii?q?HFEGgN1+rfKkXbak7DytI=3D?= X-IronPort-AV: E=Sophos;i="5.84,326,1620684000"; d="scan'208,217";a="534210327" Received: from 82-64-165-115.subs.proxad.net (HELO smtpclient.apple) ([82.64.165.115]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 15 Oct 2021 19:15:58 +0200 Content-Type: multipart/alternative; boundary=Apple-Mail-0A8B126D-02F3-48C5-98CC-8AF12230C926 Content-Transfer-Encoding: 7bit From: Benjamin Beurdouche Mime-Version: 1.0 (1.0) Date: Fri, 15 Oct 2021 19:15:58 +0200 Message-Id: <9126A0CD-C13F-4350-ABB8-F8B7F79CF2C3@inria.fr> References: Cc: Emad Omara In-Reply-To: To: sframe@ietf.org X-Mailer: iPhone Mail (19A348) Archived-At: Subject: Re: [Sframe] Adoption call for draft-omara-sframe-01 X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 17:16:07 -0000 --Apple-Mail-0A8B126D-02F3-48C5-98CC-8AF12230C926 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I support adoption as a WG item. B. > On Oct 15, 2021, at 7:14 PM, Emad Omara wrote: >=20 > =EF=BB=BF > I support adopting this draft as a working group item. >=20 >=20 >=20 >> On Fri, Oct 15, 2021 at 10:05 AM Youenn Fablet wrote: >> I support adopting this draft as a working group item. >>=20 >> The SFrame format, or variants of it, are being deployed in existing appl= ications. >> This gives confidence in the fact that the SFrame format described in the= document is solving real problems. >> The current draft document allowed to implement it in at least two indepe= ndent implementations (Cisco and Safari), both implementations passing the s= ame test suite. >> This gives confidence in the level of details used to describe the SFrame= format. >>=20 >> I look forward for additional work in the area, to address Bernard=E2=80=99= s points and more. >> The suggestion to move part of the current document in a separate documen= t seems a good idea. >> This modularity would for instance be useful in W3C specifications buildi= ng on the SFrame format, in particular the being standardised SFrameTransfor= m. >>=20 >> I do not think that this is a blocker for adopting the document as is. >> Adoption by the WG is just a starting point, and I believe that contribut= ors of this document are aware that more work is needed. >>=20 >> Thanks, >> Y >>=20 >>> ---------- Forwarded message --------- >>> From: Martin Thomson >>> Date: Sun, Oct 10, 2021 at 7:36 PM >>> Subject: [Sframe] Adoption call for draft-omara-sframe-01 >>> To: >>>=20 >>>=20 >>> https://datatracker.ietf.org/doc/html/draft-omara-sframe-01 >>>=20 >>> Please respond to this email before AOE 31 October 2021 if you support a= dopting draft-omara-sframe (currently -01) as a working group item. If you w= ould prefer we not adopt this work, please respond with an explanation of wh= y and ideally what you would like to see addressed before we do that. >>>=20 >>> We're running this a tiny bit longer than a typical adoption call. Last= time we talked about adoption there were a few concerns raised about the dr= aft. We want to make sure those concerns are addressed, or at least those w= ith concerns are satisfied that their concerns could be addressed. >>>=20 >>> Martin, for the chairs >>>=20 >>> --=20 >>> Sframe mailing list >>> Sframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/sframe >>=20 >> --=20 >> Sframe mailing list >> Sframe@ietf.org >> https://www.ietf.org/mailman/listinfo/sframe > --=20 > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe --Apple-Mail-0A8B126D-02F3-48C5-98CC-8AF12230C926 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I s= upport adoption as a WG item.
B.

On Oct 15, 2021, at 7:14 PM, Emad Omara <e= mad.omara@gmail.com> wrote:

=EF=BB=BF
I support adopting this dr= aft as a working group item.



On Fri, Oct 15,= 2021 at 10:05 AM Youenn Fablet <youenn=3D40apple.com@dmarc.ietf.org> wrote:
I support adopting this draft as a working group item.

The SFrame format, o= r variants of it, are being deployed in existing applications.
This gives confidence in the fact that the SFrame fo= rmat described in the document is solving real problems.
The curre= nt draft document allowed to implement it in at least two independent implem= entations (Cisco and Safari), both implementations passing the same test sui= te.
This gives confidence in the level of details used to describe= the SFrame format.

I look forward for additional w= ork in the area, to address Bernard=E2=80=99s points and more.
The= suggestion to move part of the current document in a separate document seem= s a good idea.
This modularity would for instance be useful in W3C= specifications building on the SFrame format, in particular the being stand= ardised SFrameTransform.

I do not think that this i= s a blocker for adopting the document as is.
Adoption by the W= G is just a starting point, and I believe that contributors of this document= are aware that more work is needed.

Thanks,
<= div> Y

=
---------- Forwarded message ---------=
From: Martin Thomson <mt= @lowentropy.net>
Date: Sun, Oct 10, 2021 at 7:36 PM
Subj= ect: [Sframe] Adoption call for draft-omara-sframe-01
To: <sframe@ietf.org>
=

https://datatracker.ietf.org/doc/ht= ml/draft-omara-sframe-01

Please respond to this email before AOE 31 October 2021 if you support adopt= ing draft-omara-sframe (currently -01) as a working group item.  If you= would prefer we not adopt this work, please respond with an explanation of w= hy and ideally what you would like to see addressed before we do that.

We're running this a tiny bit longer than a typical adoption call.  Las= t time we talked about adoption there were a few concerns raised about the d= raft.  We want to make sure those concerns are addressed, or at least t= hose with concerns are satisfied that their concerns could be addressed.
=
Martin, for the chairs

--
Sframe mailing list
Sframe@ietf.org
= https://www.ietf.org/mailman/listinfo/sframe

--
Sframe mailing list
Sframe@ietf.org
= https://www.ietf.org/mailman/listinfo/sframe
--
Sframe mailing list
Sframe@ietf.or= g
https://www.ietf.org/mailman/listinfo/sframe
= --Apple-Mail-0A8B126D-02F3-48C5-98CC-8AF12230C926-- From nobody Fri Oct 15 14:16:51 2021 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 C9DA93A0B6C for ; Fri, 15 Oct 2021 14:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20210112.gappssmtp.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 CSPbeLOnlluS for ; Fri, 15 Oct 2021 14:16:44 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 B03783A0B6B for ; Fri, 15 Oct 2021 14:16:44 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id 188so9179340iou.12 for ; Fri, 15 Oct 2021 14:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HC42Qb9mcLDS63kcMX27rfynYz0X0yU3Y1k36v+0HPE=; b=21Ydgv2pIr7e+cazTlOCUcUSUpIDhSWDit1eZcHd3JvoSxyzkLif3lpKJX0OHDaq1k 2xNwYL+f+DzhOQD/YmMQxTCLaNVmhqXdNmAiAhw7uEZ8yiVL8fjlPdTkXhmGPZt6NChJ IauihlCAEIOTDQqBA8W3G5jr6rbr0yVdRf0o9KlgXCxMlzb2/cKdk5oyhOFzRNAipRfh xN+X7e6DGUBTxDLzOPWbX+vkCnCiqzcvmKx5q2fuNzkq5YUCq2l2uYtR1vodtbK/VHAk zdw73D+zKhjhIVhBntnGimQt+4NCviW6SiFtW+loJZkXHWcw7fHSK/zdjAHciOWpy3lm PFIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HC42Qb9mcLDS63kcMX27rfynYz0X0yU3Y1k36v+0HPE=; b=uiCCQqvoW9bxUDPVyHVrEUuKipAat3V4EUO1DO5PoTImzXoPHoCHwoWBu0HAbRideS aSNKdqLNmJNhratnb2bRyTWDnCe0VhP7EG5mi59VKY5kNn3VjDNYxd2lhinOPlAucDwu 24QnRWIo9AYYEjyFqPjukNICPyH2DYLNX+r3Tnfx1NByUQQfTXy/7mJ0V5hiqLeZ59fy k/6HyIZIFrollbBNCZw8vR0Sdyo+WyJsOw1EW5nhgkVW/JoAGC8WASlLFN9joflVaIP3 6mrKzgsgfoj/ByFBYS3yFf05BqPN5OxCQjwYm914iPlvwPHRx18/aqWIwZZ7Z7/DzIKj oZyA== X-Gm-Message-State: AOAM532PmpSJsf6RjEyRjS2B7p757uLiCj894JeOv7eJ+gHankbm3WUO OFDsHpS8KZ/LNy3vEwb1wIMbw/zNiuXWvsDDY0/82Et9lt34DA== X-Google-Smtp-Source: ABdhPJyiIpU0xVfbtLRPkpuTzqhXZghR3jmB9QOiyv5erVyVPmd4SY3Ou7VhVO8PlDneNtSJD9lYcEm1GYSAfcjI1tU= X-Received: by 2002:a6b:db0d:: with SMTP id t13mr5369795ioc.149.1634332603790; Fri, 15 Oct 2021 14:16:43 -0700 (PDT) MIME-Version: 1.0 References: <7e721f57-e7ee-4f47-8663-2b485aeabd1a@www.fastmail.com> In-Reply-To: <7e721f57-e7ee-4f47-8663-2b485aeabd1a@www.fastmail.com> From: Eric Rescorla Date: Fri, 15 Oct 2021 14:16:07 -0700 Message-ID: To: Martin Thomson Cc: sframe@ietf.org Content-Type: multipart/alternative; boundary="0000000000004b4eb705ce6ab61d" Archived-At: Subject: Re: [Sframe] Adoption call for draft-omara-sframe-01 X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 21:16:50 -0000 --0000000000004b4eb705ce6ab61d Content-Type: text/plain; charset="UTF-8" TL;DR. This document needs a fair bit of work but I think we should adopt it and work on it in the WG rather than making the authors do a pile of work beforehand. At the high level, I tend to agree with Bernard that this is doing a bit too much. Specifically, while SFrame is designed to be embedded in an E2E keying system, there's not much about it that requires E2E. I would consider breaking that material out into a different document or perhaps moving it into an appendix as stage setting. I also think it would be good if the document were somewhat more agnostic about SPacket and SFrame; it seems like each version has advantages in some cases. DETAILED COMMENTS S 4. The stuff here 4. seems informational. We propose a frame level encryption mechanism that provides effective end-to-end encryption, is simple to implement, has no dependencies on RTP, and minimizes encryption bandwidth overhead. Because SFrame encrypts the full frame, rather than individual packets, bandwidth overhead is reduced by having a single IV and authentication tag for each media frame. As noted above, there's nothing E2E about this. It's just designed to it into a certain setting. I *do* think it would be useful to explain the extent to which this depends on SRTP for security, if at all. S 4.2. Since each endpoint can send multiple media layers, each frame will have a unique frame counter that will be used to derive the encryption IV. The frame counter must be unique and monotonically increasing to avoid IV reuse. Reserved (R): 1 bit This field MUST be set to zero on sending, and MUST be ignored by receivers. Counter Length (LEN): 3 bits This field indicates the length of the CTR fields in bytes (1-8). I am having trouble reading this text. Is it saying that the CTR field can be 1-8 bytes long? But of course, 3 bits can only encode 0-7, so you need to explain it's +1, I guess? S 4.3.5. Unlike messaging application, in video calls, receiving a duplicate frame doesn't necessary mean the client is under a replay attack, there are other reasons that might cause this, for example the sender might just be sending them in case of packet loss. This is true for messaging as well. SFrame decryptors use the highest received frame counter to protect against this. It allows only older frame pithing a short interval to support out of order delivery. Should this say "within". You will eventually need more detail here about how this works. In particular, you shouldn't update until you have decrypted. S 4.4. +========+==========================+====+====+====+===========+ | Value | Name | Nh | Nk | Nn | Reference | +========+==========================+====+====+====+===========+ | 0x0001 | AES_CM_128_HMAC_SHA256_8 | 32 | 16 | 12 | RFC XXXX | +--------+--------------------------+----+----+----+-----------+ | 0x0002 | AES_CM_128_HMAC_SHA256_4 | 32 | 16 | 12 | RFC XXXX | +--------+--------------------------+----+----+----+-----------+ | 0x0003 | AES_GCM_128_SHA256 | 32 | 16 | 12 | RFC XXXX | +--------+--------------------------+----+----+----+-----------+ | 0x0004 | AES_GCM_256_SHA512 | 64 | 32 | 12 | RFC XXXX | +--------+--------------------------+----+----+----+-----------+ A 4 byte tag is pretty short. What's the reason for specifyin anything with SHA-512 as the KDF? In a session that uses multiple media streams, different ciphersuites might be configured for different media streams. For example, in order to conserve bandwidth, a session might use a ciphersuite with 80-bit tags for video frames and another ciphersuite with 32-bit tags for audio frames. A little weird to say this when you don't specify anything with 80 bit tags. On Sun, Oct 10, 2021 at 4:36 PM Martin Thomson wrote: > https://datatracker.ietf.org/doc/html/draft-omara-sframe-01 > > Please respond to this email before AOE 31 October 2021 if you support > adopting draft-omara-sframe (currently -01) as a working group item. If > you would prefer we not adopt this work, please respond with an explanation > of why and ideally what you would like to see addressed before we do that. > > We're running this a tiny bit longer than a typical adoption call. Last > time we talked about adoption there were a few concerns raised about the > draft. We want to make sure those concerns are addressed, or at least > those with concerns are satisfied that their concerns could be addressed. > > Martin, for the chairs > > -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --0000000000004b4eb705ce6ab61d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
TL;DR. This document needs a fair bit of work but I think<= br>we should adopt it and work on it in the WG rather than
making the au= thors do a pile of work beforehand.

At the high level, I tend to agr= ee with Bernard that this is
doing a bit too much. Specifically, while S= Frame is designed
to be embedded in an E2E keying system, there's no= t much
about it that requires E2E. I would consider breaking that
mat= erial out into a different document or perhaps moving
it into an appendi= x as stage setting.

I also think it would be good if the document we= re somewhat
more agnostic about SPacket and SFrame; it seems like eachversion has advantages in some cases.


DETAILED COMMENTS
S 4= .

The stuff here 4. seems informational.

=C2=A0 =C2=A0We prop= ose a frame level encryption mechanism that provides effective
=C2=A0 = =C2=A0end-to-end encryption, is simple to implement, has no dependencies on=
=C2=A0 =C2=A0RTP, and minimizes encryption bandwidth overhead.=C2=A0 Be= cause SFrame
=C2=A0 =C2=A0encrypts the full frame, rather than individua= l packets, bandwidth
=C2=A0 =C2=A0overhead is reduced by having a single= IV and authentication tag for
=C2=A0 =C2=A0each media frame.

As = noted above, there's nothing E2E about this. It's just designed to<= br>it into a certain setting. I *do* think it would be useful to explainthe extent to which this depends on SRTP for security, if at all.

<= br>S 4.2.
=C2=A0 =C2=A0Since each endpoint can send multiple media layer= s, each frame will
=C2=A0 =C2=A0have a unique frame counter that will be= used to derive the
=C2=A0 =C2=A0encryption IV.=C2=A0 The frame counter = must be unique and monotonically
=C2=A0 =C2=A0increasing to avoid IV reu= se.


=C2=A0 =C2=A0Reserved (R): 1 bit This field MUST be set to z= ero on sending, and
=C2=A0 =C2=A0MUST be ignored by receivers.=C2=A0 Cou= nter Length (LEN): 3 bits This
=C2=A0 =C2=A0field indicates the length o= f the CTR fields in bytes (1-8).

I am having trouble reading this te= xt. Is it saying that the CTR field
can be 1-8 bytes long? But of course= , 3 bits can only encode 0-7, so
you need to explain it's +1, I gues= s?


S 4.3.5.

=C2=A0 =C2=A0Unlike messaging application, in= video calls, receiving a duplicate
=C2=A0 =C2=A0frame doesn't neces= sary mean the client is under a replay attack,
=C2=A0 =C2=A0there are ot= her reasons that might cause this, for example the sender
=C2=A0 =C2=A0m= ight just be sending them in case of packet loss.

This is true for m= essaging as well.

=C2=A0 =C2=A0SFrame decryptors
=C2=A0 =C2=A0use= the highest received frame counter to protect against this.=C2=A0 It
= =C2=A0 =C2=A0allows only older frame pithing a short interval to support ou= t of
=C2=A0 =C2=A0order delivery.

Should this say "within&qu= ot;. You will eventually need more detail here
about how this works. In = particular, you shouldn't update until you
have decrypted.

S 4.4.

=C2=A0 =C2=A0 =C2=A0+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D= =3D=3D+=3D=3D=3D=3D+=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
=C2= =A0 =C2=A0 =C2=A0| Value =C2=A0| Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Nh | Nk | Nn | Reference |
=C2=A0 = =C2=A0 =C2=A0+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D+=3D=3D=3D=3D+=3D=3D= =3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
=C2=A0 =C2=A0 =C2=A0| 0x0001 |= AES_CM_128_HMAC_SHA256_8 | 32 | 16 | 12 | RFC XXXX =C2=A0|
=C2=A0 =C2= =A0 =C2=A0+--------+--------------------------+----+----+----+-----------+<= br>=C2=A0 =C2=A0 =C2=A0| 0x0002 | AES_CM_128_HMAC_SHA256_4 | 32 | 16 | 12 |= RFC XXXX =C2=A0|
=C2=A0 =C2=A0 =C2=A0+--------+------------------------= --+----+----+----+-----------+
=C2=A0 =C2=A0 =C2=A0| 0x0003 | AES_GCM_12= 8_SHA256 =C2=A0 =C2=A0 =C2=A0 | 32 | 16 | 12 | RFC XXXX =C2=A0|
=C2=A0 = =C2=A0 =C2=A0+--------+--------------------------+----+----+----+----------= -+
=C2=A0 =C2=A0 =C2=A0| 0x0004 | AES_GCM_256_SHA512 =C2=A0 =C2=A0 =C2= =A0 | 64 | 32 | 12 | RFC XXXX =C2=A0|
=C2=A0 =C2=A0 =C2=A0+--------+----= ----------------------+----+----+----+-----------+

A 4 byte tag is p= retty short.

What's the reason for specifyin anything with SHA-5= 12 as the
KDF?


=C2=A0 =C2=A0In a session that uses multiple m= edia streams, different ciphersuites
=C2=A0 =C2=A0might be configured fo= r different media streams.=C2=A0 For example, in
=C2=A0 =C2=A0order to c= onserve bandwidth, a session might use a ciphersuite with
=C2=A0 =C2=A08= 0-bit tags for video frames and another ciphersuite with 32-bit tags
=C2= =A0 =C2=A0for audio frames.

A little weird to say this when you don&= #39;t specify anything with 80 bit
tags.







=

= On Sun, Oct 10, 2021 at 4:36 PM Martin Thomson <mt@lowentropy.net> wrote:
https://dat= atracker.ietf.org/doc/html/draft-omara-sframe-01

Please respond to this email before AOE 31 October 2021 if you support adop= ting draft-omara-sframe (currently -01) as a working group item.=C2=A0 If y= ou would prefer we not adopt this work, please respond with an explanation = of why and ideally what you would like to see addressed before we do that.<= br>
We're running this a tiny bit longer than a typical adoption call.=C2= =A0 Last time we talked about adoption there were a few concerns raised abo= ut the draft.=C2=A0 We want to make sure those concerns are addressed, or a= t least those with concerns are satisfied that their concerns could be addr= essed.

Martin, for the chairs

--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--0000000000004b4eb705ce6ab61d-- From nobody Sat Oct 16 03:00:53 2021 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 0C4933A1233 for ; Sat, 16 Oct 2021 03:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.2 X-Spam-Level: ** X-Spam-Status: No, score=2.2 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, FAKE_REPLY_B=4.299, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=raphaelrobert.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 bAObHiDVaGGq for ; Sat, 16 Oct 2021 03:00:46 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 9D7293A1232 for ; Sat, 16 Oct 2021 03:00:46 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id g25so30650229wrb.2 for ; Sat, 16 Oct 2021 03:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raphaelrobert.com; s=rr; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=/GlRl/p9lJbXG3NfcK9XT29ESMEqqYf3EI8FLT+JC1E=; b=dGK0MaK9TUhIj+8tkUh+cWeb+p1AKX1+eArP3nl9HL6YOCuoIIU2eCd10haOjm8giS +C9We5z4Lg7YATflv2yBZixBxsUAfrBUjslHgI04HY7G+8qseBKzxbCIUBL8TCWaqPIv w9C8dXOjfwNc6/4WoC36YVoD+6S206NB7HaaQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=/GlRl/p9lJbXG3NfcK9XT29ESMEqqYf3EI8FLT+JC1E=; b=Z3oC99u/Y3kgBEgPUj2R9au6ovZT4AvFPKBTcDUg8+DR/tkhh3YaFPN6pdzDX9Ck2j I5G6S9yQ6NLUkoD60MVbROFPspr0sSKucy6en8v1USSULk/eokPVB7G0yjRYl8ykCN5o 159UnZ9K3odRh0hhQAf/5uLI2OylW/iJVWLfp6YH3UBpgBo1MfJgA+J/alf4VwmlO+/q jZKjdV7/9r50wYd+ic5UThYagKHcfYrpZevN9h0vP1AM9lBRIPqa6ADnmVwqkW1KOWcu O7tOb/5mNb+b5iJNFovq6pWpSsK76B4FEGecKcSPn+0AnXGXu03Bv+P1/Tj9fbEEYmed 4gbQ== X-Gm-Message-State: AOAM533Ri+COnVD7sz34GaRBxz9xKtkoeWYU6lgHJElEKjgrvGy67CkY AUnaKW2LL98wCgVa4Gv4o1Q2lOVeqIHHa8Z4 X-Google-Smtp-Source: ABdhPJwtmiyXq6SlUhOOqigqCEYYVtMMRi6+MKersE10AZRcDmTxZO5g+jKS0IcOKhFyh8xo2f7VUA== X-Received: by 2002:a5d:4b43:: with SMTP id w3mr21378384wrs.404.1634378443993; Sat, 16 Oct 2021 03:00:43 -0700 (PDT) Received: from smtpclient.apple ([2a02:8109:9f40:5ac4:31a0:8f8a:50f:c8a]) by smtp.gmail.com with ESMTPSA id r4sm9141772wrz.58.2021.10.16.03.00.43 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Oct 2021 03:00:43 -0700 (PDT) From: Raphael Robert Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Message-Id: <12CFD23A-3151-48A5-9645-0E900ECED14C@raphaelrobert.com> Date: Sat, 16 Oct 2021 12:00:43 +0200 To: sframe@ietf.org X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Sframe] Adoption call for draft-omara-sframe-01 X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2021 10:00:52 -0000 I support the adoption as a working group item. Raphael On 11/10/2021 01:35, Martin Thomson wrote:=20 > https://datatracker.ietf.org/doc/html/draft-omara-sframe-01=20 > > Please respond to this email before AOE 31 October 2021 if you = support adopting draft-omara-sframe (currently -01) as a working group = item. If you would prefer we not adopt this work, please respond with an = explanation of why and ideally what you would like to see addressed = before we do that.=20 > > We're running this a tiny bit longer than a typical adoption call. = Last time we talked about adoption there were a few concerns raised = about the draft. We want to make sure those concerns are addressed, or = at least those with concerns are satisfied that their concerns could be = addressed.=20 > > Martin, for the chairs= From nobody Thu Oct 28 14:17:40 2021 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 624D63A11FE for ; Thu, 28 Oct 2021 14:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 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, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=alphaexplorationco.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 aKUEVQHoKGqH for ; Thu, 28 Oct 2021 14:17:35 -0700 (PDT) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 EBF6C3A11FF for ; Thu, 28 Oct 2021 14:17:34 -0700 (PDT) Received: by mail-ot1-x334.google.com with SMTP id 71-20020a9d034d000000b00553e24ce2b8so5833169otv.7 for ; Thu, 28 Oct 2021 14:17:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphaexplorationco.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=vhr4OyLw7KxyCmSp+eLHuk3VqpNr5FFA8gDorcljsv0=; b=JRZxSBSwYXN5hyeybBn6pHa2imO8I31RhaAszO3PzYm0T1FtG19TU5K6s+ZJIGD3od nDa04kLzMGNatqwGklzi3jr8cZF8ZwbwCaXTZQsCxhVUSB0tsEuQfLnl2m1AjoObSDtZ C60rlH6x6GXqgHbpYQggRni/O0UovgSSxq0bwfYU4HLpVkxy3f/qCzWfzPzxbVK9/h3x rkvCzr3B0taI7ihcGjw5pJLn1gxspKpQ8yIZBZgerNzwGON0n/LdMcvXl6L+5wEVrl8l YG04au2BhyMkYxbbZ/rugzHphERTuWi3MGlCPfxRqpdfe7HRrIfQtBncRn2/pSKCVpbp 2rSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=vhr4OyLw7KxyCmSp+eLHuk3VqpNr5FFA8gDorcljsv0=; b=67Jn6XJAhmx4TBGTHQt+/48zBZJ+XYAzURpUiI/4/kBlhARwLi5emGsVi2K0CenXiA 1fV90KfIXJ7PsDyvE4ttAYxfJ3IIL1VCP24pXjDqtysSYbYjJqgnz9FkZahI8bycnUy3 xDTyC53aRLLfm02ZtK3JItsI/S4jfrwFhepfdCfEuHb+0fJAlAdkbOsF58OftkWybKOP 2rkK4KBwfMoCW7Wd4c7npJuDvu8Raa/64oqXCEvGtXmE4mf9FZr5A00GFPPfsXwaAxNw wKOETkuizrK1pSDKLEhTmDisdUvZeqpfYkPZsosI9+Ht7jUgFJo1ZhyC+MQuaYk35KZI gqxA== X-Gm-Message-State: AOAM533T9qDf43Yq8Rhxw0KQEoNTWlvCYZb0EuFZodBML7I+peij76QU upGu4ngk0V6u6Uzeqw5j0GBY4JnGdhZiZSnNqh2rTVe+ACMnlA== X-Google-Smtp-Source: ABdhPJzRZbUSYcWjltAgeC7N0S0SI27E8vLKzFByA/qYmrHooBoaPdHAOtHSCB2btOqlg3ae8N0S2w5p1wjQNRXlRuo= X-Received: by 2002:a05:6830:18d:: with SMTP id q13mr5439011ota.264.1635455853050; Thu, 28 Oct 2021 14:17:33 -0700 (PDT) MIME-Version: 1.0 References: <12CFD23A-3151-48A5-9645-0E900ECED14C@raphaelrobert.com> In-Reply-To: <12CFD23A-3151-48A5-9645-0E900ECED14C@raphaelrobert.com> From: Justin Uberti Date: Thu, 28 Oct 2021 14:17:22 -0700 Message-ID: Cc: sframe@ietf.org Content-Type: multipart/alternative; boundary="0000000000002ad57605cf703d5c" Archived-At: Subject: Re: [Sframe] Adoption call for draft-omara-sframe-01 X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2021 21:17:39 -0000 --0000000000002ad57605cf703d5c Content-Type: text/plain; charset="UTF-8" I support the adoption as a working group item. On Sat, Oct 16, 2021 at 3:00 AM Raphael Robert wrote: > I support the adoption as a working group item. > > Raphael > > On 11/10/2021 01:35, Martin Thomson wrote: > > https://datatracker.ietf.org/doc/html/draft-omara-sframe-01 > > > Please respond to this email before AOE 31 October 2021 if you support > adopting draft-omara-sframe (currently -01) as a working group item. If you > would prefer we not adopt this work, please respond with an explanation of > why and ideally what you would like to see addressed before we do that. > > > We're running this a tiny bit longer than a typical adoption call. > Last time we talked about adoption there were a few concerns raised about > the draft. We want to make sure those concerns are addressed, or at least > those with concerns are satisfied that their concerns could be addressed. > > > Martin, for the chairs > -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --0000000000002ad57605cf703d5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support the adoption as a working group=C2=A0item.
=
On Sat= , Oct 16, 2021 at 3:00 AM Raphael Robert <ietf=3D40raphaelrobert.com@dmarc.ietf.org> w= rote:
I support = the adoption as a working group item.

Raphael

On 11/10/2021 01:35, Martin Thomson wrote:
> https://datatracker.ietf.org/doc/htm= l/draft-omara-sframe-01
> > Please respond to this email before AOE 31 October 2021 if you su= pport adopting draft-omara-sframe (currently -01) as a working group item. = If you would prefer we not adopt this work, please respond with an explanat= ion of why and ideally what you would like to see addressed before we do th= at.
> > We're running this a tiny bit longer than a typical adoption = call. Last time we talked about adoption there were a few concerns raised a= bout the draft. We want to make sure those concerns are addressed, or at le= ast those with concerns are satisfied that their concerns could be addresse= d.
> > Martin, for the chairs
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--0000000000002ad57605cf703d5c--