From nobody Thu Mar 1 09:16:13 2018 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 802EA12EB6C; Thu, 1 Mar 2018 09:15:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Cc: draft-ietf-rtcweb-jsep@ietf.org, The IESG , ted.ietf@gmail.com, adam@nostrum.com, rtcweb-chairs@ietf.org, Ted Hardie , rtcweb@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151992455851.10105.6918486857626892288.idtracker@ietfa.amsl.com> Date: Thu, 01 Mar 2018 09:15:58 -0800 Archived-At: Subject: [rtcweb] Protocol Action: 'JavaScript Session Establishment Protocol' to Proposed Standard (draft-ietf-rtcweb-jsep-24.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 17:15:59 -0000 The IESG has approved the following document: - 'JavaScript Session Establishment Protocol' (draft-ietf-rtcweb-jsep-24.txt) as Proposed Standard This document is the product of the Real-Time Communication in WEB-browsers Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ Technical Summary This document describes the mechanisms for allowing a JavaScript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API and relates this signaling to the media streams and data channels which are created and managed by the application. It is effectively the core signaling protocol for WebRTC endpoints. Working Group Summary The working group process leading up to this document was quite long and required unusual levels of coordination with the W3C group producing the API and the IETF working groups responsible for the underlying mechanisms (especially those responsible for SDP, ICE, and RTP). During the process, there were some decisions which moved between groups in ways that made consensus difficult to judge because the groups were not completely congruent. The shepherd's evaluation is that the contents of this document do have consensus of the interested parties, and the responsible area director concurs. Document Quality The protocol has various levels of implementation in release versions of at least five major web browsers (Chrome, Safari, Firefox, Edge, and Opera) and in hundreds of applications. Those who contributed significant text and reviews are mentioned in the acknowledgements section. The GEN-ART review was specifically (and by request) conducted by a communications and SDP expert. Personnel Ted Hardie is the document shepherd. Adam Roach is the responsible area director. From nobody Thu Mar 1 15:40:47 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020CD12704A for ; Thu, 1 Mar 2018 15:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 KMmo6YsXd4jw for ; Thu, 1 Mar 2018 15:40:44 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8FE34126B6D for ; Thu, 1 Mar 2018 15:40:44 -0800 (PST) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w21NegOb015691 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 1 Mar 2018 17:40:44 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: "rtcweb@ietf.org" , draft-ietf-rtcweb-fec.all@tools.ietf.org From: Adam Roach Message-ID: Date: Thu, 1 Mar 2018 17:40:42 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [rtcweb] AD Review: draft-ietf-rtcweb-fec-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 23:40:46 -0000 I have completed my AD review of draft-ietf-rtcweb-fec-07, and found only very minor editorial nits, which should be treated as normal last call comments. Due to this document's close relationship with draft-ietf-payload-flexible-fec-scheme, I plan to wait until both documents are ready to progress before placing draft-ietf-rtcweb-fec into IETF Last Call. Thanks to everyone who contributed to this document over its lifetime. Nits follow. --------------------------------------------------------------------------- §2 Since this document uses "should" in non-normative sentences, please use the RFC 8174 boilerplate. --------------------------------------------------------------------------- §3.3    Some audio codecs, notably Opus [RFC6716] and AMR [RFC4867] support Insert comma before "support" --------------------------------------------------------------------------- §4.1    against individual losses, with minimal overhead.  Note that as    indicated above the built-in Opus FEC only provides single-frame Insert commas before and after the phrase "as indicated above" --------------------------------------------------------------------------- §7    Implementations MAY support additional FEC mechanisms if desired,    e.g.  [RFC5109]. - Change the comma after "desired" to a semicolon. - Insert a comma after "e.g." --------------------------------------------------------------------------- /a From nobody Thu Mar 1 17:57:15 2018 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF761126BF0; Thu, 1 Mar 2018 17:57:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151995583388.15787.2908327357271443159@ietfa.amsl.com> Date: Thu, 01 Mar 2018 17:57:13 -0800 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-06.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 01:57:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers WG of the IETF. Title : WebRTC IP Address Handling Requirements Authors : Justin Uberti Guo-wei Shieh Filename : draft-ietf-rtcweb-ip-handling-06.txt Pages : 10 Date : 2018-03-01 Abstract: This document provides information and requirements for how IP addresses should be handled by WebRTC implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-06 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-ip-handling-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-ip-handling-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 1 18:00:18 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD26B127058 for ; Thu, 1 Mar 2018 18:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.896 X-Spam-Level: X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CInmIjyADcTR for ; Thu, 1 Mar 2018 18:00:16 -0800 (PST) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (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 F12FF126BF0 for ; Thu, 1 Mar 2018 18:00:15 -0800 (PST) Received: by mail-ua0-x234.google.com with SMTP id c14so5201065uak.7 for ; Thu, 01 Mar 2018 18:00:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=ZtVNfZbpfDsice7Gm9fmWjU+D89LHrxt/VkzMwE8LDk=; b=tGN0w9tsozyEcZajLZj3W2gNy7sZSxMC9aG870ClNoI9FQF5h0E1URQ7BoTsaWp75G /oVR6smesGI5LPxhXNvSdEIXGV6/a2KoQM63ym7g6sXwKZamwcVwnkl2fTu1r+wP1nDo u0Z2e7fJYZQC5n75V7q/zdxmSJ7OBDSB1CKIMJkr3pNS14Ci9T3OMNXQkXrvVHqHijDz SF+ugjdNymD+5UjP8vc4NAWG53+MOYDHMAHh2kLI8tlMWEZuFEH72YFWlaP2o4BmLMay /6ooHYZnBIdM0Sr/tIrByO8C46v8dUX7cGaislOjku33fKD7t1YR01hIjB7gyHu55R5Y nbDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=ZtVNfZbpfDsice7Gm9fmWjU+D89LHrxt/VkzMwE8LDk=; b=POBHuLssIqRqjV68YUP+wPaVlBm4/ChOLtJ54U2BkCcSAuOuBh6uLkyO/cgGwYcKvc /vWN5TzKZvgEtbhBTZdurkrh0DgZ2iRuc8AVbhwhkT7t8BH/qgHH9+bCU/JKGZgPSkbd X6DJJf7MgnRFgVrAFMVWdXD6+BHMitEy7rqNbrO+uecvHJ2PP/ZxdsBjlNLGX82ndWuh G2RujJ8g8cc/cYXBuvud4eM2NTG4L2PHUYi5bx4Qr7SidERniyBQHSaVWKPdfWZgGWRA Unm+D6w3HJxQh3wp6Jb+KyeVL9Xg78Hf3S8XKAHlZQvv8IkJtpnIW8SpKhjR+X78epHh EIwA== X-Gm-Message-State: APf1xPCp+P8ESej83QO6c6AD4s+R5Eky0G2Zzvn0E/hrTOaA5iG+y7rk AUGeYmlmDbOzSg1K58UGl27oSSjKkaxWR/jA26buMho7 X-Google-Smtp-Source: AG47ELvMjaadB0X2UWhfsCOZPxDz/uD6abChqBt0HD/hAiAQRVVeFcVzIuCF+QhnJ8LDGtWrx4wesQvUAwzVlnNgXlg= X-Received: by 10.176.93.220 with SMTP id l28mr2837209uag.100.1519956014517; Thu, 01 Mar 2018 18:00:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.167.206 with HTTP; Thu, 1 Mar 2018 17:59:53 -0800 (PST) In-Reply-To: <151995583388.15787.2908327357271443159@ietfa.amsl.com> References: <151995583388.15787.2908327357271443159@ietfa.amsl.com> From: Justin Uberti Date: Thu, 1 Mar 2018 17:59:53 -0800 Message-ID: Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="f403043efcd052545d0566645623" Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-06.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 02:00:18 -0000 --f403043efcd052545d0566645623 Content-Type: text/plain; charset="UTF-8" This minor update addresses the comments from Martin and Stephen, as discussed on the list. On Thu, Mar 1, 2018 at 5:57 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Real-Time Communication in WEB-browsers > WG of the IETF. > > Title : WebRTC IP Address Handling Requirements > Authors : Justin Uberti > Guo-wei Shieh > Filename : draft-ietf-rtcweb-ip-handling-06.txt > Pages : 10 > Date : 2018-03-01 > > Abstract: > This document provides information and requirements for how IP > addresses should be handled by WebRTC implementations. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-06 > https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-ip-handling-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-ip-handling-06 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f403043efcd052545d0566645623 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This minor update addresses the comments from Martin and S= tephen, as discussed on the list.

On Thu, Mar 1, 2018 at 5:57 PM, <internet-drafts@= ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Real-Time Communication in WEB-browsers WG= of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= WebRTC IP Address Handling Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Just= in Uberti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Guo-wei Shieh
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-ip-handling-06.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 10
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-03-01

Abstract:
=C2=A0 =C2=A0This document provides information and requirements for how IP=
=C2=A0 =C2=A0addresses should be handled by WebRTC implementations.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc= /draft-ietf-rtcweb-ip-handling/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-i= etf-rtcweb-ip-handling-06
https://datatracker.ietf.org/d= oc/html/draft-ietf-rtcweb-ip-handling-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-ip-handling-06


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

--f403043efcd052545d0566645623-- From nobody Fri Mar 2 08:52:46 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B17012D72F for ; Fri, 2 Mar 2018 08:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucXzFsfZwefT for ; Fri, 2 Mar 2018 08:52:43 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 1B2C8126DC2 for ; Fri, 2 Mar 2018 08:52:43 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id b65so6117841vka.2 for ; Fri, 02 Mar 2018 08:52:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2Q5yR25sj4U3HtJjOEjPkegFpwgAXfKm/lte3jNVayo=; b=EN4TJoOIB02+1aiDbbm6bWd6kjs0O6aBAzYRyzjpS07CS2DIpAnD2d/WD7+v3iZ3ji nl3lXiMICw70KcBFj3m9QVmAMb4qMRBMAJXZZBItcdywGI1LI10t/iAHRuiB/qcYBk3D VTaGnY/euX2Hd5F9j/Re2zBOpmJ7zMi+apCBfG+QXJLXVr+lEkLwjHHYXIDabOhr477y gOa6dguWkuSnNfPIPxVSuna3FAUTMY8xHWv+sKRu3gR+Ut5FrK0tyqq9PoWdS8KRsVYe 0cj9i4kTSKEPi3+I2K2Hv9E/lTjMfvkAK95s+H/2eY93zszNy73zF3Mdwi6RCoRoMLDB jNYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2Q5yR25sj4U3HtJjOEjPkegFpwgAXfKm/lte3jNVayo=; b=NIrCF+XqpIrHaQ/ozwHfJ8dvEOn0+02dIWRiLnaeGRr6ZYcOxln1VLnH/9ebX1fVoH Y4qPekulAYV18wt+p93B/LbWYGF9QtlhmuV1bxcDfEjuM/px/b8b2ITW/mc5mpHiQ5Bl vuoqStEPisv3Dc4TL5jNDficjkWo4/QpP4FO2MwaO+B86MEOLwZNj5ZLKg/X5N9IQLFL 3rMq7F9za31gf+C8R4YFphbohd1aNQbH/XVQ0yPeJBY//5zibXHwGNTySK7g3wIhUY/B liJDU+E24FIFlvsUUIQT4evsGNRsVaR2F19BtDgnoD8kDiHU7yOdzUqoS1M97Uuigk4I 9yGA== X-Gm-Message-State: AElRT7HP5eIkPKuYc/tbCMkDGs04wVkcrOlakXQ7UO0R9BG7x8e6qFBf 9BwxIllzYKF7IIPBF72WlaEVjjyrj7qC8A6HwysvLQ== X-Google-Smtp-Source: AG47ELvVm9WBiOhawyRLb8reMu2usU4gHMr6sAaTn3xb9Hpr3ydws7Gk2WHd0l+oWutLp1dNl6wOLHKmCKMkC5lELhI= X-Received: by 10.31.231.5 with SMTP id e5mr3429978vkh.39.1520009561406; Fri, 02 Mar 2018 08:52:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.167.206 with HTTP; Fri, 2 Mar 2018 08:52:20 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Fri, 2 Mar 2018 08:52:20 -0800 Message-ID: To: Adam Roach Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c094c32f7442d056670cd22" Archived-At: Subject: Re: [rtcweb] AD Review: draft-ietf-rtcweb-fec-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 16:52:45 -0000 --94eb2c094c32f7442d056670cd22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 1, 2018 at 3:40 PM, Adam Roach wrote: > I have completed my AD review of draft-ietf-rtcweb-fec-07, and found only > very minor editorial nits, which should be treated as normal last call > comments. > Thanks for the review, and agree with the comments, with one exception. Should I publish a new version of the document with corrections, or wait for the document to progress further? > > Due to this document's close relationship with > draft-ietf-payload-flexible-fec-scheme, I plan to wait until both > documents are ready to progress before placing draft-ietf-rtcweb-fec into > IETF Last Call. > > Thanks to everyone who contributed to this document over its lifetime. > > Nits follow. > > ------------------------------------------------------------ > --------------- > =C2=A72 > > Since this document uses "should" in non-normative sentences, please use > the > RFC 8174 boilerplate. > > ------------------------------------------------------------ > --------------- > =C2=A73.3 > > Some audio codecs, notably Opus [RFC6716] and AMR [RFC4867] support > > Insert comma before "support" > > ------------------------------------------------------------ > --------------- > =C2=A74.1 > > against individual losses, with minimal overhead. Note that as > indicated above the built-in Opus FEC only provides single-frame > > Insert commas before and after the phrase "as indicated above" > > ------------------------------------------------------------ > --------------- > =C2=A77 > > Implementations MAY support additional FEC mechanisms if desired, > e.g. [RFC5109]. > > - Change the comma after "desired" to a semicolon. I think a comma is appropriate here; this is also consistent with how e.g. is used elsewhere in the document. > - Insert a comma after "e.g." > > ------------------------------------------------------------ > --------------- > > > /a > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --94eb2c094c32f7442d056670cd22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Mar 1, 2018 at 3:40 PM, Adam Roach <adam@nostrum.com> wrote:
I have completed my AD review= of draft-ietf-rtcweb-fec-07, and found only very minor editorial nits, whi= ch should be treated as normal last call comments.
Thanks for the review, and agree with the comments, with one ex= ception. Should I publish a new version of the document with corrections, o= r wait for the document to progress further?=C2=A0

Due to this document's close relationship with draft-ietf-payload-flexi= ble-fec-scheme, I plan to wait until both documents are ready to progr= ess before placing draft-ietf-rtcweb-fec into IETF Last Call.

Thanks to everyone who contributed to this document over its lifetime.

Nits follow.

-----------------------------------------------------------------= ----------
=C2=A72

Since this document uses "should" in non-normative sentences, ple= ase use the
RFC 8174 boilerplate.

-----------------------------------------------------------------= ----------
=C2=A73.3

=C2=A0=C2=A0 Some audio codecs, notably Opus [RFC6716] and AMR [RFC4867] su= pport

Insert comma before "support"

-----------------------------------------------------------------= ----------
=C2=A74.1

=C2=A0=C2=A0 against individual losses, with minimal overhead.=C2=A0 Note t= hat as
=C2=A0=C2=A0 indicated above the built-in Opus FEC only provides single-fra= me

Insert commas before and after the phrase "as indicated above"
-----------------------------------------------------------------= ----------
=C2=A77

=C2=A0=C2=A0 Implementations MAY support additional FEC mechanisms if desir= ed,
=C2=A0=C2=A0 e.g.=C2=A0 [RFC5109].

- Change the comma after "desired" to a semicolon.=C2=A0

I think a comma is appropriate here; this is also c= onsistent with how e.g. is used elsewhere in the document.
=C2=A0=
- Insert a comma after "e.g."

-----------------------------------------------------------------= ----------


/a

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

--94eb2c094c32f7442d056670cd22-- From nobody Fri Mar 2 21:46:17 2018 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A95124D37; Fri, 2 Mar 2018 21:46:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152005597078.8302.11475653006623461008@ietfa.amsl.com> Date: Fri, 02 Mar 2018 21:46:10 -0800 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-sdp-09.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 05:46:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers WG of the IETF. Title : Annotated Example SDP for WebRTC Authors : Suhas Nandakumar Cullen Jennings Filename : draft-ietf-rtcweb-sdp-09.txt Pages : 119 Date : 2018-03-02 Abstract: The Real-Time Communications in WEB-browsers (Rtcweb) working group is charged to provide protocol support for direct interactive rich communication using audio, video and data between two peers' web browsers. With in the Rtcweb framework, Session Description protocol (SDP) is used for negotiating session capabilities between the peers. Such a negotiation happens based on the SDP Offer/Answer exchange mechanism. This document provides an informational reference in describing the role of SDP and the Offer/Answer exchange mechanism for the most common Rtcweb use-cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sdp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-sdp-09 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-sdp-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-sdp-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 2 21:51:13 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AD8126C19 for ; Fri, 2 Mar 2018 21:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZM7QwSy1X2Jq for ; Fri, 2 Mar 2018 21:51:09 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 A545B124D37 for ; Fri, 2 Mar 2018 21:51:09 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id y127so6991827vky.9 for ; Fri, 02 Mar 2018 21:51:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ciKaf6mTV/PDCIAk1B/JX3octmRSi+08VzVmRKwSLLg=; b=SevdZ04pi6HkRJ7ozJfZURFypl7S2luW9/QYABad7WyGHpxNlzcVv4bLuDY3gkHmQr hsBeV3ZAC9tExmc02G09Les68MKdsNI7iTDwgjDZG7FwoCSFNZ7ddCLh1U28+h1cHPH5 T/ASpzTM8BizRBxWZ/o1JFIyJkZTCyvd71/P72CVA2EInMOIQDCZQV8MqM3jgxBNW9JD t3m+BvSkO8v0DjsgAbS44HK2kD+P6mXWPDorXvETtWvebahSx1naXErV5F0yP5h3hnfd u1yJZ+pHyjMIUukkfi7aedIoQrlr5L/mV7q9/8xPawZoyF2T4dN/gss039aS+giMTGhv NjNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ciKaf6mTV/PDCIAk1B/JX3octmRSi+08VzVmRKwSLLg=; b=PlEoX/NlTaLay4w/QxeSowLdhOupXon0qUeFUTE+Hoya5KtSayb+RV1CvpCgxBlpKO bCsPpmbExEGAzZcpQa9oCe4PtromMcstQe2fk6lCO4UdeUSdpWI0JXTCFEWvD1xd+2XH 6JzfR0A8v3mCzNX9pNVZAz/Ay19gVXl/TXX9iGx48CP8AaIlRM+K6WUzQpNlZZduw7gZ O5WaqtUcYhTxCFPu5mgWB0f0ORer2lHC8vzjpVQpxa31ekRkZUPknqGq88R6pnvUQnOu yPhvrX/KG6u04r63UVnTHZtsoctDCaMYlXNQCYZQXvh71SoARFZ/KB8UlgN6penYCzCJ ReAg== X-Gm-Message-State: APf1xPBXEdVzVK1IAcIodDSXT8ZbGxE4QRHgSylqiizHSQ/d2jHgfdBb sA3yy7GDZ5LvQruLb7v/0YoFGWsO/D4aJDE1bQ4OR//B X-Google-Smtp-Source: AG47ELv+GmsFKMcEf1uNLzeQ0tsNzTJdhwIAgdqEc4ZRJZXLM6ByLPwUPFGaEeFsll6DxKr6pLYAkmPzShwWsT5hSXA= X-Received: by 10.31.79.70 with SMTP id d67mr5439442vkb.9.1520056267979; Fri, 02 Mar 2018 21:51:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.167.206 with HTTP; Fri, 2 Mar 2018 21:50:47 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Fri, 2 Mar 2018 21:50:47 -0800 Message-ID: To: Adam Roach Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="001a114e0076e515f405667bad3b" Archived-At: Subject: Re: [rtcweb] AD Review: draft-ietf-rtcweb-fec-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 05:51:11 -0000 --001a114e0076e515f405667bad3b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just published -08 which addresses all comments other than the one I previously noted. On Fri, Mar 2, 2018 at 8:52 AM, Justin Uberti wrote: > > > On Thu, Mar 1, 2018 at 3:40 PM, Adam Roach wrote: > >> I have completed my AD review of draft-ietf-rtcweb-fec-07, and found onl= y >> very minor editorial nits, which should be treated as normal last call >> comments. >> > > Thanks for the review, and agree with the comments, with one exception. > Should I publish a new version of the document with corrections, or wait > for the document to progress further? > >> >> Due to this document's close relationship with >> draft-ietf-payload-flexible-fec-scheme, I plan to wait until both >> documents are ready to progress before placing draft-ietf-rtcweb-fec int= o >> IETF Last Call. >> >> Thanks to everyone who contributed to this document over its lifetime. >> >> Nits follow. >> >> ------------------------------------------------------------ >> --------------- >> =C2=A72 >> >> Since this document uses "should" in non-normative sentences, please use >> the >> RFC 8174 boilerplate. >> >> ------------------------------------------------------------ >> --------------- >> =C2=A73.3 >> >> Some audio codecs, notably Opus [RFC6716] and AMR [RFC4867] support >> >> Insert comma before "support" >> >> ------------------------------------------------------------ >> --------------- >> =C2=A74.1 >> >> against individual losses, with minimal overhead. Note that as >> indicated above the built-in Opus FEC only provides single-frame >> >> Insert commas before and after the phrase "as indicated above" >> >> ------------------------------------------------------------ >> --------------- >> =C2=A77 >> >> Implementations MAY support additional FEC mechanisms if desired, >> e.g. [RFC5109]. >> >> - Change the comma after "desired" to a semicolon. > > > I think a comma is appropriate here; this is also consistent with how e.g= . > is used elsewhere in the document. > > >> - Insert a comma after "e.g." >> >> ------------------------------------------------------------ >> --------------- >> >> >> /a >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > --001a114e0076e515f405667bad3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just published -08 which addresses all comments other than= the one I previously noted.

On Fri, Mar 2, 2018 at 8:52 AM, Justin Uberti <juberti@g= oogle.com> wrote:


On Thu, Mar 1, 2018 at 3:40 PM, Adam Roach &= lt;adam@nostrum.com> wrote:
I have completed my = AD review of draft-ietf-rtcweb-fec-07, and found only very minor editorial = nits, which should be treated as normal last call comments.

Thanks for the review, and agree with the comme= nts, with one exception. Should I publish a new version of the document wit= h corrections, or wait for the document to progress further?=C2=A0

Due to this document's close relationship with draft-ietf-payload-flexi= ble-fec-scheme, I plan to wait until both documents are ready to progr= ess before placing draft-ietf-rtcweb-fec into IETF Last Call.

Thanks to everyone who contributed to this document over its lifetime.

Nits follow.

-----------------------------------------------------------------= ----------
=C2=A72

Since this document uses "should" in non-normative sentences, ple= ase use the
RFC 8174 boilerplate.

-----------------------------------------------------------------= ----------
=C2=A73.3

=C2=A0=C2=A0 Some audio codecs, notably Opus [RFC6716] and AMR [RFC4867] su= pport

Insert comma before "support"

-----------------------------------------------------------------= ----------
=C2=A74.1

=C2=A0=C2=A0 against individual losses, with minimal overhead.=C2=A0 Note t= hat as
=C2=A0=C2=A0 indicated above the built-in Opus FEC only provides single-fra= me

Insert commas before and after the phrase "as indicated above"
-----------------------------------------------------------------= ----------
=C2=A77

=C2=A0=C2=A0 Implementations MAY support additional FEC mechanisms if desir= ed,
=C2=A0=C2=A0 e.g.=C2=A0 [RFC5109].

- Change the comma after "desired" to a semicolon.=C2=A0

I think a comma is appropriate here; this is= also consistent with how e.g. is used elsewhere in the document.
=C2=A0
- Insert a comma after "e.g."

-----------------------------------------------------------------= ----------


/a

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb


--001a114e0076e515f405667bad3b-- From nobody Fri Mar 2 21:52:15 2018 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F857124D37; Fri, 2 Mar 2018 21:52:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152005632948.8290.17072481676522156492@ietfa.amsl.com> Date: Fri, 02 Mar 2018 21:52:09 -0800 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-08.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 05:52:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers WG of the IETF. Title : WebRTC Forward Error Correction Requirements Author : Justin Uberti Filename : draft-ietf-rtcweb-fec-08.txt Pages : 12 Date : 2018-03-02 Abstract: This document provides information and requirements for how Forward Error Correction (FEC) should be used by WebRTC implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-fec-08 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-fec-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-fec-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 2 21:54:01 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47A1127337 for ; Fri, 2 Mar 2018 21:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Tac7QAMhI1Yj for ; Fri, 2 Mar 2018 21:53:59 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 EA497126C19 for ; Fri, 2 Mar 2018 21:53:58 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id z130so7010729vkd.0 for ; Fri, 02 Mar 2018 21:53:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YujM/DDlltDoCfoImkEr1Mppb9fujNL8Qj79zIgGPU8=; b=maHEvtEEtevgt7S8BekfDH09smSn3AaPTHjWGGfYRQQVd7SSjelWmA0Gn3ZqWMeEXm P6QjGl+6tw/x4Dorvv4nE00q0gOjgW4CMRuwppJ/Gj0cUywJB/AuH97+ucelo+52LfTw /50vg/feC/6LVV3XyShfDpwqQw/zqGT5GG33EJ+F9qSiJ0FoOdOEzlM0ccpiuGl6udx9 9Q0/7u79UblDdmz9gmeO3tGYzZTC2iZJzniL+YrdE49be/Ssptyd5yfHRSYh8BtdKMKr bs7xeOF/h3MEuMGIYA/lLNkCEZmqd7JFQgcT3cv0dRnGAJV6mVTS7EFQkF8j2MVnuqMw 8Vvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YujM/DDlltDoCfoImkEr1Mppb9fujNL8Qj79zIgGPU8=; b=kKfMjwoxPUue8gNHmaZG/PDe6Z/U2tlnD+Se1WNyrCA3mFJpHvfJyM6GjnUXEysibA SG+1GrtX1cMuYx+6TjcgdxmujW6WoRPVn2OoQ6p+ldB4bIKVVbhrsUjDKM7eyqMCn2Ga NQV0IquTEFaS0795uZI+FQWoEaeTxO+KfGbKxVPRF38vLPmYo3nW+lqC7HXvuVtC0r2c bwr3tZjahKyy8JCYn03sSF7QPx9eORrBBYD3YHzxwVVWKX/52FOFvCZwsPIsDDV52OcU DLKbP2tvAAPNkIy9D1fkZBlJO3yI1Hf+Kkyv8XqQmmEHn5mBiD/0UK25/Uk+XXmry6C3 QpAg== X-Gm-Message-State: APf1xPCzaAdHDd9miWerJFBDG7+Wb0b9LzwZ4nuqpqsREN02cqpUWRW3 GzNxmSCkeS6pJqhrSo7INWfZl1eTwS/rOKswkn/phw== X-Google-Smtp-Source: AG47ELtVf6qAunzfheWt2iQxkEpEV7J+cibsw5F1qWC+WGEUUjEVonft5J8pSI6E2Ky2qFwm7L4SBTmjG7id3OS7Hkk= X-Received: by 10.31.227.1 with SMTP id a1mr5391681vkh.195.1520056437958; Fri, 02 Mar 2018 21:53:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.84.146 with HTTP; Fri, 2 Mar 2018 21:53:57 -0800 (PST) In-Reply-To: <152005597078.8302.11475653006623461008@ietfa.amsl.com> References: <152005597078.8302.11475653006623461008@ietfa.amsl.com> From: Suhas Nandakumar Date: Fri, 2 Mar 2018 21:53:57 -0800 Message-ID: To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary="001a114df62205ee6f05667bb81c" Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-sdp-09.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 05:54:00 -0000 --001a114df62205ee6f05667bb81c Content-Type: text/plain; charset="UTF-8" Hello All This version address most of the issues reported by Adam's syntax validation script except for the below 2: 1. a=identity attribute values are split across multiple lines Resolution: Presently splitting the identity value helps readability. Hence we left it as-is but added the following note "identity attribute values are split across multiple lines to enhance readability, thus any line breaks and indentations in the value must be ignored." 2. Use of RTP/AVP in couple of examples Resolution: There are 2 examples that uses RTP/AVP as the proto to showcase legacy interop examples.Hence we decide to ignore the proto error reported by the script This version also address another issue opened by Christer on aligning with the latest Bundle of using port 0 and bundle-only for non bundle-tag multiplexed media descriptions. Please let us know if you have any questions. Many Thanks to Adam/Nils for helping with syntax validation. Cheers Suhas On Fri, Mar 2, 2018 at 9:46 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Real-Time Communication in WEB-browsers > WG of the IETF. > > Title : Annotated Example SDP for WebRTC > Authors : Suhas Nandakumar > Cullen Jennings > Filename : draft-ietf-rtcweb-sdp-09.txt > Pages : 119 > Date : 2018-03-02 > > Abstract: > The Real-Time Communications in WEB-browsers (Rtcweb) working group > is charged to provide protocol support for direct interactive rich > communication using audio, video and data between two peers' web > browsers. With in the Rtcweb framework, Session Description protocol > (SDP) is used for negotiating session capabilities between the peers. > Such a negotiation happens based on the SDP Offer/Answer exchange > mechanism. > > This document provides an informational reference in describing the > role of SDP and the Offer/Answer exchange mechanism for the most > common Rtcweb use-cases. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sdp/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-sdp-09 > https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-sdp-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-sdp-09 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a114df62205ee6f05667bb81c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello All

=C2=A0 This version address m= ost of the issues reported by Adam's syntax validation script except fo= r the below 2:
=C2=A0=C2=A0
=C2=A0 =C2=A0 1. a=3Didenti= ty attribute values are split across multiple lines
=C2=A0 =C2=A0= =C2=A0
=C2=A0Resolution: Presently splitting the identity value h= elps readability. Hence we left it as-is but added the following note
=
=C2=A0 =C2=A0=C2=A0
"identity = attribute values are split across multiple lines to enhance readability, th= us any line breaks and indentations in the value must be ignored."

=C2=A0
=C2=A0 =C2=A02. Use of RTP/AVP in couple of examples

=C2=A0 =C2=A0 =C2=A0 Resolution: There are 2 examples that uses RT= P/AVP as the proto to showcase legacy interop examples.Hence we decide to i= gnore the proto error reported by the script


<= /div>
This version also address another issue opened by Christer on ali= gning with the latest Bundle of using port 0 and bundle-only for non bundle= -tag multiplexed media descriptions.


Please let us know if you have any questions.

Ma= ny Thanks to Adam/Nils for helping with syntax validation.

Cheers
Suhas

<= div class=3D"gmail_quote">On Fri, Mar 2, 2018 at 9:46 PM, <interne= t-drafts@ietf.org> wrote:
<= br> A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Real-Time Communication in WEB-browsers WG= of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Annotated Example SDP for WebRTC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Suha= s Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Cullen Jennings
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-sdp-09.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 119
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-03-02

Abstract:
=C2=A0 =C2=A0The Real-Time Communications in WEB-browsers (Rtcweb) working = group
=C2=A0 =C2=A0is charged to provide protocol support for direct interactive = rich
=C2=A0 =C2=A0communication using audio, video and data between two peers= 9; web
=C2=A0 =C2=A0browsers.=C2=A0 With in the Rtcweb framework, Session Descript= ion protocol
=C2=A0 =C2=A0(SDP) is used for negotiating session capabilities between the= peers.
=C2=A0 =C2=A0Such a negotiation happens based on the SDP Offer/Answer excha= nge
=C2=A0 =C2=A0mechanism.

=C2=A0 =C2=A0This document provides an informational reference in describin= g the
=C2=A0 =C2=A0role of SDP and the Offer/Answer exchange mechanism for the mo= st
=C2=A0 =C2=A0common Rtcweb use-cases.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-i= etf-rtcweb-sdp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-rtcw= eb-sdp-09
https://datatracker.ietf.org/doc/= html/draft-ietf-rtcweb-sdp-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-rtcweb-sdp-09


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--001a114df62205ee6f05667bb81c-- From nobody Mon Mar 5 11:43:31 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0F312D93E for ; Mon, 5 Mar 2018 11:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 zylw79I8f5bi for ; Mon, 5 Mar 2018 11:43:23 -0800 (PST) Received: from smtp81.iad3a.emailsrvr.com (smtp81.iad3a.emailsrvr.com [173.203.187.81]) (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 B63DA12D874 for ; Mon, 5 Mar 2018 11:43:23 -0800 (PST) Received: from smtp3.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp3.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0259321046; Mon, 5 Mar 2018 14:43:23 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp3.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id B06B224BB8; Mon, 5 Mar 2018 14:43:22 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Mon, 05 Mar 2018 14:43:22 -0500 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 5 Mar 2018 12:43:22 -0700 Message-Id: <3B663EB9-52D3-4069-A31C-03D6D0BB38BB@iii.ca> To: RTCWeb IETF X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [rtcweb] Getting rid of SDP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 19:43:27 -0000 SDP is pretty awful. What we need to do to greatly simplify things is = get rid of SDP. The offer answer is really complicated for modern = systems that have more uniform capabilities so I would like to get rid = of offer answer too. To simplify all the control, I think one needs to = also simplify STUN, TURN, ICE, RTP, and SRTP.=20 I wrote a draft outlining that - it is at: https://datatracker.ietf.org/doc/draft-jennings-dispatch-new-media/ it is being discussed on the dispatch@ietf.org email list ( you can join = at https://www.ietf.org/mailman/listinfo/dispatch). Glad to get PR at = https://github.com/WhatIETF/draft-jennings-dispatch-new-media Love to get feedback in general and also on how this, or parts of it, = would be a good way to go for the next version of WebRTC Thanks, Cullen From nobody Mon Mar 5 12:56:06 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A6E12D77D for ; Mon, 5 Mar 2018 12:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 RzUVjMPFXNOP for ; Mon, 5 Mar 2018 12:56:03 -0800 (PST) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 818F012E8A5 for ; Mon, 5 Mar 2018 12:55:58 -0800 (PST) Received: by mail-wr0-x22f.google.com with SMTP id u49so18716886wrc.10 for ; Mon, 05 Mar 2018 12:55:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=UgLsypy4+sFkDuOeAwNVZf4PiV2eYqMaRV9pIxnalTM=; b=Do3ebVv4rqHZkYefka7E6pK/CYXJC989BocSP0eD4z8t0rrogoiYCZcbXAzfy4MgtK +0KN8iWI0DvAtIBCwLcTqx51IG2xe+s9N1IgPEOlKVNIOvcHn71zEwMYiQNVhRAb1+cT /5UGf0kpvInRkvKC6qcQLZFegQsMqXKLiM/DKtNuPSO+MAg5hthp2xVxuELDeSeUJQbB FoggZOY4+P81nA9hMEZ7V0wDU16m9HOTqCzb5go63LSBNfPcc8u+98vIs+aNjfXR+OZZ NuMsL6Ov0qH+uMObExI2hIV2CGNXFsgYQOOwOCedpXejmAvMjBhq4za9u19xKXuzGocW NCLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=UgLsypy4+sFkDuOeAwNVZf4PiV2eYqMaRV9pIxnalTM=; b=FcOOajgYhlyAX5qbPRA8awaiIzl2xa5e2+n1vA3uN59bZ2VkjfwFZvhLuOrQR96SVk bZbthkUvpzm6o8c5W1W0o1WlnaeFnXQUlM6zhtF0Hw1ymK2UcJeKcNUDtc/bi/j+UMOd qU4fDtlBz5VrlzMGazbXR/sMZjPddkD9JqHqZtWGMOxG4n5a4aMjgiiyo3sGjayeDcts dEoMK8KTjvi/Rw7dybA7mPF9zDz0/8/1tVEU16oRqAjO1ysr5sTUFLxAy40se/dILPFB unZUfNDPrOlowIKnzxFH8qfvFOOdsLphf7WhEnAx7Fjlq8CyUdoputb2Uolsfz4qyqT8 SfLQ== X-Gm-Message-State: APf1xPA0MfOMifogpsPKst5Jvp1zG0TF0X4jP3BbqOAK5n9CLPJj+pWJ AnLAvdvNFnWsE0/1F62jpldIbNEJ X-Google-Smtp-Source: AG47ELsA+4GCIdAeyr2Org11P04zLwgGtQ6mYENNaG7aBgGt9Iw027h5z0tcxxhtjX62upS/GR3dMw== X-Received: by 10.223.134.42 with SMTP id 39mr14613687wrv.10.1520283356885; Mon, 05 Mar 2018 12:55:56 -0800 (PST) Received: from [192.168.0.11] (213.37.16.193.dyn.user.ono.com. [213.37.16.193]) by smtp.googlemail.com with ESMTPSA id x17sm15111644wrg.32.2018.03.05.12.55.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Mar 2018 12:55:55 -0800 (PST) To: rtcweb@ietf.org References: <3B663EB9-52D3-4069-A31C-03D6D0BB38BB@iii.ca> From: Sergio Garcia Murillo Message-ID: <89e7a7b4-ac61-f7ed-7699-1f33cf8ceff1@gmail.com> Date: Mon, 5 Mar 2018 21:56:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <3B663EB9-52D3-4069-A31C-03D6D0BB38BB@iii.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Getting rid of SDP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 20:56:05 -0000 Hi Cullen, The proposal goes far beyond of getting rid of SDP, but replacing DTLS/SRTP with QUICK, modifying ICE and changing all the media stack all together. Without entering to discuss the technical merits of it, I find it very difficult to shallow that replacing the current w3c api to remove the SDP requires such a huge impact on webrtc. IMHO, the two discussions should be independent, and I am much more worried to remove SDP than replacing my whole media stack. Also, as already stated on the w3c list, a enough low level api would allow to cover both media over dtls/ice/srtp as usual  and media over quic. Best regards Sergio On 05/03/2018 20:43, Cullen Jennings wrote: > SDP is pretty awful. What we need to do to greatly simplify things is get rid of SDP. The offer answer is really complicated for modern systems that have more uniform capabilities so I would like to get rid of offer answer too. To simplify all the control, I think one needs to also simplify STUN, TURN, ICE, RTP, and SRTP. > > I wrote a draft outlining that - it is at: > > https://datatracker.ietf.org/doc/draft-jennings-dispatch-new-media/ > > it is being discussed on the dispatch@ietf.org email list ( you can join at https://www.ietf.org/mailman/listinfo/dispatch). Glad to get PR at https://github.com/WhatIETF/draft-jennings-dispatch-new-media > > Love to get feedback in general and also on how this, or parts of it, would be a good way to go for the next version of WebRTC > > Thanks, Cullen > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Mar 5 14:58:04 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879C712711E for ; Mon, 5 Mar 2018 14:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.529 X-Spam-Level: X-Spam-Status: No, score=-14.529 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 SCfJzL5Av8gB for ; Mon, 5 Mar 2018 14:57:58 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF093127AD4 for ; Mon, 5 Mar 2018 14:57:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5458; q=dns/txt; s=iport; t=1520290675; x=1521500275; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8tJGEjZHWKhxwxoGhwNPI8jkLKRbMuzrevPkVImTtSA=; b=c9TmqNh8S0Zzc8rvuZuzTLBww5ykfFWIJA4IolGpn9m9VYCypz7Mbdjv od6EgpALN9BenB+Rahz91ZupKH0WpG9vmxcSJ7uve36ax1OngGc2+YYex duGi1BEDwymbqv+6Lg9EdSr27dRNMdpmeyeE83KmbTwVRPjHIA5HPZVW1 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAgCKyp1a/5ldJa1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJadoFWKAqbZoFbgT2PEYUjghUKhTACgnMhNRcBAgEBAQE?= =?us-ascii?q?BAQJrJ4UkBnkQAgEIDjEHMhQRAgQOBYQ3ZKsdhHKDc4ImhS2CLoM9KQyCeIh?= =?us-ascii?q?cgjIEmmIJAolkhxmOeJEoAhEZAYEtASACNIFScBVkAYIYgjEcgXt3i1eBGAE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.47,429,1515456000"; d="scan'208,217";a="356975337" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2018 22:57:54 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w25MvsZX012878 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Mar 2018 22:57:54 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 5 Mar 2018 17:57:54 -0500 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1320.000; Mon, 5 Mar 2018 17:57:54 -0500 From: "Cullen Jennings (fluffy)" To: Taylor Brandstetter CC: RTCWeb IETF Thread-Topic: [rtcweb] Processing multiple remote offers Thread-Index: AQHTtNVkA2VXHZkJskqMzQQ965tteQ== Date: Mon, 5 Mar 2018 22:57:53 +0000 Message-ID: <6043E62B-AA66-4031-8D06-D2DE6C2CA3A3@cisco.com> References: <624deabb-0fa2-4ae2-4661-f71b3ee322ae@alvestrand.no> In-Reply-To: <624deabb-0fa2-4ae2-4661-f71b3ee322ae@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.228.210] Content-Type: multipart/alternative; boundary="_000_6043E62BAA6640318D06D2DE6C2CA3A3ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] Processing multiple remote offers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 22:58:00 -0000 --_000_6043E62BAA6640318D06D2DE6C2CA3A3ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 17, 2017, at 8:50 AM, Harald Alvestrand > wrote: Den 17. okt. 2017 01:12, skrev Taylor Brandstetter: JSEP allows a remote offer to be applied while in the "have-remote-offer" state. Meaning that, in addition to supporting multiple answers (via pr-answers), JSEP also supports multiple offers. However, I don't see any text that calls out what (if anything) must be the same between these offers. Should we assume that they can be /completely/ different? Or do they at least need to contain the same m=3D sections (same type, MID and order)? For example: is it legal to apply an audio-only remote offer, then apply a video-only remote offer? Is it legal to apply an audio-only offer, then an audio+video offer? They can be totally different but only the last one applies will have any i= mpact on the media stack. So say browser A sends and offer with audio and video to endpoint B and C a= nd they both return totally different pr-answers. B only accepts audio and = C only does video. If the JS at A apples the one B, the browser sends audio to B. If the JS th= en applies the one from C, the browse with stop whatever it was doing to B = and start sending video to C. At that point the JS could decide to go back = to the one from B and the browser could go back to sending audio to B. Even= tually if final offer came from B and the JS at A applied it, the browser c= ould fee up the video codec because at this point it knows it will not be n= eeded. --_000_6043E62BAA6640318D06D2DE6C2CA3A3ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

On Oct 17, 2017, at 8:50 AM, Harald Alvestrand <harald@alvestrand.no> wr= ote:

Den 17. okt. 2017 01:12, skrev Taylor Brandstetter:
JSEP allows a remote offer to be applied while in the
"have-remote-offer" state. Meaning that, in addition to supportin= g
multiple answers (via pr-answers), JSEP also supports multiple offers.

However, I don't see any text that calls out what (if anything) must be
the same between these offers. Should we assume that they can be
/completely/ different? Or do they at least need to contain the same m= =3D
sections (same type, MID and order)? For example: is it legal to apply
an audio-only remote offer, then apply a video-only remote offer? Is it
legal to apply an audio-only offer, then an audio+video offer?

They can be totally different but only the last one applies= will have any impact on the media stack. 

So say browser A sends and offer with audio and video to en= dpoint B and C and they both return totally different pr-answers. B only ac= cepts audio and C only does video. 

If the JS at A apples the one B, the browser sends audio to= B. If the JS then applies the one from C, the browse with stop whatever it= was doing to B and start sending video to C. At that point the JS could de= cide to go back to the one from B and the browser could go back to sending audio to B. Eventually if final o= ffer came from B and the JS at A applied it, the browser could fee up the v= ideo codec because at this point it knows it will not be needed. 


--_000_6043E62BAA6640318D06D2DE6C2CA3A3ciscocom_-- From nobody Mon Mar 5 22:39:47 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31266126C2F for ; Mon, 5 Mar 2018 22:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 UqJMTqXq0ouj for ; Mon, 5 Mar 2018 22:39:43 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DC4D124B0A for ; Mon, 5 Mar 2018 22:39:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id D924E7C373F for ; Tue, 6 Mar 2018 07:39:41 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAsZzOzkizJQ for ; Tue, 6 Mar 2018 07:39:40 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:12:88ab:4fa2:7af4:100d]) by mork.alvestrand.no (Postfix) with ESMTPSA id 3EC997C0CC4 for ; Tue, 6 Mar 2018 07:39:40 +0100 (CET) To: rtcweb@ietf.org References: <3B663EB9-52D3-4069-A31C-03D6D0BB38BB@iii.ca> From: Harald Alvestrand Message-ID: <4de127a2-2936-0022-34af-614129ea105f@alvestrand.no> Date: Tue, 6 Mar 2018 07:39:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <3B663EB9-52D3-4069-A31C-03D6D0BB38BB@iii.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Getting rid of SDP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 06:39:46 -0000 Nice to see that you too are arguing that we should get rid of SDP's design errors! There are of course design errors (I think) in the proposal you made too (the most glaring one is that you tie sources to clients - in order to be generic building tools, sources need global IDs - otherwise we can't build distribution trees for Baumgartner's parachute jump from space using the same technology as chatting with Grandma). 128-bit random numbers are lovely global identifiers. (This is the same error that went into the original design of the http URL - tying location with identity. But I digress.) I'd also like to have a security story that hangs together - each layer has unique security properties that it needs to make sure are satisfiable - from the neeed to not make DDOS simple at the network layer to the assurance that I'm talking to Grandma and not some CGI-generated scammer-face at the application layer. We've so far failed to have a security story in WebRTC that is both comprehensive and attractive to deploy - I'd like to see us do better next time around. I'm a little bit hesitant to ask this, but .... should we go back and look at what use cases we plan to solve in this Grand Unified Scheme of Things? Harald On 03/05/2018 08:43 PM, Cullen Jennings wrote: > SDP is pretty awful. What we need to do to greatly simplify things is get rid of SDP. The offer answer is really complicated for modern systems that have more uniform capabilities so I would like to get rid of offer answer too. To simplify all the control, I think one needs to also simplify STUN, TURN, ICE, RTP, and SRTP. > > I wrote a draft outlining that - it is at: > > https://datatracker.ietf.org/doc/draft-jennings-dispatch-new-media/ > > it is being discussed on the dispatch@ietf.org email list ( you can join at https://www.ietf.org/mailman/listinfo/dispatch). Glad to get PR at https://github.com/WhatIETF/draft-jennings-dispatch-new-media > > Love to get feedback in general and also on how this, or parts of it, would be a good way to go for the next version of WebRTC > > Thanks, Cullen > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Mar 5 23:02:18 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED39A126CD6 for ; Mon, 5 Mar 2018 23:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 iusDkc-kGqYq for ; Mon, 5 Mar 2018 23:02:12 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 07D0C126CC4 for ; Mon, 5 Mar 2018 23:02:12 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id z197so23744508qkb.6 for ; Mon, 05 Mar 2018 23:02:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=B3lR8qjQi10N0vnvnvgyVW7pGjJOFVpV+ZdQPJe+cH4=; b=dLRDtjtpGDbF75QPQofpe6rLj2XYVYbeFCJsWDtgddXpIbEARLjxMhAmGc3Ud24/t9 6BA7zb1P/2bQBu+pvW7BqfopAPCZd26c8Jbd/XozTVFDKQumszGksS/BmTnpfmk7iQC9 fwBEJF6QBIGXqN4fhMmWGF7Dsx6OJSo7uYo/ikoukdqv/AM8opN7wuktutPRlXoM72YW LsNbOldDkzW1KpzDY0iPyFqrEMA2Ji7fhfqHPHTNAesExi4+m+tSJtNVt4CpbfEbjK8+ r5O4eJZb4VKq4ntWvTScBCISVNm2QIG2AFAIngNnB3oGh+0XezuuTAHC19visD2YGVN9 yvGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=B3lR8qjQi10N0vnvnvgyVW7pGjJOFVpV+ZdQPJe+cH4=; b=dd0+OEETOn5FjxwMzpGxHszXdlYymP9FQsWaqu/b+tfkt7g/0WdZp0lcmTko0Hq/i0 CWXOj+/wh/4KQnN0T5F8wKv1KSFI9ZO58BmvOtTKeXAEj1M0kvfi2Fs68WyKuN+2G3Ml BuYn3VFPsr/T7slKvpEzoyuM3H0MEd19xEkFmL/k+ZtCTvyoyqE10dOb94vNDzHtMAcz /jj2vRYTb0CFfyUwc9riQORktW3MiKnlGF+N7ceBwj4je7YdP3k+qDlelcJTbBfO78MU 0DKKXAl94fW88jraskZjS2admPagbVV8aKlnRvhoBBVQYi2rf3nSJyAYCZu9TKrhTB9I TCFw== X-Gm-Message-State: AElRT7GWQcFd+uz6vzW+6y2nsIqU7YydPMuStjxh2jsG99E7OUPG79yP i1DiI/xcny6s1rE4GxavLlpB7z+jCxQgt1qy/GDUiw== X-Google-Smtp-Source: AG47ELsxVsNcGJMlPy+1UAYORopEEmMrdMuaM1GNDEImgc6S7lIwo6JzkOOyrE+jpZ+w7r+Fo3lZiVFI5WkFm3dNX2k= X-Received: by 10.55.43.68 with SMTP id r65mr26274424qkh.117.1520319731088; Mon, 05 Mar 2018 23:02:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.32.129 with HTTP; Mon, 5 Mar 2018 23:01:50 -0800 (PST) In-Reply-To: <4de127a2-2936-0022-34af-614129ea105f@alvestrand.no> References: <3B663EB9-52D3-4069-A31C-03D6D0BB38BB@iii.ca> <4de127a2-2936-0022-34af-614129ea105f@alvestrand.no> From: Silvia Pfeiffer Date: Tue, 6 Mar 2018 18:01:50 +1100 Message-ID: To: Harald Alvestrand Cc: rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Getting rid of SDP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 07:02:17 -0000 Yes, please, let's make a list of the use cases and the problems. Otherwise it feels like we're re-inventing technology for technology's sake. Kind Regards, Silvia. On Tue, Mar 6, 2018 at 5:39 PM, Harald Alvestrand wr= ote: > Nice to see that you too are arguing that we should get rid of SDP's > design errors! > > There are of course design errors (I think) in the proposal you made too > (the most glaring one is that you tie sources to clients - in order to > be generic building tools, sources need global IDs - otherwise we can't > build distribution trees for Baumgartner's parachute jump from space > using the same technology as chatting with Grandma). 128-bit random > numbers are lovely global identifiers. (This is the same error that went > into the original design of the http URL - tying location with identity. > But I digress.) > > I'd also like to have a security story that hangs together - each layer > has unique security properties that it needs to make sure are > satisfiable - from the neeed to not make DDOS simple at the network > layer to the assurance that I'm talking to Grandma and not some > CGI-generated scammer-face at the application layer. We've so far failed > to have a security story in WebRTC that is both comprehensive and > attractive to deploy - I'd like to see us do better next time around. > > I'm a little bit hesitant to ask this, but .... should we go back and > look at what use cases we plan to solve in this Grand Unified Scheme of > Things? > > Harald > > On 03/05/2018 08:43 PM, Cullen Jennings wrote: >> SDP is pretty awful. What we need to do to greatly simplify things is ge= t rid of SDP. The offer answer is really complicated for modern systems tha= t have more uniform capabilities so I would like to get rid of offer answer= too. To simplify all the control, I think one needs to also simplify STUN,= TURN, ICE, RTP, and SRTP. >> >> I wrote a draft outlining that - it is at: >> >> https://datatracker.ietf.org/doc/draft-jennings-dispatch-new-media/ >> >> it is being discussed on the dispatch@ietf.org email list ( you can join= at https://www.ietf.org/mailman/listinfo/dispatch). Glad to get PR at http= s://github.com/WhatIETF/draft-jennings-dispatch-new-media >> >> Love to get feedback in general and also on how this, or parts of it, wo= uld be a good way to go for the next version of WebRTC >> >> Thanks, Cullen >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Mar 6 06:11:23 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4201270AE for ; Tue, 6 Mar 2018 06:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ave7PT4mqfqy for ; Tue, 6 Mar 2018 06:11:21 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 203351270A3 for ; Tue, 6 Mar 2018 06:11:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520345479; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=YXvGExjHPKA4Qm4p1EYYnsKf86ZgfUD0zoGzMThPEvQ=; b=VG6FTJm8qawxKdUN+CT5vsnULP9s32vQT8PsopJUi4WeEWUyzW5x2atRw5/MjbRU XsM5c5p16AMMRZd17W+5oWCS3qd/1uO2Sy844NLNlEavLQ4lJkcYPk3ZtIte1HSL BvTEWVB89AxNIUbw8kRN3URj7X+0nNmZixndo6pNlb0=; X-AuditID: c1b4fb25-44ba69c000002d5f-01-5a9ea1869e25 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 9A.D7.11615.681AE9A5; Tue, 6 Mar 2018 15:11:19 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0352.000; Tue, 6 Mar 2018 15:11:00 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: JSEP: remote-candidate attribute Thread-Index: AQHTtVT0UI2iHXS3bku9TxYBJoLZ3w== Date: Tue, 6 Mar 2018 14:11:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_D6C471262C2EEchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM2J7uG77wnlRBvufclms/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJtbmpgLZvJUfDt0k62BcQNXFyMnh4SAicSTiw9Zuxi5OIQE DjNKPGnZxAzhLGKUuHp3L3sXIwcHm4CFRPc/bZAGEQF1icsPL7CD2MICmhJztjayQcT1JBZ3 tjHB2Os/t4PFWQRUJP5u/wgW5xWwlrjR+YYRxGYUEJP4fmoNWJxZQFzi1pP5TBAHCUgs2XOe GcIWlXj5+B8riC0KNHPDidvsEHFFifanDYwQvQkS565NY4OYLyhxcuYTlgmMQrOQjJ2FpGwW kjKIuIHE+3PzmSFsbYllC19D2foSG7+cZYSwrSW273nFiKxmASPHKkbR4tTipNx0I2O91KLM 5OLi/Dy9vNSSTYzAWDm45bfqDsbLbxwPMQpwMCrx8GZOnBclxJpYVlyZe4hRgoNZSYQ3Qh8o xJuSWFmVWpQfX1Sak1p8iFGag0VJnHeOcHuUkEB6YklqdmpqQWoRTJaJg1OqgbFhyeEfK/8c W29/pHGzycJ2t50/pOV+xB3b96V3lkPtkVWrZ36Y+HBC2Ruz1evWrzl6eNbT6R+jKvrNmZh2 OkXeks54t+OnO58Oc4lQ+LqMdKuuOMHI+k3dCRXFLNmip9a6RQs6TggPvtTg1MMUJP5brU6u 6DFj+vxJM9LadQ+Efvz4jYfz8EUlluKMREMt5qLiRAAW7lVvkQIAAA== Archived-At: Subject: [rtcweb] JSEP: remote-candidate attribute X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 14:11:22 -0000 --_000_D6C471262C2EEchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, The following has probably been discussed at some point, but I could not fi= nd it in the mail archive, and it is not described in JSEP. My understanding is that JSEP does not use the remote-candidate attribute (= it must parse it if received, but it doesn=92t process it). What was the reason for that? Regards, Christer --_000_D6C471262C2EEchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

The following has probably been discussed at some point, but I could n= ot find it in the mail archive, and it is not described in JSEP.

My understanding is that JSEP does not use the remote-candidate attrib= ute (it must parse it if received, but it doesn=92t process it).

What was the reason for that?

Regards,

Christer
--_000_D6C471262C2EEchristerholmbergericssoncom_-- From nobody Tue Mar 6 10:30:39 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9DB12D779 for ; Tue, 6 Mar 2018 10:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zn3Ji7jFikiN for ; Tue, 6 Mar 2018 10:30:35 -0800 (PST) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (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 BDD3F12D0C3 for ; Tue, 6 Mar 2018 10:30:31 -0800 (PST) Received: by mail-wr0-x22b.google.com with SMTP id l43so21977393wrc.2 for ; Tue, 06 Mar 2018 10:30:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lubixYW8zl8jjqJsrYbnzhAInDTWo1U1lCUXOemXDTs=; b=vuQUGpEvL/TkiwmBCk11J94zjvcJzupBq2qZMGW2deLPgYY5RL+QfrfChdwOIs3dCX FC7/SdWUBL2xWsBqSM91hSfLkPDS4rK9NHO456dJ6gZLXHgHKwBt8m5JPtyGZKiC6nzJ BxM31ntyWa9KeXN3WlmhzEaVACc2pKJ13E/oNKppUB5gXL9u5jMQxddqt3FWOp9BwtMG g8ppG69LVzxVNkFLya+msfUtS4TYhBfPYLDUhl1hQU8/UqKxBiiviWKRKgEJVOfuQ0I3 VfjugQGtZ6ojwkQwNK0xe7FriSnCUdVp2LxrAKXJLHv2AJ0ubSaL5hUZMOEARIP6rZVb xmCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lubixYW8zl8jjqJsrYbnzhAInDTWo1U1lCUXOemXDTs=; b=SOZT6r+cEK9JXXM6HmHH5+smHIyeBAacBnpyW/xi6QWZPgDGTaGfp5USIMRs6nU2FO G+FzBJnyWltbHHyYZZVTd84R60eX3G525/YyOAzfs6ptzrqnVDTr5VIt70aXvD9gXDlu YrZf+mArPEp8iVDJMg/7vubXCRAvIx8qFQcw/FPnBBd6Y23JZWl0MRClHXPCmHp071Lt 8te4E8SF0nv81SFpb8Z/Q5jJwfuKa6UukgNd777pr14OJD2oS2bVIexgoYwGVpUSjckK ovmIP0eoCnjN+PAOmQ+6ui4Z6aRzFjpcc4FhqUaaz+W3K5WIDY7R0QONTMCRWXlhjgh8 TgBQ== X-Gm-Message-State: APf1xPDDRxPkd1Zv9CCj1UL/GVLiNEbteX/n+dOg1Q3pqPbKDnA2jEwo hsWtjthpOqDkfp74kmITjyY7DdXedYZ1+f7SOjB+ZXFU X-Google-Smtp-Source: AG47ELtKPYY1r/kSYXH+SnCKkKseL5JWdRfgBZe7PSZxx+g2zpuaxUjO6kua3jIxo3UiVsFuBy+U/Rsk2zEIwoeKBQg= X-Received: by 10.223.199.137 with SMTP id l9mr18016960wrg.6.1520361029987; Tue, 06 Mar 2018 10:30:29 -0800 (PST) MIME-Version: 1.0 References: <3B663EB9-52D3-4069-A31C-03D6D0BB38BB@iii.ca> <4de127a2-2936-0022-34af-614129ea105f@alvestrand.no> In-Reply-To: From: Peter Thatcher Date: Tue, 06 Mar 2018 18:30:19 +0000 Message-ID: To: Silvia Pfeiffer Cc: Harald Alvestrand , rtcweb@ietf.org Content-Type: multipart/alternative; boundary="089e08244044204aff0566c2a3dc" Archived-At: Subject: Re: [rtcweb] Getting rid of SDP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 18:30:37 -0000 --089e08244044204aff0566c2a3dc Content-Type: text/plain; charset="UTF-8" I just recently sent an email to the list summarizing a previous list thread asking people to share use cases that people were looking at. So, in a sense I think we've already gone through the exercise of seeking use cases, getting them, and summarizing them. The conclusion I came to was that a set of orthogonal low-level APIs would meet the use cases people had expressed. On Mon, Mar 5, 2018 at 11:02 PM Silvia Pfeiffer wrote: > Yes, please, let's make a list of the use cases and the problems. > Otherwise it feels like we're re-inventing technology for technology's > sake. > > Kind Regards, > Silvia. > > On Tue, Mar 6, 2018 at 5:39 PM, Harald Alvestrand > wrote: > > Nice to see that you too are arguing that we should get rid of SDP's > > design errors! > > > > There are of course design errors (I think) in the proposal you made too > > (the most glaring one is that you tie sources to clients - in order to > > be generic building tools, sources need global IDs - otherwise we can't > > build distribution trees for Baumgartner's parachute jump from space > > using the same technology as chatting with Grandma). 128-bit random > > numbers are lovely global identifiers. (This is the same error that went > > into the original design of the http URL - tying location with identity. > > But I digress.) > > > > I'd also like to have a security story that hangs together - each layer > > has unique security properties that it needs to make sure are > > satisfiable - from the neeed to not make DDOS simple at the network > > layer to the assurance that I'm talking to Grandma and not some > > CGI-generated scammer-face at the application layer. We've so far failed > > to have a security story in WebRTC that is both comprehensive and > > attractive to deploy - I'd like to see us do better next time around. > > > > I'm a little bit hesitant to ask this, but .... should we go back and > > look at what use cases we plan to solve in this Grand Unified Scheme of > > Things? > > > > Harald > > > > On 03/05/2018 08:43 PM, Cullen Jennings wrote: > >> SDP is pretty awful. What we need to do to greatly simplify things is > get rid of SDP. The offer answer is really complicated for modern systems > that have more uniform capabilities so I would like to get rid of offer > answer too. To simplify all the control, I think one needs to also simplify > STUN, TURN, ICE, RTP, and SRTP. > >> > >> I wrote a draft outlining that - it is at: > >> > >> https://datatracker.ietf.org/doc/draft-jennings-dispatch-new-media/ > >> > >> it is being discussed on the dispatch@ietf.org email list ( you can > join at https://www.ietf.org/mailman/listinfo/dispatch). Glad to get PR > at https://github.com/WhatIETF/draft-jennings-dispatch-new-media > >> > >> Love to get feedback in general and also on how this, or parts of it, > would be a good way to go for the next version of WebRTC > >> > >> Thanks, Cullen > >> > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e08244044204aff0566c2a3dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I just recently sent an email to the list summarizing a pr= evious list thread asking people to share use cases that people were lookin= g at.=C2=A0 So, in a sense I think we've already gone through the exerc= ise of seeking use cases, getting them, and summarizing them.=C2=A0 The con= clusion I came to was that a set of orthogonal low-level APIs would meet th= e use cases people had expressed.

On Mon, Mar 5, 2018 at 11:02 PM Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:<= br>
Yes, please, let's make a list = of the use cases and the problems.
Otherwise it feels like we're re-inventing technology for technology= 9;s
sake.

Kind Regards,
Silvia.

On Tue, Mar 6, 2018 at 5:39 PM, Harald Alvestrand <harald@alvestrand.no> wrote: > Nice to see that you too are arguing that we should get rid of SDP'= ;s
> design errors!
>
> There are of course design errors (I think) in the proposal you made t= oo
> (the most glaring one is that you tie sources to clients - in order to=
> be generic building tools, sources need global IDs - otherwise we can&= #39;t
> build distribution trees for Baumgartner's parachute jump from spa= ce
> using the same technology as chatting with Grandma). 128-bit random > numbers are lovely global identifiers. (This is the same error that we= nt
> into the original design of the http URL - tying location with identit= y.
> But I digress.)
>
> I'd also like to have a security story that hangs together - each = layer
> has unique security properties that it needs to make sure are
> satisfiable - from the neeed to not make DDOS simple at the network > layer to the assurance that I'm talking to Grandma and not some > CGI-generated scammer-face at the application layer. We've so far = failed
> to have a security story in WebRTC that is both comprehensive and
> attractive to deploy - I'd like to see us do better next time arou= nd.
>
> I'm a little bit hesitant to ask this, but .... should we go back = and
> look at what use cases we plan to solve in this Grand Unified Scheme o= f
> Things?
>
> Harald
>
> On 03/05/2018 08:43 PM, Cullen Jennings wrote:
>> SDP is pretty awful. What we need to do to greatly simplify things= is get rid of SDP. The offer answer is really complicated for modern syste= ms that have more uniform capabilities so I would like to get rid of offer = answer too. To simplify all the control, I think one needs to also simplify= STUN, TURN, ICE, RTP, and SRTP.
>>
>> I wrote a draft outlining that - it is at:
>>
>> https://datatracker.ietf= .org/doc/draft-jennings-dispatch-new-media/
>>
>> it is being discussed on the dispatch@ietf.org email list ( you can join at https://www.ietf.org/mailman/listinfo/dispatch). Glad to= get PR at https://github.com/WhatIETF/= draft-jennings-dispatch-new-media
>>
>> Love to get feedback in general and also on how this, or parts of = it, would be a good way to go for the next version of WebRTC
>>
>> Thanks, Cullen
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--089e08244044204aff0566c2a3dc-- From nobody Tue Mar 6 11:34:31 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD501270A0 for ; Tue, 6 Mar 2018 11:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqp8yYRMCZnP for ; Tue, 6 Mar 2018 11:34:26 -0800 (PST) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (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 969D4126BF3 for ; Tue, 6 Mar 2018 11:34:26 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id b13so13873067uam.10 for ; Tue, 06 Mar 2018 11:34:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ffttGfAvTs2R6SsrlcRrF0L0j75tNBUTx+JEJ026gmA=; b=fNN9MGsYTO/FmDrz5HMVlMmcweRi/6DgYCi6tcRzpO5dO2IlEHaZDXMDoRkYQzI4b4 kqSzvnrdAmdR5tmyUlF4SShSOTTlenAXNg+r0kFRjkHt7WVqdr7mRopHrBrMuhBtDaJU UrGvn+z8Wi0R7sNzh9yM+aa/W5uVehdsg4i58b8HNVoezEag03P1RBWnlbhGa+GRByID AmI3yWtAl9vQBiDtU0SgC+2+J2Of+cIIusYqsulnT0ekwMw2EWGTLrBsSiEHUHqAp9+g lfzMgbqapO/jDRZgUnd0Ayuz3DsarFgg0iTuR0MbAjcPkwzKOWVadICP/wlcZs5JUMhY AbVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ffttGfAvTs2R6SsrlcRrF0L0j75tNBUTx+JEJ026gmA=; b=qk3evzgDqE9tyw7braY32KzSI8neqdPG5mdyexZewCSI9uStyjI+y3yT1N1SZIM4yd gR/Q0agQdxVfWMyVgWA4+sDKvOcGLA7S9flJ6twkSH31pvE565a/XMZHmen019u1C6W+ KJCIYIJ8gVsABEeRLImz/TJNgn9w5lhEfNrxvnv3Cf0PUbj1kG6GQ/knC+l39TVutYjD 5IgtMkqNlpLz671gX046qeafzEdRlYyeEl062F4uOnIm9tQvTXdGmd+cqfJ6W7+RrM66 SHvcnwi0JU+rgEqtkExVJ5qynMopqIsE1b6RZnn+g0UF/zos0jBx+cV6qqp5s/5a40Uo /zvg== X-Gm-Message-State: APf1xPDEcTMq/Exwo3owFwlUM3G6G5tt+TBGy8Hhpc44HIfReLbb4Sdl DgmnOQuV9Levkx/5abFPCF4B5NLgMhd7DNZF1Z8BpA== X-Google-Smtp-Source: AG47ELujxCFtAGw+zKcy0+DETW95L0jsxIEZqbvz7BIHGRYwTB15JUBxBmxFE7r6Ch9E079XoNQUo7q9D8B3oaoJEtM= X-Received: by 10.176.93.220 with SMTP id l28mr14195987uag.100.1520364864936; Tue, 06 Mar 2018 11:34:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.167.206 with HTTP; Tue, 6 Mar 2018 11:34:04 -0800 (PST) In-Reply-To: References: <3B663EB9-52D3-4069-A31C-03D6D0BB38BB@iii.ca> <4de127a2-2936-0022-34af-614129ea105f@alvestrand.no> From: Justin Uberti Date: Tue, 6 Mar 2018 11:34:04 -0800 Message-ID: To: Peter Thatcher Cc: Silvia Pfeiffer , RTCWeb IETF Content-Type: multipart/alternative; boundary="f403043efcd0b4a01a0566c38757" Archived-At: Subject: Re: [rtcweb] Getting rid of SDP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 19:34:29 -0000 --f403043efcd0b4a01a0566c38757 Content-Type: text/plain; charset="UTF-8" I agree with Peter; we also have input from Sergio's developer survey that indicates a supermajority of WebRTC developers want lower-level APIs. One notable aspect of Cullen's proposal is that it aims to replace basically everything all at once, when several of the individual pieces could be considered separately (e.g. Snowflake, media-transport-over-QUIC). Even if we don't think it makes sense to pursue all these pieces, we should be able to find common ground on a couple pieces for WebRTC v2. On Tue, Mar 6, 2018 at 10:30 AM, Peter Thatcher wrote: > I just recently sent an email to the list summarizing a previous list > thread asking people to share use cases that people were looking at. So, > in a sense I think we've already gone through the exercise of seeking use > cases, getting them, and summarizing them. The conclusion I came to was > that a set of orthogonal low-level APIs would meet the use cases people had > expressed. > > On Mon, Mar 5, 2018 at 11:02 PM Silvia Pfeiffer > wrote: > >> Yes, please, let's make a list of the use cases and the problems. >> Otherwise it feels like we're re-inventing technology for technology's >> sake. >> >> Kind Regards, >> Silvia. >> >> On Tue, Mar 6, 2018 at 5:39 PM, Harald Alvestrand >> wrote: >> > Nice to see that you too are arguing that we should get rid of SDP's >> > design errors! >> > >> > There are of course design errors (I think) in the proposal you made too >> > (the most glaring one is that you tie sources to clients - in order to >> > be generic building tools, sources need global IDs - otherwise we can't >> > build distribution trees for Baumgartner's parachute jump from space >> > using the same technology as chatting with Grandma). 128-bit random >> > numbers are lovely global identifiers. (This is the same error that went >> > into the original design of the http URL - tying location with identity. >> > But I digress.) >> > >> > I'd also like to have a security story that hangs together - each layer >> > has unique security properties that it needs to make sure are >> > satisfiable - from the neeed to not make DDOS simple at the network >> > layer to the assurance that I'm talking to Grandma and not some >> > CGI-generated scammer-face at the application layer. We've so far failed >> > to have a security story in WebRTC that is both comprehensive and >> > attractive to deploy - I'd like to see us do better next time around. >> > >> > I'm a little bit hesitant to ask this, but .... should we go back and >> > look at what use cases we plan to solve in this Grand Unified Scheme of >> > Things? >> > >> > Harald >> > >> > On 03/05/2018 08:43 PM, Cullen Jennings wrote: >> >> SDP is pretty awful. What we need to do to greatly simplify things is >> get rid of SDP. The offer answer is really complicated for modern systems >> that have more uniform capabilities so I would like to get rid of offer >> answer too. To simplify all the control, I think one needs to also simplify >> STUN, TURN, ICE, RTP, and SRTP. >> >> >> >> I wrote a draft outlining that - it is at: >> >> >> >> https://datatracker.ietf.org/doc/draft-jennings-dispatch-new-media/ >> >> >> >> it is being discussed on the dispatch@ietf.org email list ( you can >> join at https://www.ietf.org/mailman/listinfo/dispatch). Glad to get PR >> at https://github.com/WhatIETF/draft-jennings-dispatch-new-media >> >> >> >> Love to get feedback in general and also on how this, or parts of it, >> would be a good way to go for the next version of WebRTC >> >> >> >> Thanks, Cullen >> >> >> >> >> >> _______________________________________________ >> >> rtcweb mailing list >> >> rtcweb@ietf.org >> >> https://www.ietf.org/mailman/listinfo/rtcweb >> > >> > >> > _______________________________________________ >> > rtcweb mailing list >> > rtcweb@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --f403043efcd0b4a01a0566c38757 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Peter; we also have input from Sergio's d= eveloper survey that indicates a supermajority of WebRTC developers want lo= wer-level APIs.

One notable aspect of Cullen's propo= sal is that it aims to replace basically everything all at once, when sever= al of the individual pieces could be considered separately (e.g. Snowflake,= media-transport-over-QUIC). Even if we don't think it makes sense to p= ursue all these pieces, we should be able to find common ground on a couple= pieces for WebRTC v2.

On Tue, Mar 6, 2018 at 10:30 AM, Peter Thatcher <pthatcher@g= oogle.com> wrote:
I just recently sent an email to the list summarizing a previous l= ist thread asking people to share use cases that people were looking at.=C2= =A0 So, in a sense I think we've already gone through the exercise of s= eeking use cases, getting them, and summarizing them.=C2=A0 The conclusion = I came to was that a set of orthogonal low-level APIs would meet the use ca= ses people had expressed.

On Mon, Mar 5, 2018 at= 11:02 PM Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
Yes, please, let's make a list of the use cases= and the problems.
Otherwise it feels like we're re-inventing technology for technology= 9;s
sake.

Kind Regards,
Silvia.

On Tue, Mar 6, 2018 at 5:39 PM, Harald Alvestrand <harald@alvestrand.no> wrote: > Nice to see that you too are arguing that we should get rid of SDP'= ;s
> design errors!
>
> There are of course design errors (I think) in the proposal you made t= oo
> (the most glaring one is that you tie sources to clients - in order to=
> be generic building tools, sources need global IDs - otherwise we can&= #39;t
> build distribution trees for Baumgartner's parachute jump from spa= ce
> using the same technology as chatting with Grandma). 128-bit random > numbers are lovely global identifiers. (This is the same error that we= nt
> into the original design of the http URL - tying location with identit= y.
> But I digress.)
>
> I'd also like to have a security story that hangs together - each = layer
> has unique security properties that it needs to make sure are
> satisfiable - from the neeed to not make DDOS simple at the network > layer to the assurance that I'm talking to Grandma and not some > CGI-generated scammer-face at the application layer. We've so far = failed
> to have a security story in WebRTC that is both comprehensive and
> attractive to deploy - I'd like to see us do better next time arou= nd.
>
> I'm a little bit hesitant to ask this, but .... should we go back = and
> look at what use cases we plan to solve in this Grand Unified Scheme o= f
> Things?
>
> Harald
>
> On 03/05/2018 08:43 PM, Cullen Jennings wrote:
>> SDP is pretty awful. What we need to do to greatly simplify things= is get rid of SDP. The offer answer is really complicated for modern syste= ms that have more uniform capabilities so I would like to get rid of offer = answer too. To simplify all the control, I think one needs to also simplify= STUN, TURN, ICE, RTP, and SRTP.
>>
>> I wrote a draft outlining that - it is at:
>>
>> https://datatracker.ietf= .org/doc/draft-jennings-dispatch-new-media/
>>
>> it is being discussed on the dispatch@ietf.org email list ( you can join at https://www.ietf.org/mailman/listinfo/dispatch). Gl= ad to get PR at https://github.com/What= IETF/draft-jennings-dispatch-new-media
>>
>> Love to get feedback in general and also on how this, or parts of = it, would be a good way to go for the next version of WebRTC
>>
>> Thanks, Cullen
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/rtcw= eb
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

--f403043efcd0b4a01a0566c38757-- From nobody Wed Mar 7 11:49:34 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D018A12DA08 for ; Wed, 7 Mar 2018 11:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 CZrsjJDRojeV for ; Wed, 7 Mar 2018 11:49:20 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 2222A1200F1 for ; Wed, 7 Mar 2018 11:49:20 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id r16so4088392qtm.4 for ; Wed, 07 Mar 2018 11:49:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=DKtBU1C4NBc6OBYs6XwCYrdsKqTxSD022sKIi621VNI=; b=Fou2p4J08h1+xK86gSbATPp2j2zQRLUVJX0xgKIBT1WUO+EcZRZwPRyViFbJGod9iu XrzVahKlEyFNe11lo5dEQI79cJS6uryk/Cyfw67A971hQvirPUn2eoi1SApbSFC9pnob eGtN+rMzWzUkK7MC4m6cRRunw+uGV7dIMNzCU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=DKtBU1C4NBc6OBYs6XwCYrdsKqTxSD022sKIi621VNI=; b=EUSPcu3f3wRvXGB+gTSPlUnWOobfnr/1M3pNIkd66tRb9IDgJ4qv06y8yp/qSN4XJz CA4ePYt/Q7JktrNnNhiEdu5LTd0+MW1+3qzKqSuHK5deWOf0TZ5xcdkSGCM/HdYClnbF dqJL/2XAObJB+bITSmoF05iRKXtY2huLssSKCQPQbZ90dwk5edfGxcu+bu9Zhqgrgppy hQYKKWkG8Ey3udOFz8pKqXhysQESpGPYiTa4YArKRIF8T/d3WSvFV1BMjFw66tT37mxT 3ajlCfi2JrrL+GnjWhagTRmG75NQCoKNxmZzvP9JG9oftxxrjG0DIjClcbKLbx3Wfera 7DJQ== X-Gm-Message-State: AElRT7F5zg8jtdiIu5OxUIIQIG5JIj9jMAIKYVXNrXXuAz2z/pzUVDrP kQjBYmHR9nOE16Q+QkdWSlX9TdNVqTs= X-Google-Smtp-Source: AG47ELsPHNvzerRmkQKnXpCcIqi97Ob9bBI2hFzAcFYJZZMtLRRbSSznKlFjqTUDE8LifthrDFnYIw== X-Received: by 10.200.24.46 with SMTP id q43mr37118029qtj.309.1520452159172; Wed, 07 Mar 2018 11:49:19 -0800 (PST) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id q5sm8080683qkf.64.2018.03.07.11.49.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Mar 2018 11:49:18 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> Date: Wed, 7 Mar 2018 14:49:17 -0500 To: RTCWeb IETF X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 19:49:23 -0000 All, This is the WGLC for the "WebRTC IP Address Handling Requirements=E2=80=9D= draft available @ = https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/. Please = review the draft and send your comments to this list by 2359UTC on 30 = March 30 2017. Thanks, C/T/S= From nobody Wed Mar 7 12:13:01 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15B612D872 for ; Wed, 7 Mar 2018 12:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 Yc5ujOMcg5je for ; Wed, 7 Mar 2018 12:12:57 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 747F912D94C for ; Wed, 7 Mar 2018 12:12:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B454ABE74; Wed, 7 Mar 2018 20:12:55 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PO4vUhurNJw4; Wed, 7 Mar 2018 20:12:51 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DFC01BE73; Wed, 7 Mar 2018 20:12:50 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1520453571; bh=bnVej/iPj51OSnplRDmPOHUTISOAx0cCrrmSX6yZKu8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=y9iIZC+qVNhlXLoqRXTntUSNKscJulcFWX4xkOmywLqudRCGq89VZuASoz4RibzjX UMDlk/9tWoiipuojzEUXiuOVDsK04eoYL1XnS0APGOgUy5Zj65+v72GNYPdOq+1pSG u/VSCNaHZ0hRfIRnUcsZVmYQXtdNAMwY9f0AmY8g= To: Sean Turner , RTCWeb IETF References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> Date: Wed, 7 Mar 2018 20:12:50 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="P2778vMeenpQXy48FTGi6BkytwlHrid32" Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 20:13:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --P2778vMeenpQXy48FTGi6BkytwlHrid32 Content-Type: multipart/mixed; boundary="176o2ZEi16maUhyqvZsDFedVomgpTHJ2z"; protected-headers="v1" From: Stephen Farrell To: Sean Turner , RTCWeb IETF Message-ID: <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> In-Reply-To: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> --176o2ZEi16maUhyqvZsDFedVomgpTHJ2z Content-Type: multipart/mixed; boundary="------------09E1076F618E55F8B5B61FBD" Content-Language: en-GB This is a multi-part message in MIME format. --------------09E1076F618E55F8B5B61FBD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 07/03/18 19:49, Sean Turner wrote: > All, >=20 > This is the WGLC for the "WebRTC IP Address Handling Requirements=E2=80= =9D > draft available @ > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/. > Please review the draft and send your comments to this list by > 2359UTC on 30 March 30 2017. I've raised this previously, so this is, I guess, mostly just for the record, and I'll likely still be in the rough... I continue to think it is a bad idea to use the term "consent" at all, and especially coupled with getUserMedia and with mode 1 having a MUST for using all interfaces based on what I think is such a bogus concept. There is, IMO, no valid way in which a person can fairly be considered to have consented to any of this. I think entwining IETF specifications in the tangled web of web "consent" (so called) is going in exactly the wrong direction. Cheers, S. >=20 > Thanks, C/T/S _______________________________________________ rtcweb > mailing list rtcweb@ietf.org=20 > https://www.ietf.org/mailman/listinfo/rtcweb >=20 --------------09E1076F618E55F8B5B61FBD Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------09E1076F618E55F8B5B61FBD-- --176o2ZEi16maUhyqvZsDFedVomgpTHJ2z-- --P2778vMeenpQXy48FTGi6BkytwlHrid32 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaoEfCAAoJEFqy+vF7FyvqVwkP/28g8Je3pHbjd8AI5IVW+Hea Ja8amLAF2rp0GQUy2Zdl1FqqFPFGSnrvf7/7OmK8iQds959hfi34OSH4iMWR1M8e G3IncT+413+aPPUp8SBPboey0Ygc/wxxit9DnmdGJJRBvNPrRXMNjpXZI1Uj4aFD tJzvfborv6h34zMFAuFifLMJvdj0UZiCqGZbx/fuu7CrPY8z7eclI2BYnaqBtePv Be7mvqhoJgSscUUsTZFWfejspMDjwWDSUygOTLwRn5uTe7jY18hRDutkKQUV7+u5 yBcEm8gSqPT4Zj18jdqM4ihSEeQBmf2CCbtMoUkHPY2DomobpQB9zSZScWTzmCV2 GV9mPD0YrucrkuJ43MhTLQbdvm5sXUlsp5ZIJX/pD+xFMOylxxNn+wtjP9Z1YnLs 8LHbm+CTzvpYD/e9fL67TPBkh4RfMss/p5nTijie/txZOFB6umGHJ5SAjc1QDnHK uGAyD/VAJQrn0LNGE1x1u9uGbef9mwv0R6RBI6X0F6jYeEmiq1Tu2k/s6Z6Jf7S7 kLbsN+I9HVM+w9v6hjFIw0piW4O5KjUPng0o1WPLxEKb9pIQUTGY3RIzQc0fkAzU QuQxx/wEJ+8xqwLdW2kQnXd26q8+kz+oZbmn2t3on9KsbFV5XUbQNpUnqL98tXxa JI2QBAmZeXsxGK8McQ8v =LGEP -----END PGP SIGNATURE----- --P2778vMeenpQXy48FTGi6BkytwlHrid32-- From nobody Wed Mar 7 12:47:45 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4ED129C6B for ; Wed, 7 Mar 2018 12:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpiGSIU4iX5t for ; Wed, 7 Mar 2018 12:47:41 -0800 (PST) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 73187126B6D for ; Wed, 7 Mar 2018 12:47:41 -0800 (PST) Received: by mail-ua0-x22a.google.com with SMTP id n24so2389063ual.12 for ; Wed, 07 Mar 2018 12:47:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HKyKJzxJDfi+Si1AUUvSabgPkRlYXJKJo/fX0veFH78=; b=DA0cyvD2ihJT0rBbvqpCB8QXm5+WYsO1XwfnHmmxWSahvElTch1aAfpOgHDUCS1inM NsvzpuFJD9skVXQa3oZbLmc0A1Ky3QnjozE9/iI6wY6ZYK2vs2fJs4sdqBuXxfbxMPRh Qq7/7+GVR4RQD5WluBfYFcLURraQDg4AOPhjvRz23C5Iub0Jw01v1aIjpWJaTdSk4p4l HV7mWf205CtPVwvKD67qs38peoSCfVr3KhWpFY9TGEIr6qRBSFjup3Mgtp6ALiPZFb5V cpwIu/R5pxCWX+NeSvK/ML3gC0Kgg1RrMyZIQgj6Mh1RcJ7g1WdwncBxR43M2cdCztST sIhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HKyKJzxJDfi+Si1AUUvSabgPkRlYXJKJo/fX0veFH78=; b=bJ2eCVxe+3NNFfmPlJ8Fb7K4RglPyFhqmV4C9s8wYTTDsoQXLYE7fwp4j5//CHAjI8 THBV6DTXT2Le8ts1Ji2+JzYuKfcgsx/DqqhBOximehHPSFRa/DFHIez0b1E6pKfwL0A+ NtQshZlNg0mJa7PxKN+oZsM8kzsMxyRnMX+S0MtmtmL6GdilHVgStzZc7sllQ3kSK4CI gTlYaadJuq8Qtq7BIr8HJJdhwSHU2nnF1b4wRY3O4oWSVxR9Jez1iCCVvHLoHxDZevI1 STVzEZTJMImA0tzIZIaxUqA3qD9rBDRWDVBy9wJI7Eha2mX7B2T3r8fZcBQARLgTbnNH OMDQ== X-Gm-Message-State: APf1xPDw13ZqD/JP0NnAuxdvHMq2OfBx4mJnbTh1WP2sLb6SrpRHx+kK jHJNEUhMQJk1oThPUbD8lZoHaATAQ21V8MAnNK4mIQ== X-Google-Smtp-Source: AG47ELtSWtpTZBajII7yxP5rBmgPc6wmYXcedpTQYX63a4rRWanIKLfXkdJmvMSzwLEjwLoAk5loFb2wh+qeFQFrwLc= X-Received: by 10.159.60.4 with SMTP id u4mr17450107uah.87.1520455659810; Wed, 07 Mar 2018 12:47:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.167.206 with HTTP; Wed, 7 Mar 2018 12:47:19 -0800 (PST) In-Reply-To: <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> From: Justin Uberti Date: Wed, 7 Mar 2018 12:47:19 -0800 Message-ID: To: Stephen Farrell Cc: Sean Turner , RTCWeb IETF Content-Type: multipart/alternative; boundary="f403043ed54c80a8bc0566d8ab50" Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 20:47:43 -0000 --f403043ed54c80a8bc0566d8ab50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To be clear, the MUST does not say that all interfaces MUST be used if consent is given, rather the converse, that you MUST only use all interfaces if there is consent. In addition, while gUM consent is given as an example, it is not normative. Mode 1 MUST only be used when user consent has been provided. The details of this consent are left to the implementation; one potential mechanism is to tie this consent to getUserMedia consent. On Wed, Mar 7, 2018 at 12:12 PM, Stephen Farrell wrote: > > Hiya, > > On 07/03/18 19:49, Sean Turner wrote: > > All, > > > > This is the WGLC for the "WebRTC IP Address Handling Requirements=E2=80= =9D > > draft available @ > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/. > > Please review the draft and send your comments to this list by > > 2359UTC on 30 March 30 2017. > > I've raised this previously, so this is, I guess, mostly just > for the record, and I'll likely still be in the rough... > > I continue to think it is a bad idea to use the term "consent" > at all, and especially coupled with getUserMedia and with mode > 1 having a MUST for using all interfaces based on what I think > is such a bogus concept. There is, IMO, no valid way in which a > person can fairly be considered to have consented to any of this. > I think entwining IETF specifications in the tangled web of web > "consent" (so called) is going in exactly the wrong direction. > > Cheers, > S. > > > > > > Thanks, C/T/S _______________________________________________ rtcweb > > mailing list rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --f403043ed54c80a8bc0566d8ab50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To be clear, the MUST does not say that all interface= s MUST be used if consent is given, rather the converse, that you MUST only= use all interfaces if there is consent.

In ad= dition, while gUM consent is given as an example, it is not normative.
<= div>
 =
  Mode 1 MUST only be used when user consent has been provided.  The
   details of this consent are left to the implementation; one potential
   mechanism is to tie this consent to getUserMedia consent.


On Wed, Mar 7, 2018 at 12:12 PM, Stephen Farrell <st= ephen.farrell@cs.tcd.ie> wrote:

Hiya,

On 07/03/18 19:49, Sean Turner wrote:
> All,
>
> This is the WGLC for the "WebRTC IP Address Handling Requirements= =E2=80=9D
> draft available @
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/.
> Please review the draft and send your comments to this list by
> 2359UTC on 30 March 30 2017.

I've raised this previously, so this is, I guess, mostly just for the record, and I'll likely still be in the rough...

I continue to think it is a bad idea to use the term "consent" at all, and especially coupled with getUserMedia and with mode
1 having a MUST for using all interfaces based on what I think
is such a bogus concept. There is, IMO, no valid way in which a
person can fairly be considered to have consented to any of this.
I think entwining IETF specifications in the tangled web of web
"consent" (so called) is going in exactly the wrong direction.
Cheers,
S.


>
> Thanks, C/T/S _______________________________________________ rtc= web
> mailing list rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb
>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--f403043ed54c80a8bc0566d8ab50-- From nobody Wed Mar 7 13:12:25 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC1C12D964 for ; Wed, 7 Mar 2018 13:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 vVnAJTSq4jEF for ; Wed, 7 Mar 2018 13:12:18 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA77127863 for ; Wed, 7 Mar 2018 13:12:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6BECABE77; Wed, 7 Mar 2018 21:12:16 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xT9zxlGRDmO8; Wed, 7 Mar 2018 21:12:14 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B76DABE74; Wed, 7 Mar 2018 21:12:14 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1520457134; bh=p9RpT3g++6bAxMiq4NUok7fm1aT2oBrI431FaHF091Y=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=w1cKp9toBw7CVUtmdaJOTbWNMzO4AfW/NoHYQRP3wqyEiVdsino+Oh5fHCtwd8QjE rmtmII6a4wxlfmG7Yqf6JtP5V0TuNi+eGTKoab1v7tr+DENh1aWvp3nuJMUS6l0GQG Z1OncvokNb/g6gbyEEsixBHJB8GPGBUdcONdUQ8U= To: Justin Uberti Cc: Sean Turner , RTCWeb IETF References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> Date: Wed, 7 Mar 2018 21:12:14 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CW1OPtApOCPwdFP1HpfmSgGqJo4FqtYVZ" Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 21:12:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CW1OPtApOCPwdFP1HpfmSgGqJo4FqtYVZ Content-Type: multipart/mixed; boundary="LzqPV94dP6BzrFzommlq5VKFaIcJ3H8JJ"; protected-headers="v1" From: Stephen Farrell To: Justin Uberti Cc: Sean Turner , RTCWeb IETF Message-ID: <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> In-Reply-To: --LzqPV94dP6BzrFzommlq5VKFaIcJ3H8JJ Content-Type: multipart/mixed; boundary="------------6D8909ED8C79D116D40700C4" Content-Language: en-GB This is a multi-part message in MIME format. --------------6D8909ED8C79D116D40700C4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, To also be clear: my main objection is to the term consent being used at all. The stuff below isn't that big a deal, though would change if the WG did drop the idea of "consent" supposedly being a real thing. On 07/03/18 20:47, Justin Uberti wrote: > To be clear, the MUST does not say that all interfaces MUST be used if > consent is given, rather the converse, that you MUST only use all > interfaces if there is consent. It's unclear to me that there's any practical difference there. Are there any implementations that do something else? (Apologies if that's clear to everyone else:-) > In addition, while gUM consent is given as an example, it is not normat= ive. >=20 > Mode 1 MUST only be used when user consent has been provided. The > details of this consent are left to the implementation; one potentia= l > mechanism is to tie this consent to getUserMedia consent. Sure. OTOH, IIUC, that is what's done in web browsers so it kind of really is normative, in practice. Again, apologies if there are other things done in browsers. S. >=20 >=20 >=20 > On Wed, Mar 7, 2018 at 12:12 PM, Stephen Farrell > wrote: >=20 >> >> Hiya, >> >> On 07/03/18 19:49, Sean Turner wrote: >>> All, >>> >>> This is the WGLC for the "WebRTC IP Address Handling Requirements=E2=80= =9D >>> draft available @ >>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/. >>> Please review the draft and send your comments to this list by >>> 2359UTC on 30 March 30 2017. >> >> I've raised this previously, so this is, I guess, mostly just >> for the record, and I'll likely still be in the rough... >> >> I continue to think it is a bad idea to use the term "consent" >> at all, and especially coupled with getUserMedia and with mode >> 1 having a MUST for using all interfaces based on what I think >> is such a bogus concept. There is, IMO, no valid way in which a >> person can fairly be considered to have consented to any of this. >> I think entwining IETF specifications in the tangled web of web >> "consent" (so called) is going in exactly the wrong direction. >> >> Cheers, >> S. >> >> >>> >>> Thanks, C/T/S _______________________________________________ rtcweb >>> mailing list rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >=20 --------------6D8909ED8C79D116D40700C4 Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------6D8909ED8C79D116D40700C4-- --LzqPV94dP6BzrFzommlq5VKFaIcJ3H8JJ-- --CW1OPtApOCPwdFP1HpfmSgGqJo4FqtYVZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaoFWuAAoJEFqy+vF7FyvqqgYP/2BuTq1WvjESOylLbUoym6xp U2Czpdr41VNGJJsKDJ5heSKl1UcUpnqB1rzqJ1N3MHfbLToyeF1HwUVm5+YEy6MB JAKFHTg0joZgN/UcoYoqK/gDHNN/ZgcP0mg+7IjA+iZOa2bbI3KWWK9niHhHqimj 7pMf5Ri5j7LwdcaKpJP7saOGxdjlUhYgmp4z8kykgB7tb2xqDYRvstzB3bxrnSVV awlPAP3TBqK6ssVnS1/OKglo1FRUBh4aqMY89p74dpouHw3+RgVFzAAj6RHtYOAf 43CaYXJRcNYQaGqT3Q+sxCUoDGrPtMsNfwjlssrwD2TY6xXMT/nY7o+lBnMYVT1s 73XVIh2/KE0WlMYDNMVUg/g1sXqgTil0t8noO84rC+hpYfsbBZPtEYXF96lvyW+R sCIb9zwB1Zmil3KECnFLIVPr6PwgovBeu4OO0T9qk23W6WztZW/9UE9n8tuBNRXp r5bOye7kPeHEiDxYtPV9y8ndJUUyZUxsHMDGjJijJykqjG4Ua/gacUbT34CDTcFi IW8ZCgdu/aOUoEvIr92CiJD/fk0slIiKeVR/TXTsp7DAVc6LKWOsBBGrIuQtSrt+ ZdRX9i4ZyaJZZKQdeMsvuYPOb8pwwfSesNJagrmv+PPSjyjvk003DZASUtZTr5oI tnyTYcJ6dmVfHB82wLQe =y/Tb -----END PGP SIGNATURE----- --CW1OPtApOCPwdFP1HpfmSgGqJo4FqtYVZ-- From nobody Wed Mar 7 14:14:15 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D845512D958 for ; Wed, 7 Mar 2018 14:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ALpRjxoxGxgQ for ; Wed, 7 Mar 2018 14:14:11 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 91DD3127419 for ; Wed, 7 Mar 2018 14:14:11 -0800 (PST) Received: by mail-oi0-x22a.google.com with SMTP id x12so2889293oie.13 for ; Wed, 07 Mar 2018 14:14:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=P1T2lha+SjTM67VnubA+gemcF8CVpJWT5UYVW/7QXI0=; b=DDdRbSqYHHFHQC+x0k9CWg/FHa8iHsxnaSSeT563aK/x8OpgOT7p2xtYnjigiiLcTT kAAk+nY15ZX4UgWylRgZQUK1+XVnp7nckfmDk6c5dn7fW4G1s14s66ZPVbR1f2moj7lD MnUNJot2sdgAYk8SueweT+uBT19Fw+eVXNKJ21zKRgjB5nAr9GELKNni/wUNWnWIwK2Z 0hsBFJrJ3uCFjmGb7FXiyxxy2r94qvnYbw0KCBUi5WOJ4CNli6YLPqR+741t0VQNCy2n AbtWFNdphyKLbSag5ps9usLAadmjUwoJn9VEpYZ795DxNGfAlgjLOsKqYlApU3KYTYw/ /qwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=P1T2lha+SjTM67VnubA+gemcF8CVpJWT5UYVW/7QXI0=; b=Fmx1/c+kIUWh5E4kDckGHTbVYePzbtBYsa5/THXJvRN056yeNDYNIFjAqZt7XSN6sZ 0Qyzi1s2Bg+3bXmA037FVkzUeeN/eReaWWTSMbvFfKd7SXz2U0q00g1i6ez+EQ/4EY4G RHWAOcyvpauJTlCRerWG2UAzjgTedvhWucYt5dA23CbcA5Q9KX/BLMDMdISbiV6bkFYh YVFQ0K5RNudNocILVB4PVHNv9BAX1x9VPT7xH2RMaYa4CFWEG9NfWBR5gjAhl54ljAyc BwJ2TRnox5S/v8a+wqmNLF0QN6yBpUc/Z8VDcbBjBoMKhC1gC3mZdK8/313rdeDiPful gWtw== X-Gm-Message-State: AElRT7G8m9BznzByddwkANmDOk6ZYVGktCL2LJseOs0D/6QunbEsZD1O Y69WRNWoEqHVoiUilFU3aaZARn8H5pYE36LONlw= X-Google-Smtp-Source: AG47ELvsjP8k6cbPsGop6sLCHNUBrN63cLiLNTSc0j/dmLdmAorUcEzGyl0yF53KIebeJYL/vGBZwhE3LeeWBIJeB9Q= X-Received: by 10.202.235.12 with SMTP id j12mr14956859oih.284.1520460850691; Wed, 07 Mar 2018 14:14:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.7.27 with HTTP; Wed, 7 Mar 2018 14:13:40 -0800 (PST) In-Reply-To: <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> From: Ted Hardie Date: Wed, 7 Mar 2018 14:13:40 -0800 Message-ID: To: Stephen Farrell Cc: Justin Uberti , RTCWeb IETF Content-Type: multipart/alternative; boundary="001a113cc70ce684a70566d9e015" Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 22:14:14 -0000 --001a113cc70ce684a70566d9e015 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 7, 2018 at 1:12 PM, Stephen Farrell wrote: > > Hiya, > > To also be clear: my main objection is to the term consent being > used at all. The stuff below isn't that big a deal, though would > change if the WG did drop the idea of "consent" supposedly being > a real thing. > > So, while I am sympathetic (just generally, really, not just to this), I think "consent" is basically a term of art in the web world and that its use in the document is consistent with the more general use. If you know of a different term of art here that would be similarly well-understood, I would be glad to know of it. It may also be an interesting project to create such a term. But I don't think the document should wait on that. > On 07/03/18 20:47, Justin Uberti wrote: > > To be clear, the MUST does not say that all interfaces MUST be used if > > consent is given, rather the converse, that you MUST only use all > > interfaces if there is consent. > > It's unclear to me that there's any practical difference there. > Are there any implementations that do something else? (Apologies > if that's clear to everyone else:-) > > > In addition, while gUM consent is given as an example, it is not > normative. > > > > Mode 1 MUST only be used when user consent has been provided. The > > details of this consent are left to the implementation; one potentia= l > > mechanism is to tie this consent to getUserMedia consent. > > Sure. OTOH, IIUC, that is what's done in web browsers so it kind > of really is normative, in practice. Again, apologies if there > are other things done in browsers. > > If I recall correctly, it was not made normative because mobile applications might use this using advice outside browser contexts. I can't find an immediate citation to that, though, so it may be a convenient reconstruction rather than an accurate memory. Ted > S. > > > > > > > > > > On Wed, Mar 7, 2018 at 12:12 PM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> > > wrote: > > > >> > >> Hiya, > >> > >> On 07/03/18 19:49, Sean Turner wrote: > >>> All, > >>> > >>> This is the WGLC for the "WebRTC IP Address Handling Requirements=E2= =80=9D > >>> draft available @ > >>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/. > >>> Please review the draft and send your comments to this list by > >>> 2359UTC on 30 March 30 2017. > >> > >> I've raised this previously, so this is, I guess, mostly just > >> for the record, and I'll likely still be in the rough... > >> > >> I continue to think it is a bad idea to use the term "consent" > >> at all, and especially coupled with getUserMedia and with mode > >> 1 having a MUST for using all interfaces based on what I think > >> is such a bogus concept. There is, IMO, no valid way in which a > >> person can fairly be considered to have consented to any of this. > >> I think entwining IETF specifications in the tangled web of web > >> "consent" (so called) is going in exactly the wrong direction. > >> > >> Cheers, > >> S. > >> > >> > >>> > >>> Thanks, C/T/S _______________________________________________ rtcweb > >>> mailing list rtcweb@ietf.org > >>> https://www.ietf.org/mailman/listinfo/rtcweb > >>> > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > >> > >> > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a113cc70ce684a70566d9e015 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Mar 7, 2018 at 1:12 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hiya,

To also be clear: my main objection is to the term consent being
used at all. The stuff below isn't that big a deal, though would
change if the WG did drop the idea of "consent" supposedly being<= br> a real thing.


So, while I am= sympathetic (just generally, really, not just to this), I think "cons= ent" is basically a term of art in the web world and that its use in t= he document is consistent with the more general use.=C2=A0

If you know of a different term of art here that would be similarly well= -understood, I would be glad to know of it.=C2=A0 It may also be an interes= ting project to create such a term.=C2=A0 But I don't think the documen= t should wait on that.

=C2=A0
On 07/03/18 20:47, Justin Uberti wrote:
> To be clear, the MUST does not say that all interfaces MUST be used if=
> consent is given, rather the converse, that you MUST only use all
> interfaces if there is consent.

It's unclear to me that there's any practical difference the= re.
Are there any implementations that do something else? (Apologies
if that's clear to everyone else:-)

> In addition, while gUM consent is given as an example, it is not norma= tive.
>
>=C2=A0 =C2=A0 Mode 1 MUST only be used when user consent has been provi= ded.=C2=A0 The
>=C2=A0 =C2=A0 details of this consent are left to the implementation; o= ne potential
>=C2=A0 =C2=A0 mechanism is to tie this consent to getUserMedia consent.=

Sure. OTOH, IIUC, that is what's done in web browsers so it kind=
of really is normative, in practice. Again, apologies if there
are other things done in browsers.

If I recall correctly, it was not made normative because mobile app= lications might use this using advice outside browser contexts.=C2=A0 I can= 't find an immediate citation to that, though, so it may be a convenien= t reconstruction rather than an accurate memory.

Ted
<= /div>

=C2=A0
S.


>
>
>
> On Wed, Mar 7, 2018 at 12:12 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
>
>>
>> Hiya,
>>
>> On 07/03/18 19:49, Sean Turner wrote:
>>> All,
>>>
>>> This is the WGLC for the "WebRTC IP Address Handling Requ= irements=E2=80=9D
>>> draft available @
>>> https://datatracker.ietf= .org/doc/draft-ietf-rtcweb-ip-handling/.
>>> Please review the draft and send your comments to this list by=
>>> 2359UTC on 30 March 30 2017.
>>
>> I've raised this previously, so this is, I guess, mostly just<= br> >> for the record, and I'll likely still be in the rough...
>>
>> I continue to think it is a bad idea to use the term "consent= "
>> at all, and especially coupled with getUserMedia and with mode
>> 1 having a MUST for using all interfaces based on what I think
>> is such a bogus concept. There is, IMO, no valid way in which a >> person can fairly be considered to have consented to any of this.<= br> >> I think entwining IETF specifications in the tangled web of web >> "consent" (so called) is going in exactly the wrong dire= ction.
>>
>> Cheers,
>> S.
>>
>>
>>>
>>> Thanks, C/T/S ___________________________________________= ____ rtcweb
>>> mailing list rtcweb@ietf.or= g
>>> https://www.ietf.org/mailman/listinf= o/rtcweb
>>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcw= eb
>>
>>
>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--001a113cc70ce684a70566d9e015-- From nobody Wed Mar 7 14:36:12 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B05D127419 for ; Wed, 7 Mar 2018 14:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yxc-HKYLU06x for ; Wed, 7 Mar 2018 14:36:07 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 91C41126CBF for ; Wed, 7 Mar 2018 14:36:07 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id f6so2424993vkh.6 for ; Wed, 07 Mar 2018 14:36:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=38UtrCqcOdt8zTPbmJod2fCrwAAob12riRXE6KiowfQ=; b=AL0Ge2K31l+lAah/YQ9vA04CRYKaUXnyyMm5cesCl+UY9M1rupEoGBLTvQcyJbSZrL JevI5ooPAd3joOMJKYQpMkgoKKQVt7xIfjc57v4ysp13/kcy2937hMOjbtQIfOtnByJe oTDTT1e/TKyCDatxoYvc82lEypkubn4C0Y2sQN5KENtU2n9+AdsN0iNBzQHGIvPqFLXx 4MPc3L1vUbCOY86y2uVdUc3Wzz7CGWUOSQVW3S1zSt83S5dKZpqetKkLS7lvdQRA90C6 b5EBB+5S8qR+Taf470HoIL68J7dDL+ULgAjkFwfg/Ay0pQbtzb7gSPB553WG3KT6dzOy Gm+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=38UtrCqcOdt8zTPbmJod2fCrwAAob12riRXE6KiowfQ=; b=qalVOsmHxLSRCemPcUzb4J3yX/l75x9vaddN1yLBa8Z+SHAxKMix7U5CFmd4l0wrDR GG28hHICzyrDR0a/auADlybOu3pbmxszIiP03OO/bFIUTFKSGKGl4Bugyr6UyBQHOqi4 1dVnUbmDkEm4AOqxU9c5IsDhjCUvTktYDRAFOxq3X4y5h8Bsi5ce4NEENu5vS0KMb1E0 P76Sn1xDTwwmWnUd08yx/LrugVXJANQYVvO6hUguEx+/c6tH7T0lNtuKze+CkkQzu/Pl XnbYShjSTCO9jqp93apoxlfDJ+OdrJs6g6DhKN8rVA82jdnWuG2gRNn+q9EShAoW2+eQ eqMQ== X-Gm-Message-State: APf1xPA5G1rTcIXvuWJTJaN4E+tSUGKeWTGB01oMtAapWaFYJq+jgpO5 5/Z0QCedgk0cUgTVdDY6+GyEobYYVlka/YJH6+logQ== X-Google-Smtp-Source: AG47ELs4iatO8gbPMrcfFVLdgz0VGJS2JrGJq5GXLlvBCNALMogRJ4hK8GOSJPsgT93GXmgmImb1KQ1zZm4S1iJqgUw= X-Received: by 10.31.248.195 with SMTP id w186mr17936057vkh.78.1520462166129; Wed, 07 Mar 2018 14:36:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.167.206 with HTTP; Wed, 7 Mar 2018 14:35:45 -0800 (PST) In-Reply-To: <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> From: Justin Uberti Date: Wed, 7 Mar 2018 14:35:45 -0800 Message-ID: To: Stephen Farrell Cc: Sean Turner , RTCWeb IETF Content-Type: multipart/alternative; boundary="94eb2c1495424f12130566da2f63" Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 22:36:10 -0000 --94eb2c1495424f12130566da2f63 Content-Type: text/plain; charset="UTF-8" On Wed, Mar 7, 2018 at 1:12 PM, Stephen Farrell wrote: > > Hiya, > > To also be clear: my main objection is to the term consent being > used at all. The stuff below isn't that big a deal, though would > change if the WG did drop the idea of "consent" supposedly being > a real thing. > > On 07/03/18 20:47, Justin Uberti wrote: > > To be clear, the MUST does not say that all interfaces MUST be used if > > consent is given, rather the converse, that you MUST only use all > > interfaces if there is consent. > > It's unclear to me that there's any practical difference there. > Are there any implementations that do something else? (Apologies > if that's clear to everyone else:-) > > > In addition, while gUM consent is given as an example, it is not > normative. > > > > Mode 1 MUST only be used when user consent has been provided. The > > details of this consent are left to the implementation; one potential > > mechanism is to tie this consent to getUserMedia consent. > > Sure. OTOH, IIUC, that is what's done in web browsers so it kind > of really is normative, in practice. Again, apologies if there > are other things done in browsers. > I believe that the Brave browser uses Mode 4 in its private browsing mode. https://github.com/brave/browser-laptop/issues/260 --94eb2c1495424f12130566da2f63 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Mar 7, 2018 at 1:12 PM, Stephen Farrell <<= a href=3D"mailto:stephen.farrell@cs.tcd.ie" target=3D"_blank">stephen.farre= ll@cs.tcd.ie> wrote:

Hiya,

To also be clear: my main objection is to the term consent being
used at all. The stuff below isn't that big a deal, though would
change if the WG did drop the idea of "consent" supposedly being<= br> a real thing.

On 07/03/18 20:47, Justin Uberti wrote:
> To be clear, the MUST does not say that all interfaces MUST be used if=
> consent is given, rather the converse, that you MUST only use all
> interfaces if there is consent.

It's unclear to me that there's any practical difference the= re.
Are there any implementations that do something else? (Apologies
if that's clear to everyone else:-)

> In addition, while gUM consent is given as an example, it is not norma= tive.
>
>=C2=A0 =C2=A0 Mode 1 MUST only be used when user consent has been provi= ded.=C2=A0 The
>=C2=A0 =C2=A0 details of this consent are left to the implementation; o= ne potential
>=C2=A0 =C2=A0 mechanism is to tie this consent to getUserMedia consent.=

Sure. OTOH, IIUC, that is what's done in web browsers so it kind=
of really is normative, in practice. Again, apologies if there
are other things done in browsers.

I be= lieve that the Brave browser uses Mode 4 in its private browsing mode.
--94eb2c1495424f12130566da2f63-- From nobody Wed Mar 7 14:39:41 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638EF126CBF for ; Wed, 7 Mar 2018 14:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRxfJajOLDyF for ; Wed, 7 Mar 2018 14:39:37 -0800 (PST) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (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 A1359127419 for ; Wed, 7 Mar 2018 14:39:37 -0800 (PST) Received: by mail-ua0-x233.google.com with SMTP id u99so2610026uau.8 for ; Wed, 07 Mar 2018 14:39:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hr7PDmsEO1tCnqWkC7Y6xWspldht6t3UGp2Er3bmH5c=; b=Hp7qSeDEL4cFL3ify/uIff8F7W7foz6HGZdN7Zk24XE0LXXQ0WeWiB/iK1N/lu6yxx G3bbPLT4vbRDdTtMqD9MDIoi+U130YrqJJtcr88OW+Jkxe1NThGMK8+8/32i6z+hkD89 TcMPxxC84W04TVKZSIO9bpR572DbYAbLu3zgOGgY9H3Ff41qMx+1UTlnhS4ZLEV2oWIZ OBtvns0HiNNUyQjnVaFLitPWCfhpSJJWDFRblv9F0n12evN8OtQtbRUX/MyN6zJRqyjN OjGy5beCQyoc3yeY/HBakJztoMC0mVXNRupQaNMaoAyLLXeQ0stF4JdkfsHZOJpDsjtV wLgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hr7PDmsEO1tCnqWkC7Y6xWspldht6t3UGp2Er3bmH5c=; b=B09OYl7+AsAHYW5g2xVDOwlodOrqWCTW+jjr/9TGKzlhNLMGCWdO+f2oYJtIJrngwr aDyt7ERj7jKTlSRF5Ma6Lmp+dXXq4XHtpIByykUrMCKAAuSCo/HWa/dCDCEQQNIjNa/R GkiAEd1KDhTCxfo1ZDn+lHj0WnjWwvuNptZctugqMsocgZ70sjnHGRiLpLljoqO8j5ww TUs+zuC8LH3pQWBBGc2M3V7cbtqvYAaUcs3UEpQgxe3agmhgPcsJaj3uqToUNj5Jku4F A6+syDuUshejxJX+mizd0NMs0AQovxoh2SJQL7tpIMu5mpkSHz5x+LxPIQVZ/52yLgg0 RJnw== X-Gm-Message-State: AElRT7EC8ov1dmb9WqqKSNov5Zvg1IyuWHpLit4sHIT15oNz1IEdKEGj 64nLW7PcPFUidDjAktNPauFdXc9WGQME94JUpBUqqw== X-Google-Smtp-Source: AG47ELsslsU2qJgybyqF+2RIfyZ76pViM4/T5CKqnYBCBDW6bDZfJc+UoYXc4xUEF+wu+RkTzgNnCmWgps4KIaSvMB4= X-Received: by 10.176.6.197 with SMTP id g63mr14458969uag.72.1520462376121; Wed, 07 Mar 2018 14:39:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.167.206 with HTTP; Wed, 7 Mar 2018 14:39:15 -0800 (PST) In-Reply-To: References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> From: Justin Uberti Date: Wed, 7 Mar 2018 14:39:15 -0800 Message-ID: To: Ted Hardie Cc: Stephen Farrell , RTCWeb IETF Content-Type: multipart/alternative; boundary="94eb2c122e64d343e80566da3b70" Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 22:39:39 -0000 --94eb2c122e64d343e80566da3b70 Content-Type: text/plain; charset="UTF-8" On Wed, Mar 7, 2018 at 2:13 PM, Ted Hardie wrote: > On Wed, Mar 7, 2018 at 1:12 PM, Stephen Farrell > wrote: > >> >> Hiya, >> >> To also be clear: my main objection is to the term consent being >> used at all. The stuff below isn't that big a deal, though would >> change if the WG did drop the idea of "consent" supposedly being >> a real thing. >> >> > So, while I am sympathetic (just generally, really, not just to this), I > think "consent" is basically a term of art in the web world and that its > use in the document is consistent with the more general use. > > If you know of a different term of art here that would be similarly > well-understood, I would be glad to know of it. It may also be an > interesting project to create such a term. But I don't think the document > should wait on that. > > > >> On 07/03/18 20:47, Justin Uberti wrote: >> > To be clear, the MUST does not say that all interfaces MUST be used if >> > consent is given, rather the converse, that you MUST only use all >> > interfaces if there is consent. >> >> It's unclear to me that there's any practical difference there. >> Are there any implementations that do something else? (Apologies >> if that's clear to everyone else:-) >> >> > In addition, while gUM consent is given as an example, it is not >> normative. >> > >> > Mode 1 MUST only be used when user consent has been provided. The >> > details of this consent are left to the implementation; one potential >> > mechanism is to tie this consent to getUserMedia consent. >> >> Sure. OTOH, IIUC, that is what's done in web browsers so it kind >> of really is normative, in practice. Again, apologies if there >> are other things done in browsers. >> >> If I recall correctly, it was not made normative because mobile > applications might use this using advice outside browser contexts. I can't > find an immediate citation to that, though, so it may be a convenient > reconstruction rather than an accurate memory. > > Yes, that was one reason; generally, there was squeamishness around codifying the exact form consent should take in this sort of document (i.e., an IETF vs W3C recommendation). --94eb2c122e64d343e80566da3b70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Mar 7, 2018 at 2:13 PM, Ted Hardie <ted.ietf@gmail.com>= ; wrote:
On= Wed, Mar 7, 2018 at 1:12 PM, Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:

Hiya,

To also be clear: my main objection is to the term consent being
used at all. The stuff below isn't that big a deal, though would
change if the WG did drop the idea of "consent" supposedly being<= br> a real thing.


So, while I am sym= pathetic (just generally, really, not just to this), I think "consent&= quot; is basically a term of art in the web world and that its use in the d= ocument is consistent with the more general use.=C2=A0

I= f you know of a different term of art here that would be similarly well-und= erstood, I would be glad to know of it.=C2=A0 It may also be an interesting= project to create such a term.=C2=A0 But I don't think the document sh= ould wait on that.

=C2=A0
On 07/03/18 20:47, Justin Uberti wrote:
> To be clear, the MUST does not say that all interfaces MUST be used if=
> consent is given, rather the converse, that you MUST only use all
> interfaces if there is consent.

It's unclear to me that there's any practical difference the= re.
Are there any implementations that do something else? (Apologies
if that's clear to everyone else:-)

> In addition, while gUM consent is given as an example, it is not norma= tive.
>
>=C2=A0 =C2=A0 Mode 1 MUST only be used when user consent has been provi= ded.=C2=A0 The
>=C2=A0 =C2=A0 details of this consent are left to the implementation; o= ne potential
>=C2=A0 =C2=A0 mechanism is to tie this consent to getUserMedia consent.=

Sure. OTOH, IIUC, that is what's done in web browsers so it kind=
of really is normative, in practice. Again, apologies if there
are other things done in browsers.

If I recall correc= tly, it was not made normative because mobile applications might use this u= sing advice outside browser contexts.=C2=A0 I can't find an immediate c= itation to that, though, so it may be a convenient reconstruction rather th= an an accurate memory.

<= div>
Yes, that was one reason; generally, there was squeamish= ness around codifying the exact form consent should take in this sort of do= cument (i.e., an IETF vs W3C recommendation).
--94eb2c122e64d343e80566da3b70-- From nobody Wed Mar 7 14:51:41 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B468B12D86B for ; Wed, 7 Mar 2018 14:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 BZdoI7EpXMjT for ; Wed, 7 Mar 2018 14:51:37 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8375E127419 for ; Wed, 7 Mar 2018 14:51:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EA821BE5B; Wed, 7 Mar 2018 22:51:34 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySqkXMBhQv1i; Wed, 7 Mar 2018 22:51:33 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7B887BE4C; Wed, 7 Mar 2018 22:51:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1520463093; bh=VCJ3kEYPg/RucoDBUm1Z5yP/QezGzW1x0pLJQDaysRw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=pjhh5y09CUw2KHQxKx0zGlsfs13EYdHyyJKf1lwOsBP5835EZUBSqKAbKuGvQ+nJ+ C4oVvYgJ7XLp3EdIr2yaYsujr2LTyKHbxucMFYiwnZ6NSmjajjH6X5mxlJKQ9TE7uv WfTZ6+BOQS6ctfeRg43wHB5SUtn6NdyGuiJ/PuiM= To: Justin Uberti Cc: Sean Turner , RTCWeb IETF References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: Date: Wed, 7 Mar 2018 22:51:32 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CZgbKOGmebh1BFH7z0udtkIZpUYakBqQO" Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 22:51:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CZgbKOGmebh1BFH7z0udtkIZpUYakBqQO Content-Type: multipart/mixed; boundary="O514DXE1GIfIhThtzYWCoBCdqEiH3cwu1"; protected-headers="v1" From: Stephen Farrell To: Justin Uberti Cc: Sean Turner , RTCWeb IETF Message-ID: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> In-Reply-To: --O514DXE1GIfIhThtzYWCoBCdqEiH3cwu1 Content-Type: multipart/mixed; boundary="------------EBD90281B4CD9F27CB978E64" Content-Language: en-GB This is a multi-part message in MIME format. --------------EBD90281B4CD9F27CB978E64 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/03/18 22:35, Justin Uberti wrote: >>> In addition, while gUM consent is given as an example, it is not >> normative. >>> Mode 1 MUST only be used when user consent has been provided. The= >>> details of this consent are left to the implementation; one potent= ial >>> mechanism is to tie this consent to getUserMedia consent. >> Sure. OTOH, IIUC, that is what's done in web browsers so it kind >> of really is normative, in practice. Again, apologies if there >> are other things done in browsers. >> > I believe that the Brave browser uses Mode 4 in its private browsing mo= de. > https://github.com/brave/browser-laptop/issues/260 Interesting, didn't know that and good to see. OTOH, still the vast majority of web browsers will I assume do mode 1 for the vast majority of webrtc calls. So it's a bit of a fig leaf IMO. S. --------------EBD90281B4CD9F27CB978E64 Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------EBD90281B4CD9F27CB978E64-- --O514DXE1GIfIhThtzYWCoBCdqEiH3cwu1-- --CZgbKOGmebh1BFH7z0udtkIZpUYakBqQO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaoGz1AAoJEFqy+vF7FyvqT2AP/2tluplBN0aYfGaao91yYhYx KikaxK431yYTn0PGM4Bq1ZJSqoXDdyLzmGWjdcrCIOOOJMcuuZYB4M9qfo0Il52u V+v5a4bspr/pYC4IBS2EYZCo3pXEzJ/zs7OER4XbXD+IM2R6tyqhcYbDIhKh6fJp ctMg1h9Q1xFBqrzRHL5+JCATcrE9UJtsXTSitWvLBxbuqCrqSDSpwxy8PMuzreab 1P2j5yfVFhqO1DpRYcqpCYGBOSf8C8ksyo1gXtAIZ7T/0jzigOdEOFkpu2/dY2y+ /yqRIYr1fLoPV7RfHgrg+I4/Wl6afAKoFFt6NzwuyrpuGUkTFTz//JSWS70o8Cud SnVK7b3Gk34TFDZAiiKGCD/PZRLzv00rx7f9FEhbMa3XT9PBZlqDYTI1wh462gJD jNebvukmF3sPrPTI+waDko8Y7IuJ8zWheUFrQNkT6jCkUywme27+D+UPyaUDzbNY e1SWAO6ChQzpyl8Bnq8d+2J1BkjcNLOxTKgdl8LXqbcYPMWxE0VRTBLBNMsPE4+Z MCIY1oCleO/AfoztftQx+lNfpLPyEv/5vTyQWm5M9yhJeSDZKvo/D16avjcq4eYz K5yxCyRl82cWnhJlH1N+Nk4DxAM+ZG36wunE8N+PY5wYU8ExjXx5ab/NIZ2bIWIf H/R0WovTm3bB6NcRKGrI =cX3l -----END PGP SIGNATURE----- --CZgbKOGmebh1BFH7z0udtkIZpUYakBqQO-- From nobody Wed Mar 7 15:04:49 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE3A1242F5 for ; Wed, 7 Mar 2018 15:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 oGd9shSCwrEK for ; Wed, 7 Mar 2018 15:04:45 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3466120727 for ; Wed, 7 Mar 2018 15:04:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8EB0CBE5D; Wed, 7 Mar 2018 23:04:43 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pCsvKLsT2G5; Wed, 7 Mar 2018 23:04:39 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8ED07BE5B; Wed, 7 Mar 2018 23:04:39 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1520463879; bh=SSVm+6LnsMLbzr0GrCoEbU3HQdrP6Arx+N8IR4EbE7I=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=x64onNThalJwXnJK9DIvrk9wzQi9hFHZfMgQiR3jsB1N5smXE/T+vZ1dX2po01E+t 0fpB++JFryB7EyUS5yO1vSqMPwD4098eCSmI/zZqP4YeInSQg+HIUQp37oHbBn9Kg3 wgEukVfTIX4+Xo6A7pjq6OeBkHllD8nnE0nZ+WzM= To: Ted Hardie Cc: Justin Uberti , RTCWeb IETF References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: Date: Wed, 7 Mar 2018 23:04:38 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nHS5qQGTDUpXaXutaZrVlXFVdws5QnrYB" Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 23:04:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nHS5qQGTDUpXaXutaZrVlXFVdws5QnrYB Content-Type: multipart/mixed; boundary="t3xUR8BTQJh0hdjZbO0Y2httF0YkKsENb"; protected-headers="v1" From: Stephen Farrell To: Ted Hardie Cc: Justin Uberti , RTCWeb IETF Message-ID: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> In-Reply-To: --t3xUR8BTQJh0hdjZbO0Y2httF0YkKsENb Content-Type: multipart/mixed; boundary="------------950283580F19D78555B183B2" Content-Language: en-GB This is a multi-part message in MIME format. --------------950283580F19D78555B183B2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 07/03/18 22:13, Ted Hardie wrote: > On Wed, Mar 7, 2018 at 1:12 PM, Stephen Farrell > wrote: >=20 >> >> Hiya, >> >> To also be clear: my main objection is to the term consent being >> used at all. The stuff below isn't that big a deal, though would >> change if the WG did drop the idea of "consent" supposedly being >> a real thing. >> >> > So, while I am sympathetic (just generally, really, not just to this), = I > think "consent" is basically a term of art in the web world and that it= s > use in the document is consistent with the more general use. Yes. And there's IMO plenty of reason to not want to be consistent with that general (ab)use. If we start down that road, I worry that we'll end up with the moral equivalent of "you looked at my web-page (possibly whilst ignoring 300 pages of legal crap); therefore you have already agreed to my T&Cs" which'd be an even worse thing if attempted/applied at lower layers. To me, this usage matches that (slightly exaggerated) anti-pattern. > If you know of a different term of art here that would be similarly > well-understood, I would be glad to know of it. =20 Fair point and a fair ask. I'll think some more about it, but TBH, I doubt I could come up with something with a chance of garnering WG consensus. (I don't think this is just terminology btw - I suspect with any better term, the modes defined would also have to change.) If I get inspired, I'll post something. (Hopefully someone smarter than I and with more WebRTC/STUN clue will get there first:-) If I don't, and nobody else does, it's fair to consider me in the rough. Cheers, S. > It may also be an > interesting project to create such a term. But I don't think the docum= ent > should wait on that. >=20 >=20 >=20 >> On 07/03/18 20:47, Justin Uberti wrote: >>> To be clear, the MUST does not say that all interfaces MUST be used i= f >>> consent is given, rather the converse, that you MUST only use all >>> interfaces if there is consent. >> >> It's unclear to me that there's any practical difference there. >> Are there any implementations that do something else? (Apologies >> if that's clear to everyone else:-) >> >>> In addition, while gUM consent is given as an example, it is not >> normative. >>> >>> Mode 1 MUST only be used when user consent has been provided. The= >>> details of this consent are left to the implementation; one potent= ial >>> mechanism is to tie this consent to getUserMedia consent. >> >> Sure. OTOH, IIUC, that is what's done in web browsers so it kind >> of really is normative, in practice. Again, apologies if there >> are other things done in browsers. >> >> If I recall correctly, it was not made normative because mobile > applications might use this using advice outside browser contexts. I c= an't > find an immediate citation to that, though, so it may be a convenient > reconstruction rather than an accurate memory. >=20 > Ted >=20 >=20 >=20 >> S. >> >> >>> >>> >>> >>> On Wed, Mar 7, 2018 at 12:12 PM, Stephen Farrell < >> stephen.farrell@cs.tcd.ie> >>> wrote: >>> >>>> >>>> Hiya, >>>> >>>> On 07/03/18 19:49, Sean Turner wrote: >>>>> All, >>>>> >>>>> This is the WGLC for the "WebRTC IP Address Handling Requirements=E2= =80=9D >>>>> draft available @ >>>>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/. >>>>> Please review the draft and send your comments to this list by >>>>> 2359UTC on 30 March 30 2017. >>>> >>>> I've raised this previously, so this is, I guess, mostly just >>>> for the record, and I'll likely still be in the rough... >>>> >>>> I continue to think it is a bad idea to use the term "consent" >>>> at all, and especially coupled with getUserMedia and with mode >>>> 1 having a MUST for using all interfaces based on what I think >>>> is such a bogus concept. There is, IMO, no valid way in which a >>>> person can fairly be considered to have consented to any of this. >>>> I think entwining IETF specifications in the tangled web of web >>>> "consent" (so called) is going in exactly the wrong direction. >>>> >>>> Cheers, >>>> S. >>>> >>>> >>>>> >>>>> Thanks, C/T/S _______________________________________________ rtcwe= b >>>>> mailing list rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>> >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>>> >>> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >=20 --------------950283580F19D78555B183B2 Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------950283580F19D78555B183B2-- --t3xUR8BTQJh0hdjZbO0Y2httF0YkKsENb-- --nHS5qQGTDUpXaXutaZrVlXFVdws5QnrYB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaoHAHAAoJEFqy+vF7Fyvqab8QALI2NvREDQBCMUWv6xa3ZFn0 CqgPtuV6pnP5fzxQHMDUpV5So66tGuQxsZS2IfNoosYs946OwQiJcjFnZLvX5qIS JefT+8o2I9FwaRkUPsTtn0sxH0Qeorq4A3ZULRfzniL+jdamg9vXY/fnsxcsaAA8 VK+x7D3VwATXEALHDghJ+/u2AGYetsnMXeX+/O6+f9suUnEgLUu1FFfRgBBeglsm fV4NDuBgdoJbE5ajIC+lPXiySPUWTNBvJ2wUH5/5zWt9I4WwVynQrWzVC7eGtksY 235PtlHM6GGOvU92wfI4pT9nxtePGzBySW6gu3+Ywi6ouljFEy2GrQiPZSgGnmMa wjSOBYMkKBloNpEQNArygkO+B8idcwtrNE5BzVTfewg/X41iB3w8PzuM/tGDahVw GHxadhusGbNZal3lNKxdDQMgt3hU/n1AHht4KmEM2Vqti265Jz5i7HwlW3Tb+8YY nlq/Rv+HobjPBOnqAUStoADz7++GFjdYMQG7RXrmwT1TJj3B5yXNcGjQ3HPrlqRR Qvn3fjB/HWCzy2P8yZsFoVKYLEsxkM8auwwdhzY8FfG9Xs98FWOc2CdnbJA3QyFU P8otRRubNBsG4UXScokFwieqFK2a8QMi/KGodfEjkoBK1++QkjAsWtdfKw4IQhDc EjSeaC+/txu96XJQfRjQ =IttL -----END PGP SIGNATURE----- --nHS5qQGTDUpXaXutaZrVlXFVdws5QnrYB-- From nobody Mon Mar 12 15:49:54 2018 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67BFD12422F; Mon, 12 Mar 2018 15:49:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.75.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152089498736.4653.9496698416339786973@ietfa.amsl.com> Date: Mon, 12 Mar 2018 15:49:47 -0700 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-arch-14.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 22:49:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers WG of the IETF. Title : WebRTC Security Architecture Author : Eric Rescorla Filename : draft-ietf-rtcweb-security-arch-14.txt Pages : 39 Date : 2018-03-12 Abstract: This document defines the security architecture for WebRTC, a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-14 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-security-arch-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-security-arch-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 12 16:08:12 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498CE1270AE for ; Mon, 12 Mar 2018 16:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 TJE8eHgHKOZX for ; Mon, 12 Mar 2018 16:08:09 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 AACF112704A for ; Mon, 12 Mar 2018 16:08:09 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id q13so5037648pff.0 for ; Mon, 12 Mar 2018 16:08:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=ApnCI6CfJK5Sm1LY3QQYrIDfRAktacmtMYVldvZ3fKs=; b=lPjHUi9MvgqpsZo/3jZdB6ckXJFaazTsYayJLrB7dulHFMAnSzM7yCjtWamGRRu5XJ DJ6Y5/eY/Po5r205i2wMRAfhOCpCXDBZMBUIG6AbFvy8X2PtTxNHh9AHuAUKuyh9njhT Ei4kboXVZ8/9Krrk3NpkZYpVTIEhG0Z9VIVFM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=ApnCI6CfJK5Sm1LY3QQYrIDfRAktacmtMYVldvZ3fKs=; b=kugSzb2lHkgyLGvkyTUTy4yuY8zWLeWhJaN1pq3cjMkqeGuQFTfOuEz8tlaWrxs2Ww WipKtWc5rXrVfl/o/Ui6uIDIluWmM7wq9X9Z0I87MNt4Wireca+lsnYVU1QqmJqTRBaK pwoz/ZNFA6ZydZOfkEo41wxm4BYXPFmYMMrvQ+TkyPczN0pTCuR+AbJ1+pGkPMjcsvAG WVIzQDQejTIyIlCoytF+mFxRyrUSWitvB0psvgPmrxlApsTqtR6pD2pjfMFYRvDOrn0k ZJu0u371Vb5iuhfu1AaF6S5UzFlm75NCDBylniotceaHDq15AMeeHbGrLD/85uI/8e8A +YlQ== X-Gm-Message-State: AElRT7FhTHaAA2BL8tZPTkEaNxLYX5LTXPYS2IdbJRK75fKsLcAWZE8+ tQE48jCEpQrwc9eG8BmSkWvhchJfceE= X-Google-Smtp-Source: AG47ELtcwRi6Mi16JKRo+FDWPNM6YwRsEe0xpEESel/c01pM/KRGluXXgw/+bM7yQrYgDXQW/vQ1hQ== X-Received: by 10.98.107.134 with SMTP id g128mr5277718pfc.238.1520896089085; Mon, 12 Mar 2018 16:08:09 -0700 (PDT) Received: from [5.5.33.141] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id j185sm15813348pgc.79.2018.03.12.16.08.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Mar 2018 16:08:08 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: Date: Mon, 12 Mar 2018 23:08:02 +0000 To: RTCWeb IETF X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [rtcweb] WGLC for draft-ietf-rtcweb-security-arch X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 23:08:11 -0000 All, This is the WGLC for the =E2=80=9CWebRTC Security Architecture=E2=80=9D = draft available @ = https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/. Please = review the draft and send your comments to this list by 2359UTC on April = 6th, 2018. Note the gh repo is here: https://github.com/rtcweb-wg/security-arch Thanks, C/T/S= From nobody Tue Mar 13 07:14:27 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD03127444 for ; Tue, 13 Mar 2018 07:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Rc73QbxhKxOZ for ; Tue, 13 Mar 2018 07:14:25 -0700 (PDT) Received: from smtp89.ord1d.emailsrvr.com (smtp89.ord1d.emailsrvr.com [184.106.54.89]) (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 C6030124B0A for ; Tue, 13 Mar 2018 07:14:25 -0700 (PDT) Received: from smtp20.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp20.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id 05E38C0065; Tue, 13 Mar 2018 10:14:25 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp20.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id BF030C0098; Tue, 13 Mar 2018 10:14:24 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Tue, 13 Mar 2018 10:14:25 -0400 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 13 Mar 2018 08:14:23 -0600 Message-Id: <2C22A535-0F8D-496D-B8BF-C74ACB17958C@iii.ca> To: WebRTC WG , RTCWeb IETF X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [rtcweb] WebRTC REF for OAUTH based TURN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 14:14:27 -0000 =46rom a dependency point of view, I would like to note that right now = the WebRTC PC spec references * draft-ietf-oauth-pop-key-distribution Which rumor has it has been replaced by=20 * datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz Which normatively references the following: * draft-ietf-ace-cbor-web-token * ietf-ace-cwt-proof-of-possession * draft-ietf-ace-cbor-web-token * draft-ietf-ace-cwt-proof-of-possession More discussion of this at https://github.com/w3c/webrtc-pc/issues/1642 What needs to happen with all this so we can finish up the stuff WebRTC = needs to reference from IETF ? From nobody Tue Mar 13 10:53:58 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7F31271FD for ; Tue, 13 Mar 2018 10:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 yG-4Vkr8X3k0 for ; Tue, 13 Mar 2018 10:53:56 -0700 (PDT) Received: from mail-pl0-x22c.google.com (mail-pl0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) (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 EA296124C27 for ; Tue, 13 Mar 2018 10:53:55 -0700 (PDT) Received: by mail-pl0-x22c.google.com with SMTP id ay1-v6so239314plb.7 for ; Tue, 13 Mar 2018 10:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PFy5f8dBu9xjKPYVh3DVNZhCldidt4MwQXKVCzzsmic=; b=fr2DYQsFsu1NxvvW1P/T03AmGuevkZQzJr7J+m6aujpwhj6Qxvhe/gt7XlWdM/xBk+ zqRxJbsJcyw9wUQvwNnmiHDe/KI1LXWKzORJSoiBnUqreg1QXTpNLj3CXwCZ7dMo/Xyv U1/fkUWp2VMRXjnLGIwBmY1mtCBCZazSVCvJc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PFy5f8dBu9xjKPYVh3DVNZhCldidt4MwQXKVCzzsmic=; b=q766XuHMGt/50aJGGmo8dUeWAQK7vzd42x/dBXfyzumOH3WMxLLVEy2m8MdvxtT0Je aa6mz9VOL5CGhX9Nj4qkWy1O3Ol9tI2E1RySDEDbG/NXkUnmTKhkJprjWkFf6CUNaGNP jtG96HPUhHYkko6kZ8QQdXUlxYQiC9PDB+3qz6bbZauwc3W2VLt5Y2W0sajBOS3aGtoJ NpU5wgh65zPX/NGAcllblEsJ7fMPk133sdeChNVhEQ128t2GAd24E9F8NBOXRCf9axD6 W59MMD77XyBLEW/RYUu/ifJOpalGCyoAAFZscbvohIO2PKpr5K4g02OuOr5pT+wWVj2U Xr7g== X-Gm-Message-State: AElRT7HBQM3mC4xkpCDAeHYQ8QhEdm7RAwVk3NI4ieXHrkPSQS4oYFIP mtDqX5IAYn6JDB0iSEM3He3lcQ== X-Google-Smtp-Source: AG47ELurrnDuQx5IMjViSkOKCt7pjOSaaZ7B+MIK/vBroqp+OH3ggMSZg9bz8mAg2dbCTtkBsCIS4g== X-Received: by 2002:a17:902:7883:: with SMTP id q3-v6mr1262176pll.361.1520963635579; Tue, 13 Mar 2018 10:53:55 -0700 (PDT) Received: from [5.5.33.141] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id h26sm1176337pgv.22.2018.03.13.10.53.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 10:53:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: <2C22A535-0F8D-496D-B8BF-C74ACB17958C@iii.ca> Date: Tue, 13 Mar 2018 17:53:47 +0000 Cc: WebRTC WG , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <500B1FA0-26D7-4DE5-9DC3-0180A1CA24C7@sn3rd.com> References: <2C22A535-0F8D-496D-B8BF-C74ACB17958C@iii.ca> To: Cullen Jennings X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [rtcweb] WebRTC REF for OAUTH based TURN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 17:53:57 -0000 I believe that draft-ietf-oauth-pop-key-distribution morphed into: draft-ietf-ace-cwt-proof-of-possession/ I will double check with the ace chairs. There is one downref to draft-ietf-ace-cbor-web-token, but it=E2=80=99s = state is now "Approved-announcement to be sent::Revised I-D Needed for 5 = days=E2=80=9D spt > On Mar 13, 2018, at 14:14, Cullen Jennings wrote: >=20 >=20 > =46rom a dependency point of view, I would like to note that right now = the WebRTC PC spec references >=20 > * draft-ietf-oauth-pop-key-distribution >=20 > Which rumor has it has been replaced by=20 >=20 > * datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz >=20 > Which normatively references the following: >=20 > * draft-ietf-ace-cbor-web-token > * ietf-ace-cwt-proof-of-possession > * draft-ietf-ace-cbor-web-token > * draft-ietf-ace-cwt-proof-of-possession >=20 > More discussion of this at = https://github.com/w3c/webrtc-pc/issues/1642 >=20 > What needs to happen with all this so we can finish up the stuff = WebRTC needs to reference from IETF ? >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Mar 14 00:37:40 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A977D126BF6 for ; Wed, 14 Mar 2018 00:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 za9UOrNUU0YX for ; Wed, 14 Mar 2018 00:37:36 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28C221200C5 for ; Wed, 14 Mar 2018 00:37:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 15B9D7C0CF3; Wed, 14 Mar 2018 08:37:34 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8BqPUdw1L1t; Wed, 14 Mar 2018 08:37:31 +0100 (CET) Received: from [192.168.3.17] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id BBFE27C0CC5; Wed, 14 Mar 2018 08:37:31 +0100 (CET) To: Cullen Jennings , WebRTC WG , RTCWeb IETF References: <2C22A535-0F8D-496D-B8BF-C74ACB17958C@iii.ca> From: Harald Alvestrand Message-ID: Date: Wed, 14 Mar 2018 08:37:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <2C22A535-0F8D-496D-B8BF-C74ACB17958C@iii.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] WebRTC REF for OAUTH based TURN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 07:37:39 -0000 Den 13. mars 2018 15:14, skrev Cullen Jennings: > > From a dependency point of view, I would like to note that right now the WebRTC PC spec references > > * draft-ietf-oauth-pop-key-distribution > > Which rumor has it has been replaced by > > * datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz > > Which normatively references the following: > > * draft-ietf-ace-cbor-web-token > * ietf-ace-cwt-proof-of-possession > * draft-ietf-ace-cbor-web-token > * draft-ietf-ace-cwt-proof-of-possession > > More discussion of this at https://github.com/w3c/webrtc-pc/issues/1642 > > What needs to happen with all this so we can finish up the stuff WebRTC needs to reference from IETF ? > > > > > >From a WG product management point of view, I consider that this has not deployed, and is not likely to deploy in the present timeframe, given that no consensus specifiation has emerged. My suggestion would be to replace this text: An OAuth 2.0 based authentication method, as described in [RFC7635]. It uses the OAuth 2.0 Implicit Grant type, with PoP (Proof-of-Possession) Token type, as described in [RFC6749] and [OAUTH-POP-KEY-DISTRIBUTION]. .... rest of section .... with An OAuth 2.0 based authentication method, as described in [RFC7635]. The amount of detail currently in the webrtc-pc document is, to my mind, inappropriate for a W3C spec. If the IETF has failed to come up with a single "handle" by which all this detail can be referenced, the IETF needs to solve that problem. From nobody Wed Mar 14 02:33:31 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E0F127871 for ; Wed, 14 Mar 2018 02:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 vANDzrSi0xyw for ; Wed, 14 Mar 2018 02:33:28 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 3B92D127077 for ; Wed, 14 Mar 2018 02:33:28 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id h11so1153539pfn.4 for ; Wed, 14 Mar 2018 02:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YnuZNccZM5SsFSjU4fg2fB0i7V7Y3WsTadAb9yn7UBU=; b=bnAhT9QxyRRsQB/Y14MADKUTm6qj+GfzzBbov7e91FPXM77la/OEKbL0vNjM0I2LiJ SoLm2eNxrW6+phbxR3i74Q8qMDDWFa1JQFL3W4hUlaklRf4H6Iwf4tO3kfXELSIJvxlW G5BRCtuKFT/1F9vBGsH+v06KZI5+J00yKvpZs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YnuZNccZM5SsFSjU4fg2fB0i7V7Y3WsTadAb9yn7UBU=; b=QjKimADWIx4q/x7lzXht4Hed91HqO2AGfEfBT3cm+FWDjRugu9j9r+7anlA5mFYTyC AlT1FMvQUCtSEfcXRmvWF8tjlHwidxEG22dGT8RFugx/PbmHUKvl87+NQIL3Qhme3kAp Yvzs80s1lIVVzx829itdW8rJjVK/P7EuaY0QXLL+dRQWHUXsQin0co/KBCrUfxV3jSwm 9TlImuDbkLxdNlViCRhSZSOMnIF5f1uWIXmlilpvw91HxwocdXlb95/zl+kv2KYhGpko NEHFhBgiMiA/E3+deSXpULbfOvEhsMkAQTQt3VewE1Hrw2N8Upf0YIImISsYzAJgsdwd i1dA== X-Gm-Message-State: AElRT7G+4Dp6Dmrbef6AnZ2oHrnDCP07cqx0e7GOYLFaoobSZEhHP7ZW R9tsPK/RdqxVgOBUDgYqJrg+zAPrIOg= X-Google-Smtp-Source: AG47ELulpGvelv2+x/Evn3R7OCiCp+wUW9xxf7+EC56+aq8ccyTYT5in9yA8yJSVHuezpZ29pFE/5Q== X-Received: by 10.101.77.195 with SMTP id q3mr3040301pgt.283.1521020007812; Wed, 14 Mar 2018 02:33:27 -0700 (PDT) Received: from [5.5.33.158] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id w88sm4549598pfa.50.2018.03.14.02.33.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Mar 2018 02:33:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: Date: Wed, 14 Mar 2018 09:33:20 +0000 Cc: Cullen Jennings , WebRTC WG , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <2C22A535-0F8D-496D-B8BF-C74ACB17958C@iii.ca> To: Harald Tveit Alvestrand X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [rtcweb] WebRTC REF for OAUTH based TURN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 09:33:30 -0000 > On Mar 14, 2018, at 07:37, Harald Alvestrand = wrote: >=20 > Den 13. mars 2018 15:14, skrev Cullen Jennings: >>=20 >> =46rom a dependency point of view, I would like to note that right = now the WebRTC PC spec references >>=20 >> * draft-ietf-oauth-pop-key-distribution >>=20 >> Which rumor has it has been replaced by=20 >>=20 >> * datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz >>=20 >> Which normatively references the following: >>=20 >> * draft-ietf-ace-cbor-web-token >> * ietf-ace-cwt-proof-of-possession >> * draft-ietf-ace-cbor-web-token >> * draft-ietf-ace-cwt-proof-of-possession >>=20 >> More discussion of this at = https://github.com/w3c/webrtc-pc/issues/1642 >>=20 >> What needs to happen with all this so we can finish up the stuff = WebRTC needs to reference from IETF ? >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >> =46rom a WG product management point of view, I consider that this = has not > deployed, and is not likely to deploy in the present timeframe, given > that no consensus specifiation has emerged. >=20 > My suggestion would be to replace this text: >=20 > An OAuth 2.0 based authentication method, as described in [RFC7635]. = It > uses the OAuth 2.0 Implicit Grant type, with PoP (Proof-of-Possession) > Token type, as described in [RFC6749] and = [OAUTH-POP-KEY-DISTRIBUTION]. > .... rest of section .... >=20 > with >=20 > An OAuth 2.0 based authentication method, as described in [RFC7635]. >=20 > The amount of detail currently in the webrtc-pc document is, to my = mind, > inappropriate for a W3C spec. If the IETF has failed to come up with a > single "handle" by which all this detail can be referenced, the IETF > needs to solve that problem. This seems to be like the right approach. spt= From nobody Wed Mar 14 02:59:58 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89F9128954 for ; Wed, 14 Mar 2018 02:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 J5hlo9umtQ6Z for ; Wed, 14 Mar 2018 02:59:55 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (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 60B8A127909 for ; Wed, 14 Mar 2018 02:59:55 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id r26so1133900pgv.13 for ; Wed, 14 Mar 2018 02:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U98+SJqjrr9dg9/fIMelX2ayO0wPzcnsPmx1VPEFxk0=; b=gPWwNA4pmtWghknPwq+xclfZLdx6cAxKu3FmKDwMUmtk7aTPyqhsSC8VACAUxbgss6 wu/1nVCGPXkwKgQ4gT1bqcoh8z+lZWMvp1fNtWik01N5mY3DthttC7mEx3RI2+Vom6+7 T0NGoupKP/QYCqv5/0lPAaPXlTVTBvwOu8VCQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U98+SJqjrr9dg9/fIMelX2ayO0wPzcnsPmx1VPEFxk0=; b=UEiaGw+oPh28jLL6tH3Y5l3O7ebyEoI+ILjRCiqbhPIvnDlYI7+BYBTfb2hTfR0kiv jep1i1fn90XG7COlWyqVuP7TiP/Xs2lWHrQWOHXqqBZRrFly482QExmTCM5Ta2c0rDIw ThtrXejS/NFYqCgOy5jH2TT2ZOSz6QC4bO7sbqTvYIOFydGnbCcr2x0axzw8gzpclg11 wIoZkGKe/AXZ+1AhdNES4Dtk4a/0B0L5Mder9g+4PqRvNXjxUw/9PvOlLBGdEQ1vIZN3 sxAbGOoJNyHBqxvojPTZeSAWwaSdPyeCg/vp2iNbOfzPKzdAVErRrgZ5x5v9d1cHNmZ/ O0aQ== X-Gm-Message-State: AElRT7E+L9uBFuRapQxqE4ic2uQ2iZ6r67P1J2gvfPMs8m+Kv8qU7Fdu kajpFxQDhpv5B6ALMOlufLyigA== X-Google-Smtp-Source: AG47ELt6OM2JhlgkTbS7lv7FSiuxAy81brCtipbGrvy0pdyrcO5xZzCVYgKQR1MViGxw2jv7knyTNg== X-Received: by 10.167.129.24 with SMTP id b24mr3678765pfi.183.1521021594732; Wed, 14 Mar 2018 02:59:54 -0700 (PDT) Received: from [5.5.33.158] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id r30sm4769713pff.7.2018.03.14.02.59.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Mar 2018 02:59:53 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: Date: Wed, 14 Mar 2018 09:59:46 +0000 Cc: Cullen Jennings , WebRTC WG , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <1A1A6CB8-A85A-431C-8BD0-CB80B51E002D@sn3rd.com> References: <2C22A535-0F8D-496D-B8BF-C74ACB17958C@iii.ca> To: Harald Tveit Alvestrand X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [rtcweb] WebRTC REF for OAUTH based TURN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 09:59:57 -0000 > On Mar 14, 2018, at 09:33, Sean Turner wrote: >=20 >=20 >=20 >> On Mar 14, 2018, at 07:37, Harald Alvestrand = wrote: >>=20 >> Den 13. mars 2018 15:14, skrev Cullen Jennings: >>>=20 >>> =46rom a dependency point of view, I would like to note that right = now the WebRTC PC spec references >>>=20 >>> * draft-ietf-oauth-pop-key-distribution >>>=20 >>> Which rumor has it has been replaced by=20 >>>=20 >>> * datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz >>>=20 >>> Which normatively references the following: >>>=20 >>> * draft-ietf-ace-cbor-web-token >>> * ietf-ace-cwt-proof-of-possession >>> * draft-ietf-ace-cbor-web-token >>> * draft-ietf-ace-cwt-proof-of-possession >>>=20 >>> More discussion of this at = https://github.com/w3c/webrtc-pc/issues/1642 >>>=20 >>> What needs to happen with all this so we can finish up the stuff = WebRTC needs to reference from IETF ? >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>> =46rom a WG product management point of view, I consider that this = has not >> deployed, and is not likely to deploy in the present timeframe, given >> that no consensus specifiation has emerged. >>=20 >> My suggestion would be to replace this text: >>=20 >> An OAuth 2.0 based authentication method, as described in [RFC7635]. = It >> uses the OAuth 2.0 Implicit Grant type, with PoP = (Proof-of-Possession) >> Token type, as described in [RFC6749] and = [OAUTH-POP-KEY-DISTRIBUTION]. >> .... rest of section .... >>=20 >> with >>=20 >> An OAuth 2.0 based authentication method, as described in [RFC7635]. >>=20 >> The amount of detail currently in the webrtc-pc document is, to my = mind, >> inappropriate for a W3C spec. If the IETF has failed to come up with = a >> single "handle" by which all this detail can be referenced, the IETF >> needs to solve that problem. >=20 > This seems to be like the right approach. >=20 For more info: draft-ietf-ace-oauth-authz Says: COSE is used to secure self-contained tokens such as proof-of-possession (PoP) tokens, which is an extension to the OAuth tokens. The default token format is defined in CBOR web token (CWT) [I-D.ietf-ace-cbor-web-token]. ace-cbor-web-token is in Approved-announcement to be sent::Revised I-D = Needed for 6 days with no DOWNREF.. spt= From nobody Wed Mar 14 08:05:36 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D363A126C19 for ; Wed, 14 Mar 2018 08:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.363 X-Spam-Level: X-Spam-Status: No, score=0.363 tagged_above=-999 required=5 tests=[RDNS_DYNAMIC=0.363] autolearn=no 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 KN8tLSfMlkFv for ; Wed, 14 Mar 2018 08:05:31 -0700 (PDT) Received: from odu.duckdns.org (business-178-48-31-65.business.broadband.hu [178.48.31.65]) (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 A61411200B9 for ; Wed, 14 Mar 2018 08:05:31 -0700 (PDT) Received: from alma.ki.iif.hu ([193.6.222.35]) by odu.duckdns.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ew7y1-000593-Bb; Wed, 14 Mar 2018 16:05:25 +0100 To: Harald Alvestrand , Cullen Jennings , WebRTC WG , RTCWeb IETF References: <2C22A535-0F8D-496D-B8BF-C74ACB17958C@iii.ca> From: =?UTF-8?B?TcOpc3rDoXJvcyBNaWjDoWx5?= Message-ID: Date: Wed, 14 Mar 2018 16:05:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB Archived-At: Subject: Re: [rtcweb] WebRTC REF for OAUTH based TURN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 15:05:33 -0000 2018-03-14 08:37 keltez=C3=A9ssel, Harald Alvestrand =C3=ADrta: > Den 13. mars 2018 15:14, skrev Cullen Jennings: >> From a dependency point of view, I would like to note that right now t= he WebRTC PC spec references >> >> * draft-ietf-oauth-pop-key-distribution >> >> Which rumor has it has been replaced by=20 >> >> * datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz >> >> Which normatively references the following: >> >> * draft-ietf-ace-cbor-web-token >> * ietf-ace-cwt-proof-of-possession >> * draft-ietf-ace-cbor-web-token >> * draft-ietf-ace-cwt-proof-of-possession >> >> More discussion of this at https://github.com/w3c/webrtc-pc/issues/164= 2 >> >> What needs to happen with all this so we can finish up the stuff WebRT= C needs to reference from IETF ? >> >> >> >> >> > >From a WG product management point of view, I consider that this has n= ot > deployed, and is not likely to deploy in the present timeframe, given > that no consensus specifiation has emerged. > > My suggestion would be to replace this text: > > An OAuth 2.0 based authentication method, as described in [RFC7635]. It= > uses the OAuth 2.0 Implicit Grant type, with PoP (Proof-of-Possession) > Token type, as described in [RFC6749] and [OAUTH-POP-KEY-DISTRIBUTION].= > .... rest of section .... > > with > > An OAuth 2.0 based authentication method, as described in [RFC7635]. > > The amount of detail currently in the webrtc-pc document is, to my mind= , > inappropriate for a W3C spec. If the IETF has failed to come up with a > single "handle" by which all this detail can be referenced, the IETF > needs to solve that problem. > After the confusion around RTCIceCredential OAuth parameters in WebRTC-PC, I just want to close the gap between W3C WebRTC-PC and IETF RFC7635. RFC7635 is complex and confusing without a guide. My intention was to remove confusion and define an example guideline howto use RFC7635 in WebRTC context, and put all this info into the WebRTC-PC spec. Now I see I went too far, and PC spec should step back and mention OAuth PoP only as a possible way of the key distribution, but in other hand the information in webrtc PC is inline with the RFC7635 example Appendix = B. Is it better to leave totally undefined howto use RFC7635 in WebRTC context as Harald proposed? I am not sure. Misi From nobody Wed Mar 14 09:46:57 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75DA12D77A for ; Wed, 14 Mar 2018 09:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 c7iISS8xJsKN for ; Wed, 14 Mar 2018 09:46:53 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8865127337 for ; Wed, 14 Mar 2018 09:46:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id D9EEB7C392A; Wed, 14 Mar 2018 17:46:50 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LltAydUmx35W; Wed, 14 Mar 2018 17:46:50 +0100 (CET) Received: from [192.168.3.17] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id E03957C371A; Wed, 14 Mar 2018 17:46:49 +0100 (CET) To: =?UTF-8?B?TcOpc3rDoXJvcyBNaWjDoWx5?= , Cullen Jennings , WebRTC WG , RTCWeb IETF References: <2C22A535-0F8D-496D-B8BF-C74ACB17958C@iii.ca> From: Harald Alvestrand Message-ID: Date: Wed, 14 Mar 2018 17:46:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] WebRTC REF for OAUTH based TURN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 16:46:56 -0000 Den 14. mars 2018 16:05, skrev Mészáros Mihály: > > > 2018-03-14 08:37 keltezéssel, Harald Alvestrand írta: >> Den 13. mars 2018 15:14, skrev Cullen Jennings: >>> From a dependency point of view, I would like to note that right now the WebRTC PC spec references >>> >>> * draft-ietf-oauth-pop-key-distribution >>> >>> Which rumor has it has been replaced by >>> >>> * datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz >>> >>> Which normatively references the following: >>> >>> * draft-ietf-ace-cbor-web-token >>> * ietf-ace-cwt-proof-of-possession >>> * draft-ietf-ace-cbor-web-token >>> * draft-ietf-ace-cwt-proof-of-possession >>> >>> More discussion of this at https://github.com/w3c/webrtc-pc/issues/1642 >>> >>> What needs to happen with all this so we can finish up the stuff WebRTC needs to reference from IETF ? >>> >>> >>> >>> >>> >> >From a WG product management point of view, I consider that this has not >> deployed, and is not likely to deploy in the present timeframe, given >> that no consensus specifiation has emerged. >> >> My suggestion would be to replace this text: >> >> An OAuth 2.0 based authentication method, as described in [RFC7635]. It >> uses the OAuth 2.0 Implicit Grant type, with PoP (Proof-of-Possession) >> Token type, as described in [RFC6749] and [OAUTH-POP-KEY-DISTRIBUTION]. >> .... rest of section .... >> >> with >> >> An OAuth 2.0 based authentication method, as described in [RFC7635]. >> >> The amount of detail currently in the webrtc-pc document is, to my mind, >> inappropriate for a W3C spec. If the IETF has failed to come up with a >> single "handle" by which all this detail can be referenced, the IETF >> needs to solve that problem. >> > After the confusion around RTCIceCredential OAuth parameters in > WebRTC-PC, I just want to close the gap between W3C WebRTC-PC and IETF > RFC7635. > RFC7635 is complex and confusing without a guide. > My intention was to remove confusion and define an example guideline > howto use RFC7635 in WebRTC context, and put all this info into the > WebRTC-PC spec. > > Now I see I went too far, and PC spec should step back and mention OAuth > PoP only as a possible way of the key distribution, but in other hand > the information in webrtc PC is inline with the RFC7635 example Appendix B. > > Is it better to leave totally undefined howto use RFC7635 in WebRTC > context as Harald proposed? > I am not sure. I think it would be better to publish an IETF document that describes "one clear way to do it", and see if we can get interoperable implementations of that. Then we can insert a reference to that in the WebRTC spec when it's ready. The current text is unimplementable because it refers to documents that don't exist (formally) any more, which is an untenable situation. Harald From nobody Fri Mar 16 04:39:20 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416851200C5 for ; Fri, 16 Mar 2018 04:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 A10GaXa84oe5 for ; Fri, 16 Mar 2018 04:39:17 -0700 (PDT) Received: from smtp121.ord1d.emailsrvr.com (smtp121.ord1d.emailsrvr.com [184.106.54.121]) (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 DE07B127077 for ; Fri, 16 Mar 2018 04:39:17 -0700 (PDT) Received: from smtp24.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp24.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id 388D4A0077; Fri, 16 Mar 2018 07:39:17 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp24.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id C2503A006A; Fri, 16 Mar 2018 07:39:16 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.61.214.50] ([UNAVAILABLE]. [173.38.220.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:25 (trex/5.7.12); Fri, 16 Mar 2018 07:39:17 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <4de127a2-2936-0022-34af-614129ea105f@alvestrand.no> Date: Fri, 16 Mar 2018 11:39:18 +0000 Cc: RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B663EB9-52D3-4069-A31C-03D6D0BB38BB@iii.ca> <4de127a2-2936-0022-34af-614129ea105f@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [rtcweb] Getting rid of SDP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 11:39:19 -0000 > On Mar 6, 2018, at 6:39 AM, Harald Alvestrand = wrote: >=20 > Nice to see that you too are arguing that we should get rid of SDP's > design errors! >=20 > There are of course design errors (I think) in the proposal you made = too > (the most glaring one is that you tie sources to clients - in order to > be generic building tools, sources need global IDs - otherwise we = can't > build distribution trees for Baumgartner's parachute jump from space > using the same technology as chatting with Grandma). 128-bit random > numbers are lovely global identifiers. (This is the same error that = went > into the original design of the http URL - tying location with = identity. > But I digress.) Totally agree we need a 128 bit integer that is globally unique for the = source. I was thinking that the hash of the concatenation of = conferenceID, endpointID, sourceID would be that. So this may be = somewhat just a terminology issue.=20 >=20 > I'd also like to have a security story that hangs together - each = layer > has unique security properties that it needs to make sure are > satisfiable - from the neeed to not make DDOS simple at the network > layer to the assurance that I'm talking to Grandma and not some > CGI-generated scammer-face at the application layer. We've so far = failed > to have a security story in WebRTC that is both comprehensive and > attractive to deploy - I'd like to see us do better next time around. Makes sense. Do you have thoughts on some particular security problems = that we should be able to solve and either currently don't solve or = solve in a way that is painful to use? >=20 > I'm a little bit hesitant to ask this, but .... should we go back and > look at what use cases we plan to solve in this Grand Unified Scheme = of > Things? >=20 This draft was way lacking in goals of what it was trying to fix. I = think we need to be clear about what we are trying to accomplish that we = can't already do so good to get input on that.=20 From nobody Fri Mar 16 04:40:59 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69F31277BB for ; Fri, 16 Mar 2018 04:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ys8nTdGnBfa2 for ; Fri, 16 Mar 2018 04:40:52 -0700 (PDT) Received: from smtp81.iad3a.emailsrvr.com (smtp81.iad3a.emailsrvr.com [173.203.187.81]) (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 A54AA1200C5 for ; Fri, 16 Mar 2018 04:40:52 -0700 (PDT) Received: from smtp19.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp19.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id AD07F51D2; Fri, 16 Mar 2018 07:40:51 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp19.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 3C28851FC; Fri, 16 Mar 2018 07:40:51 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.61.214.50] ([UNAVAILABLE]. [173.38.220.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Fri, 16 Mar 2018 07:40:51 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_569DEDC3-2830-4BED-B311-6A71DC542F18" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Fri, 16 Mar 2018 11:40:52 +0000 Cc: Harald Alvestrand , RTCWeb IETF Message-Id: References: <3B663EB9-52D3-4069-A31C-03D6D0BB38BB@iii.ca> <4de127a2-2936-0022-34af-614129ea105f@alvestrand.no> To: Silvia Pfeiffer X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [rtcweb] Getting rid of SDP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 11:40:56 -0000 --Apple-Mail=_569DEDC3-2830-4BED-B311-6A71DC542F18 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 6, 2018, at 7:01 AM, Silvia Pfeiffer = wrote: >=20 > Yes, please, let's make a list of the use cases and the problems. > Otherwise it feels like we're re-inventing technology for technology's > sake. Totally agree, I will drive some of the goals into the next version.=20= --Apple-Mail=_569DEDC3-2830-4BED-B311-6A71DC542F18 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Mar 6, 2018, at 7:01 AM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:

Yes, please, let's make a list of the use cases = and the problems.
Otherwise it feels like we're re-inventing = technology for technology's
sake.

Totally agree,  I will drive some = of the goals into the next version. 
= --Apple-Mail=_569DEDC3-2830-4BED-B311-6A71DC542F18-- From nobody Fri Mar 16 06:35:49 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE64D128959 for ; Fri, 16 Mar 2018 06:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 DeqoBm5RR0N3 for ; Fri, 16 Mar 2018 06:35:46 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) (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 4A172126CD8 for ; Fri, 16 Mar 2018 06:35:45 -0700 (PDT) Received: (qmail 76307 invoked from network); 16 Mar 2018 13:35:43 -0000 X-APM-Authkey: 255286/0(159927/0) 1060 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 16 Mar 2018 13:35:43 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id CC43B18A056C; Fri, 16 Mar 2018 13:35:43 +0000 (GMT) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id dV2KTG2GFMe1; Fri, 16 Mar 2018 13:35:43 +0000 (GMT) Received: from phage-rock.fritz.box (p5B28C54E.dip0.t-ipconnect.de [91.40.197.78]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 802BA18A02B2; Fri, 16 Mar 2018 13:35:43 +0000 (GMT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: westhawk In-Reply-To: Date: Fri, 16 Mar 2018 14:35:42 +0100 Cc: Peter Thatcher , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B663EB9-52D3-4069-A31C-03D6D0BB38BB@iii.ca> <4de127a2-2936-0022-34af-614129ea105f@alvestrand.no> To: Justin Uberti X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [rtcweb] Getting rid of SDP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 13:35:49 -0000 > On 6 Mar 2018, at 20:34, Justin Uberti wrote: >=20 > I agree with Peter; we also have input from Sergio's developer survey = that indicates a supermajority of WebRTC developers want lower-level = APIs. >=20 > One notable aspect of Cullen's proposal is that it aims to replace = basically everything all at once, when several of the individual pieces = could be considered separately (e.g. Snowflake, = media-transport-over-QUIC). Even if we don't think it makes sense to = pursue all these pieces, we should be able to find common ground on a = couple pieces for WebRTC v2. Cullen=E2=80=99s =E2=80=98quixotic' proposal we could call it :-)=20 Another input we should be putting into this process are the proposals = that were rejected first time around on grounds that seem less valid than they did. We are already incorporating much from the skype/ms proposal that became = ORTC. I think we should look again at what was in the adobe RTMFP based = proposal to see if (for instance) the way it does identity is worth replicating. I=E2=80=99d also like us to take a second look at IAX2 - specifically = the way it obviates ICE.=20 (basically setting up a connection via a known good intermediary e.g. a = TURN server, then whilst that is up=20 probing other possible paths, then flipping over when one of them comes = good). We also need to make a clear stand on legacy interop - much of the = complexity we got into is (IMHO) due to us not knowing what was a consistent level of legacy = support. Tim. From nobody Fri Mar 16 16:59:25 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD181243F3 for ; Fri, 16 Mar 2018 16:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 a9c6axrT1Wav for ; Fri, 16 Mar 2018 16:59:22 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (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 CFA87120725 for ; Fri, 16 Mar 2018 16:59:21 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id c24so1345492wrc.6 for ; Fri, 16 Mar 2018 16:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fQqDxLeH4KE1Qx9kkny/nzXpUdccg2/oRsEW3vGjSLU=; b=SredCdfay2N6tyeyrwZ36ZggiPuRh86Jn1nqWaOLc6vYeg2wH99qrtv20BfwabUCKg lJEx/WFF/dKYGhBINmboKFqYZlW2MZfrSTIyWBjqRtOTIuIASMzKHoxDeaOWDLBtQDLZ pq8cMD2JIOBRUy+q8lKA8FNnD+P4wi2N9qy984tXLF3CFaa/y9syCG20nzQx1DUC0ttJ uBL9tV0vcU4DHDR8pngm2+AzMHJCXFO1iUVFZ35KeF3J+QrJcCkfpHg/nUjN3Jf+7Zte GOpNYMk+xKhHQ7ZxkjIyUrhL0cDteQBHiIbEb7BDpvn8ltSSzukTsqBUVIQ/kNZXaSJi Tnsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fQqDxLeH4KE1Qx9kkny/nzXpUdccg2/oRsEW3vGjSLU=; b=Azv6R7tjiAMBaCiQyTCnOIPenPy4pM/L+6gq0m2NzOLU9gZz5MDg57mT/Ogl4EiYw/ Hp6YA1Htyfj7WsrXzbZ6j12XeKWp9jEPUMTD005wl/pxFDvrDfCnclAqducl4PQhn7DN DDxXwYVPn3lHtOLRhpZ3jQkTvumVSHH4tW0s2laCMgyI0aMK+o3qVFlU8BaXImrvUhdV Xk8RnOIP6NLuLE4OqodiNCPGjueMsacphDzkvyXdNodor5fmeJSjQquqk2xV+QClsKuY mqkEp1rTIs6SYox4mbyl45VyLvQVZWMcIpTkPyfRfxCi01m3KyizcCSlWGL0QGX7TAfv vkuA== X-Gm-Message-State: AElRT7F+suQELcBs4DxhQSkeC5fad3WJhmM4UDLTVQVl+DoYdMrZweE4 d7NvbBv3/QMRwNzy+6c+C0s= X-Google-Smtp-Source: AG47ELsjgR/zTXk7Q7i/tLCH+xd8PXk82hajiUyky/hvR8MsRWoWP627U+WeJPYgpVASR81fzLILPA== X-Received: by 10.223.174.247 with SMTP id y110mr3069357wrc.68.1521244760392; Fri, 16 Mar 2018 16:59:20 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:ccdd:87ed:24c:f984? ([2001:67c:1232:144:ccdd:87ed:24c:f984]) by smtp.gmail.com with ESMTPSA id f206sm8101336wmf.26.2018.03.16.16.59.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Mar 2018 16:59:19 -0700 (PDT) To: rtcweb@ietf.org References: <4B65832E-7BD6-4515-9C09-0C392BC85BC9@westhawk.co.uk> From: Lennart Grahl Message-ID: <1c3502ac-1e5d-9101-fa3d-188d3de4cce0@gmail.com> Date: Fri, 16 Mar 2018 23:59:18 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <4B65832E-7BD6-4515-9C09-0C392BC85BC9@westhawk.co.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Datachannel Hackathon at IETF 101 ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 23:59:24 -0000 In case anyone of you is not subscribed to the IETF hackathon mailing list. :) -------- Forwarded Message -------- Subject: [hackathon] Standalone WebRTC Data Channel Implementation Date: Fri, 16 Mar 2018 23:53:42 +0000 From: Lennart Grahl To: hackathon@ietf.org Hello everyone, I will be championing the "Portable C-based WebRTC Data Channel Implementation" project. Now, that title is probably not really expressive, so this is what I have in mind: There have been some hints that SCTP-based data channels are hard to get right and this is why I've prepared a standalone data channel library (called RAWRTCDC) before IETF 101 you can integrate into your WebRTC or ORTC stack. [1] The readme should cover the basics on how this can be integrated into a WebRTC or ORTC stack of your choice. So, here are a bunch of ideas we can do with this at the hackathon: * Try to integrate it into a WebRTC/ORTC stack of your choice and I'll be available for any questions, or * Creating bindings to other languages, or * Resolving open issues. Beyond that library, we may also... * Do interop testing with other data channel implementations, or * Hunt and resolve bugs that are related to data channels (implementation, spec-wise, usrsctp-specific, ...), or * Ponder about how to get streams right for the W3C spec [3]. If you're interested or just want to chat with other data channel folks, we can talk on-site or communicate via RAWRTC's Gitter channel [2]. Cheers Lennart [1] https://github.com/rawrtc/rawrtc-data-channel [2] https://gitter.im/rawrtc/Lobby On 24.01.2018 11:28, T H Panton wrote: > There has been talk over on the w3c list about the scarcity and unsuitability of free-standing WebRTC datachannel implementations. > > I wonder if this is a suitable target for the IETF 101 hackathon? > > The challenge would be to throw up one or 2 free standing datachannel implementations based on existing open > source with APIs that might suit authors of networked games or SFUs. > > Comments? Thoughts? > > T. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Mon Mar 19 02:04:50 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D5C124BFA for ; Mon, 19 Mar 2018 02:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 M8ebGOpQ0RJv for ; Mon, 19 Mar 2018 02:04:45 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 60276126CE8 for ; Mon, 19 Mar 2018 02:04:45 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id x82so1187912wmg.1 for ; Mon, 19 Mar 2018 02:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=xBId0pWIl2tlHQaLsCtMSrj/2rAcGsqkRnqEezAmLhM=; b=e+cnFIdT1EZW2fVRHOWCUXDLGlKQQcd5KpiGz59nqeHRVgZJAAxxGQVk+ezmkNgEQA mFiwbbCLc0igaQ6mE6a272E7w+3cwQA6reRuBP7qWviDH+oBU9ukeI30t7mO0QDWQgW5 pO9I4r1erJTsJoQYwXBWPiI7+zBSzfvikAnbZAhuroKNPQ3WIKFR8Pah9cWCKisn0kNs 9KMLg4Q4KIFfpDyVv0+HxmZnyoojrFDCsqyPnIbGal+H5bYYC8TkiEhrXTLS5l7CW03J 3DJeb90dX8K7Kl+cwD30eFYPwLRyrLN95A5OeeW61WJM4XUzVl6IeibPktlM/5Ei9new jpgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=xBId0pWIl2tlHQaLsCtMSrj/2rAcGsqkRnqEezAmLhM=; b=npU7qw2PU7LFbHFrKTIBUvqhm5vC+JfRsFw2gaI3lwMtwstxAmyzNIC61cL8OpLb9V e3KGgaZl7lnyBJR+E/WIPiSovUm9gtebxLrz/Eu3aBLAdOxS+Ie+PrpH5iJ27TNO+QNo ySqL09vNkF+IgmHF+UaQMLQS7S+Pt627NCczuadfZWNyGARxhm+JX5dxoAp8gEr8BDPW J01GCfdN7YNEvOAna8W7yZw5zBvmhpJRhOxBceR1MCMBRP/8kZlj7wsdBVIwEto2B9uL oSfalGOOSPe8lkHSE6gXsrVYPgsvyBEmy16ObQaQPPPrXUfSfix8yQYJPw1Mq7AJHcE0 6/Yw== X-Gm-Message-State: AElRT7HzmBeHW8u2NAcTsYVnMxWvQTcd83yxgkpQvHWBGlpAFtHHp+2O ZQYM1eABuRm+yFRnk/nTevYH6Mix X-Google-Smtp-Source: AG47ELutM31Cy1NbGTgiMKtDtDsuCX2qogM6XqTWccQmecf912dEdTtCGnsagDja5aiXohKttnvZ6Q== X-Received: by 10.80.204.195 with SMTP id b3mr12461950edj.18.1521450283639; Mon, 19 Mar 2018 02:04:43 -0700 (PDT) Received: from [192.168.0.101] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id b3sm7575341edb.45.2018.03.19.02.04.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 02:04:42 -0700 (PDT) To: RTCWeb IETF From: Sergio Garcia Murillo Message-ID: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> Date: Mon, 19 Mar 2018 10:04:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 09:04:48 -0000 Hi all, After passing the weekend playing with the webrtc identity, I have a doubt regarding a potential security issue. The generateAssertion contents contains only the DTLS-SRTP fingerprint attributes used by the peerconnection. The idp only has to options to generate the assertion, either hash/encrypt the contents and the user identity or create  record server side and return an unique token associated to it. In case the hash/encrypt option is used, as there is no nonce or similar, it is a deterministic operation, and a will always produce the same assertion. So, it should be possible for a malicious app to store the RTCCertificate  and the generated assertion and reuse it afterwards for an un-authenticated user. Am I missing anything or this could be potentially exploitable? Best regards Sergio From nobody Mon Mar 19 02:38:03 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A2112702E for ; Mon, 19 Mar 2018 02:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 u4MZ_i7G-UrA for ; Mon, 19 Mar 2018 02:38:00 -0700 (PDT) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (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 8897E127023 for ; Mon, 19 Mar 2018 02:38:00 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id y11-v6so16679936otg.0 for ; Mon, 19 Mar 2018 02:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NvEkGGKUwWqzVB2Dygq8udsczJ9/DQeAaTOvtoa4XQc=; b=pYfwhh19oaORXmTkudXF5jDX9eDeRHsnG/5AdRoywc58iVfQOlY8hjDwf8m4W6S1WB 6H0RZWawjrCnHfBdlsDJIpSlEBvzn6PRRfziFH01/irTaW3UWvZhLLIzO6g6Sc2xYYNy mQlO8JANhYOUbJahQemSU++1Fyo8tzt4i7FGs6ZkpGCva4M7mqBeFoh1a5CPYzinKKoQ pQFeTwBeXd2yMQP37kS2d3Sj7SVq9jZzlBGb/8fEjqMvtmKxXoIFr8sx0yJnKXmNNKKb 4JUazMXZV93zEMpW2C7U3qqfaxsQ1R9GEjGOclQE5yydow7F7VqIbl3g90OGSAjXDCMZ 1/CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NvEkGGKUwWqzVB2Dygq8udsczJ9/DQeAaTOvtoa4XQc=; b=kVdQ2K1ebG6HM7Qiiwdz5Aslei5guN/Ti8ZUjxFbsbZgn6tgxAZXcoqwFcCL96Wp9M KxAiTJOBVmtsYNX495U7N0w69bFuW8HHxOjT4LLuc4O3WhHi1KaVqh4BjmoF9DLYkx1n +efbDm6P2LkXYY0OEpPq7XHYSkFi9DQvMYFFnOxVYnkZRtnTkcBW1yaXywq0H8aVXNBJ 8mPjkiF2LZ1AL6FMuKOIC050NXBtgAtHYiY22zVayCT0BS/zf58/tK42EgfeSDtdezMU j7Q2rZ0WGvDqjVCe4BsEGYvUmL9aZT6RDN7j5u74aH87Hx4pMxuJtKOciwTkPu5+0Hyo YzAw== X-Gm-Message-State: AElRT7ElwVVXCRUq/O1kiIVzcPmhli08laBl5nO6YqtX4yA0lKSEbed8 acorj4PNhbsrbXyMoTu5jl+SEZ7OYMb55wdS24XlQoWa X-Google-Smtp-Source: AG47ELtyMqVEJAwhnjdjKnugceWrDoOYBiyoN2o1imNWHhABIjcZgbym8YRbMjwIdlvn/7bbzfvssHDBM+Rx9fMLAPs= X-Received: by 2002:a9d:350a:: with SMTP id o10-v6mr6849422otc.283.1521452279770; Mon, 19 Mar 2018 02:37:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Mon, 19 Mar 2018 02:37:59 -0700 (PDT) In-Reply-To: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> From: Martin Thomson Date: Mon, 19 Mar 2018 09:37:59 +0000 Message-ID: To: Sergio Garcia Murillo Cc: RTCWeb IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 09:38:02 -0000 Two things: This is a bearer-token design, which is inherently vulnerable to theft. The usual technique for containing the damage there is to include a timestamp. https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-sdp-uks addresses the question of theft differently. On Mon, Mar 19, 2018 at 9:04 AM, Sergio Garcia Murillo wrote: > Hi all, > > After passing the weekend playing with the webrtc identity, I have a doubt > regarding a potential security issue. > > The generateAssertion contents contains only the DTLS-SRTP fingerprint > attributes used by the peerconnection. The idp only has to options to > generate the assertion, either hash/encrypt the contents and the user > identity or create record server side and return an unique token associated > to it. > > In case the hash/encrypt option is used, as there is no nonce or similar, it > is a deterministic operation, and a will always produce > the same assertion. So, it should be possible for a malicious app to store > the RTCCertificate and the generated assertion and reuse it afterwards for > an un-authenticated user. > > Am I missing anything or this could be potentially exploitable? > > Best regards > > Sergio > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Mar 19 02:53:52 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553D2127867 for ; Mon, 19 Mar 2018 02:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Ktcgw4yJyfIx for ; Mon, 19 Mar 2018 02:53:48 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 2B67412D777 for ; Mon, 19 Mar 2018 02:53:44 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id x82so1482579wmg.1 for ; Mon, 19 Mar 2018 02:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=cFg2pV2NioqXF/VeTvk1rvejCq2TFQG2N2lAzIoopjA=; b=VOhpy6Utz9ITE//ak+fHA4M4BIpX1eDNr6zdiqRdRPHxuZFueygdewQuGLbuDZfNND POW39aFqjHMSLLK0h4O0Z0kTr5dCRU3IaN/EHqalo7YiC7Oj15KlRgIepeoNRz01l1H4 w54zHOO42fC9Tp6iL6gQd5EZujXE1zlQoICYbvJgPm4e+3fyGFA5HQ2g88f2AKMbi3IP r1TGC6FzPoHC/OJ2BzH79uJmhbk24FS0NKTFP+Mg+6/cxFnvFzs0RMzigPLEPbE1ZBml iLZJIa8v/FtHWzmczZY4wmCKLjlcUnFdwG+VNXKUnD4Sg9K/v315MgC3112pB9fXQyzB ryPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=cFg2pV2NioqXF/VeTvk1rvejCq2TFQG2N2lAzIoopjA=; b=XXBqdN1/OYD/QagIXvMQ7uuuSO/2nbegLQjz4jlNUO/61HeDyuGkRl3S4/Py3H30gT 3LqLQcFKff/YvslbzxOkv2SDTxkZy54eEenJiNnGxbeuAhAYv7oROvRUlN+yhXNp8tEq Lb0lEHy+bwjXyao55A8lklM4Dq2/H1UW6+hdwnim7Kwt7weWVAs+/m4zawaq1TTPp5iW 7uKPGj5YWBF3VZ4OeECFkehCWlFR1tg/+Lgw2uLNsdp+sUtROFLzmOadz74/2U+jvJMQ YopQ0w+R090UDuJAiNcGwMsfDZp9O7wTjeAAqI9OfQiumXvO5HVSkwryTuWcQP2cDK7+ 797A== X-Gm-Message-State: AElRT7HAl0G2AhE4JH3UE8MhsCZ1J4VUbRtLeVq5cpdaSbc54E1kA5SU SaN+cE/PPT14lOpStwj27gkHLLJi X-Google-Smtp-Source: AG47ELtSanMGcds4jOMyL0zUs1dArfBo5t/cJPzUFraGH0y0oU358YSDRl9PlY6UZDuIUhFwciMoUw== X-Received: by 10.80.149.68 with SMTP id v4mr12768423eda.236.1521453222259; Mon, 19 Mar 2018 02:53:42 -0700 (PDT) Received: from [192.168.0.101] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id j90sm7374520edb.37.2018.03.19.02.53.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 02:53:41 -0700 (PDT) To: Martin Thomson Cc: RTCWeb IETF References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> From: Sergio Garcia Murillo Message-ID: <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> Date: Mon, 19 Mar 2018 10:53:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 09:53:51 -0000 Hi Martin, I saw the reference to the sdp-uks but was not sure if it covered my scenario or not, so thanks for clarifying it. Generating an ExternalSessionId per peerconnection which is passed to the generate assertion function would make much sense and protect against theft. Shouldn't we add support for it? (at least if identity is used) Best regards Sergio On 19/03/2018 10:37, Martin Thomson wrote: > Two things: > > This is a bearer-token design, which is inherently vulnerable to > theft. The usual technique for containing the damage there is to > include a timestamp. > > https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-sdp-uks > addresses the question of theft differently. > > On Mon, Mar 19, 2018 at 9:04 AM, Sergio Garcia Murillo > wrote: >> Hi all, >> >> After passing the weekend playing with the webrtc identity, I have a doubt >> regarding a potential security issue. >> >> The generateAssertion contents contains only the DTLS-SRTP fingerprint >> attributes used by the peerconnection. The idp only has to options to >> generate the assertion, either hash/encrypt the contents and the user >> identity or create record server side and return an unique token associated >> to it. >> >> In case the hash/encrypt option is used, as there is no nonce or similar, it >> is a deterministic operation, and a will always produce >> the same assertion. So, it should be possible for a malicious app to store >> the RTCCertificate and the generated assertion and reuse it afterwards for >> an un-authenticated user. >> >> Am I missing anything or this could be potentially exploitable? >> >> Best regards >> >> Sergio >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Mar 19 03:05:27 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB4D126CBF for ; Mon, 19 Mar 2018 03:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 nuoGYpIB6dTp for ; Mon, 19 Mar 2018 03:05:22 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.14]) (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 B4F0A126DEE for ; Mon, 19 Mar 2018 03:05:19 -0700 (PDT) Received: from [216.82.249.212] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-14.bemta-12.messagelabs.com id B6/16-10394-F5B8FAA5; Mon, 19 Mar 2018 10:05:19 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSfUgTcRjH+93tbpd58Wuu9iS90KAsaZZJZEk vVFhQQVBSSVS3urbRNsfdrAX9oQRmilYwyVY2I0vUokzDllkp9GYy02KkvdiblppUaq3MpDtv 9nJ/fe75fu95vg/3MKQmQEcyvMvJC3bOqqfDVI0xZ3WGbdmXkufezdTGBxqGUPzFoUPq+PahK nIZudrneaFeXVT0g1hPJFMWuzHFtYMylzT0UI6DK13B/q9UGupaloVGMyr8iYBfHbOyUBijwX kEnK73E8rLKwS1vg5adtF4LgRq7hEya7EJcj6+VMtM4mnQX+wd9kTgJeBPL1UrnqXw7ImfVHg 5XPzRRyvTpoO/IF/qwzAs3goZg7PlsgZXIjhfrZN5NF4Mze7AcBuEJ0Cw/gKhjNJB6zvvMAPW wuumh7TC46Hz7RCl+LdCQV9dqK6HnnY3pfBkaPZmI3kvwAE1nD7RFhIM8Dkvj1R4HfQNfqcUU zOC543doWnR0NASVMmhAe+BgVy1Uk6ATn91yF9EQs21l6GmkyC/4khIaKHgc6mHVtbcBe7SkX g/CSgvizuKoj3/bOeRviGxF0Gg6TySBRaPgwcn3qkUkwGu37xNKjwVqnpOhTgB8gdqaU/oj7i zX6sVng/dd76gQsSUoiiRF/bygiEuxihYTGanjbNYDbGx82JsvChyJt7KGcWYnSm2K0i6rlHS cw215a6oQxMZQj+ehVWXkjVjjSm79ps50bxdSLXyYh2axDB6YMUsSRsn8CbetdtilU50RAYmX K9lz8gyKzo4m2gxKVI9imMqj7/PIJmnH7ozSI3KnmLnI3XsQdmKZas51f6n0ci5N6PJkREskq Jpwh28YLM4/9e7kI5B+gg2Xe4SbrE7/8zrkqIQUpS15y7IUZzcXykyDSVu8t0IttZE3NpSqH1 clrj/RWHt0Q3VqRWuzWEFB2jflP7yzPUJSQvbfS0LCtyONYcTxxT3qnPnCV8rHFFLMulj5SeL H+VG9Q7MoJI6p6W/6Q3eKcEbo8FztW2geF+ab7DD689Bs/Htqjn3t3XMzLkcDFZe/2aassj4Y U1da9LHPr1KNHOx0aQgcr8BtCtOIekDAAA= X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-2.tower-219.messagelabs.com!1521453917!184477400!1 X-Originating-IP: [207.46.163.23] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6468 invoked from network); 19 Mar 2018 10:05:18 -0000 Received: from mail-dm3nam03lp0023.outbound.protection.outlook.com (HELO NAM03-DM3-obe.outbound.protection.outlook.com) (207.46.163.23) by server-2.tower-219.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 19 Mar 2018 10:05:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/+AMdeE6ulXLSp3NW9ycRll7g9ATGSbriLqoCiXewu0=; b=ap0i3PKdDCr/IVfefFNgXBzmCLX74pMA89Y4oCP6zCU+YDoyn9VhuB2KoaiSLvb4cyablrXuKL/f1BCzlL+jHNGVyWF2gtRX+quBOIyWccZSwNNdlYLs4KoGfJRllCVx2bjB4iHYUIk7KHl6GnLJTDnniOiQoKZ1/DBHj1wzMgU= Received: from MWHPR14MB1376.namprd14.prod.outlook.com (10.173.232.139) by MWHPR14MB1168.namprd14.prod.outlook.com (10.173.101.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Mon, 19 Mar 2018 10:05:15 +0000 Received: from MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::7929:3f48:4a4f:1e32]) by MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::7929:3f48:4a4f:1e32%18]) with mapi id 15.20.0588.016; Mon, 19 Mar 2018 10:05:15 +0000 From: Tim Hollebeek To: Sergio Garcia Murillo , Martin Thomson CC: RTCWeb IETF Thread-Topic: [rtcweb] Possible identity security vulnerability Thread-Index: AQHTv2Fbf2/O/UlBVk2jAz9KxqI00qPXTSyAgAAEY4CAAAAskA== Date: Mon, 19 Mar 2018 10:05:15 +0000 Message-ID: References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> In-Reply-To: <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [31.133.148.144] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR14MB1168; 6:ekzJEwNOonrFoZnjihQztT4IFZAmOfq/mCs7e3BWY4cATT4XJrWKl0BBe8fb1SA6Dfs+Um1U121qtlF1Qri8vUX4wjf9Vabq07Yl5V7S7c9hFHl8Khb0XMa6YMDP94zkrsXSSftMlwQkcNHGeA2VX2QoK9LPDcBovTykErI1YFdOVED0fIgU4Ad5wARns4roy8JmY/3rm5iaQe2br08+M7by/FaaYLIvMccMYiib299pXh8OV0DJEb0R4Jvprvba/zGdG8GUxIgc4K7dwInEcZrjQJpwCQtd+gYBwzjIGQ6Wch02GRat3PbVUqrX3/If36oejE+yTooVDocikZuI6coTJeBTEl0PuS2tkKcIuRUgqdH0CeaUbStcAOAhNWGC; 5:yfmc9CxewX+SKGWRhwncmNKa472rL9ZP1FACzA2A1otDsnjJGR5ORaexaie3CcAVF2dWAGesVJc+6drSD+90thJHW37ER+ECqYQ2vxOjFh+4+9YBq+F6dePYA7Hg/8nLfxbu0tUPgIY5kSUGiW1RQIXuYgM9GAEyY6rOU6QUjZ4=; 24:zJkODuff6Hn6/qSi9T1L7pi5wTFjcIuSUgmkP8r3aPKg+w1qowRd4laHIAgLBiuwhILrFZiuDMinGLE4bHxFuXfW5cQCFzCMjCx2f5DAdLQ=; 7:GGr5p0akQUkUIDnOuzj0aZDHZchPJZ+qjiG8UW4fIMmcADoqMJw8oREZutZEt6BDgwmBMIUa1evbwDeHpj9zPlH56qyIJz8Pq3JQjA+lNYpDY/WjRCIa6UjVpU3DgfWmHCM1ccUgL8a+PJi1eVuO63nIYg0SUnVp9KHAl8HDqK3vyqTO9ZmA8qhzG0mnBI7O30Ir9He2pXMPqLvx/gEd1/ixvBRLRIHGxh0SZIMT6j8JRgKtg8HQum7TPkVsYCUu x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 5f089bbb-f088-459f-6ca2-08d58d80e961 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:MWHPR14MB1168; x-ms-traffictypediagnostic: MWHPR14MB1168: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231221)(944501300)(52105095)(10201501046)(6041310)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:MWHPR14MB1168; BCL:0; PCL:0; RULEID:; SRVR:MWHPR14MB1168; x-forefront-prvs: 06167FAD59 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39380400002)(39850400004)(376002)(396003)(346002)(199004)(189003)(6116002)(3846002)(2906002)(3280700002)(74316002)(305945005)(7736002)(97736004)(4326008)(66066001)(15650500001)(229853002)(2950100002)(68736007)(6506007)(186003)(102836004)(59450400001)(25786009)(26005)(39060400002)(86362001)(3660700001)(81156014)(81166006)(8676002)(8936002)(53936002)(6246003)(55016002)(6436002)(9686003)(110136005)(316002)(2900100001)(33656002)(478600001)(14454004)(5250100002)(99286004)(105586002)(76176011)(5660300001)(106356001)(7696005)(99936001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR14MB1168; H:MWHPR14MB1376.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 9dVGJGrpddUJ63UyQOGWDfN0eMkuJKoon7Sp2DkvPKYlNmxfL07/pdDDd3opmTA8OWr0fmJPSs7IEw7UzMeE5dw14idBsWShZybMEmZp2LcfcdDPBKDVwRWJ2sPY+csOZano2aYatDucGwqYyerZI54EQqobeqYdSs0gZoEtKP1dWq0u5mKstYz0JO9EDfXBaBho8Jl6/O6jdblxvPH/ctmU4Tx96/oIi+ncZDlNmGDvyyfFtZ++5u3rdfXbFLlvjPupPkaAAOXKYBdzjtO2UD77jZiv3JdK12aKRd7mPXCUCUtVehhQZWjCKqHLNbslaoj8G9XXzadh404fF5jVrw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_03D8_01D3BF69.C542B170" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5f089bbb-f088-459f-6ca2-08d58d80e961 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2018 10:05:15.2037 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1168 Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 10:05:25 -0000 ------=_NextPart_000_03D8_01D3BF69.C542B170 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > Generating an ExternalSessionId per peerconnection which is passed to the > generate assertion function would make much sense and protect against > theft. Shouldn't we add support for it? (at least if identity is used) Based on the discussion at the hackathon this week, the time scope of the authentication is anticipated to be very short-lived, i.e. on the order of the length of time it takes to set up the call. So I can't see a valid use case for re-using the bearer token. If it fails the first time, simply restart the protocol. Indeed, I believe that is what Harald was doing in his proof of concept. Therefore, I'd personally suggest that the rtcweb-id require that the tokens be one time use, and perhaps even specify a reasonable mechanism to prevent unnecessary "innovation" in this space. Preventing replay is a basic security goal, and it would be unfortunate to leave it up to Identity Providers to notice that and get it right. Someone please correct me if that requirement already exists somewhere that I didn't notice. I read all these documents and Cullen's excellent overview slides with only about 5% of my brain cells functioning. BTW, I'd like to thank the rtcweb-id hackathon members for answering all my questions in my extremely sleep deprived and jet lagged state. It was an absolutely wonderful experience being able to discuss the draft with them and dig down into all the technical details about how it would actually work in practice. There are actually a number of other interesting things about the design from a security standpoint that I hopefully will have time to expound upon further in a couple of days. -Tim ------=_NextPart_000_03D8_01D3BF69.C542B170 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgwMzE5MTAwNTEyWjAvBgkqhkiG9w0BCQQxIgQgGBHfGVl7J/fDuWpP4dX2rNkkfEy0 lDjwkgUKXvmiNbYwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAEadMXMnQslH4g6qzZxvcKJ3uXi2vCESf6z92XR2mknJRDFvboqO+6jMXWV9+uPQyT9SI55D +C2EkVPc+QtHPFCpY9kiAitzqQ0iqMj2FQeNj90159Wqkkh0bzYotoBsZ9T9xdFS4SX+Y7j1/xRy V9du/SmqXNAqTUH0T0AECA+20aMYvhA2Zb2mZ+8HMeqhvI3MiSdg0rDdWGsvHIMKknX8teeGkKCv 4l5xxEM2jG4etWBIw/6PMJhR0gQg5FIJeIk7P9gov5ELaDwrkpcvtbwHsnyal/3/uhanf58amoXB C1gkHu6p3JnkCKawh409+eamYwOph7LwZlDt3ayiguYAAAAAAAA= ------=_NextPart_000_03D8_01D3BF69.C542B170-- From nobody Mon Mar 19 03:20:37 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A95A126CE8 for ; Mon, 19 Mar 2018 03:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 pAGFceGa3k2h for ; Mon, 19 Mar 2018 03:20:35 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 E0BF8126CBF for ; Mon, 19 Mar 2018 03:20:34 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id h76so14082815wme.4 for ; Mon, 19 Mar 2018 03:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=aSQEbZ01G937rOx2cCezlkzjHUn3Qwxb4Bla9oKGZpo=; b=qzvnePwSO+qygJr9caCj2cTtOFokI//uBBbR/lNrjYO/hhS/btecIghYRowfVraOA/ V4grCPr738utO1nZFd21wH7FUd6n2SYXGGe+PenBByNlZ/4ybw0j8j5yYnRU5XSlnuCb RwYEyWioYbY7PppXLfm1pVxD9uN+flzIKMHb3U5pjVa2O0964jXEBxRAa2lbbXCyH985 m08KgqGx2bFLnU7UJQlZz5Xqb1B///1dZ2K/SRl59t7F9/P2zGwk3fWN3f8mLusYpzzy QhXp8OQTxIV7F3BBeg9De6amoxVNnh4KdLdjNEeM06jDLsqmbcdLcMsV6ICqWxHEMVbY 51pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=aSQEbZ01G937rOx2cCezlkzjHUn3Qwxb4Bla9oKGZpo=; b=f4LXI01ZnPYPgqlKrUww3t7usrxgznTN0sQUoq/fknYZxGA7qkzqhTwfsBlHXTjNVz gWYJb/bQcfzdtsCLDICpbzmJAZ5xiRfbDzaC5NfQvSVt3fVAnmJh3pmm+YhulbMfnOIc 22UBMxBZGuCizW1Otppn4FLnZUjHWs6zcqKAMRWZVgkVhXM7CY9/t9430MQin0W/94W6 nuuYXf2Wy4Yud1UXEa9nA4HtRhvR7Zp9xppmR9Q1Yvbw1iH4ns5jnhV8Z1PH3XsfA4dT 2mBX6RdzLIEjGZ1Go6mEV99PVkPMde0mJuVtlROe5PM+SjH+T7FGeYYcrIB8Rn3mBY5Q fRUg== X-Gm-Message-State: AElRT7FHLbCP1m9rb1mVSb7Bim5E1oC68S0E+fDudysHe3YSh1tuYP3z Ux5aRssGoOd/BftPfog+t8Wg50ID X-Google-Smtp-Source: AG47ELuOW6n0vR3auax9izEt6Nq9El9LvJ1xldCl6DM+y0YPh6moypemVHP45U2WatKQOvMko9kc2w== X-Received: by 10.80.221.74 with SMTP id u10mr12920774edk.198.1521454833234; Mon, 19 Mar 2018 03:20:33 -0700 (PDT) Received: from [192.168.0.101] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id k7sm9253101edb.51.2018.03.19.03.20.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 03:20:32 -0700 (PDT) To: Tim Hollebeek , Martin Thomson Cc: RTCWeb IETF References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> From: Sergio Garcia Murillo Message-ID: <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> Date: Mon, 19 Mar 2018 11:20:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 10:20:36 -0000 On 19/03/2018 11:05, Tim Hollebeek wrote: >> Generating an ExternalSessionId per peerconnection which is passed to the >> generate assertion function would make much sense and protect against >> theft. Shouldn't we add support for it? (at least if identity is used) > Based on the discussion at the hackathon this week, the time scope of the > authentication is anticipated to be very short-lived, i.e. on the order of > the length of time it takes to set up the call. So I can't see a valid use case > for re-using the bearer token. If it fails the first time, simply restart the > protocol. > Indeed, I believe that is what Harald was doing in his proof of concept. > > Therefore, I'd personally suggest that the rtcweb-id require that the tokens > be one time use, and perhaps even specify a reasonable mechanism to > prevent unnecessary "innovation" in this space. Preventing replay is a > basic security goal, and it would be unfortunate to leave it up to Identity > Providers to notice that and get it right. Someone please correct me if > that requirement already exists somewhere that I didn't notice. I read > all these documents and Cullen's excellent overview slides with only about > 5% of my brain cells functioning. I agree that the tokens should be one time use, but the I think that the only way of enforcing it is by generating and unique opaque nonce (the ExternalSessionId exchanged on the DTLS setup) and couple it to be consumed only by the PC. Without a similar mechanism, we would delegate the correct implementation to the IDP, which would be forced to store the "contents" server side a return an unique token and ensure that it is deleted after first use. Note that even in that case, there is no way of certifying that the assertion was consumed by the right call, that is, a malicious attack could generate the one time assertion on a valid user, but do not establish the call or faking it has failed, and use the token later on non legitimate call. > BTW, I'd like to thank the rtcweb-id hackathon members for answering all > my questions in my extremely sleep deprived and jet lagged state. It was > an absolutely wonderful experience being able to discuss the draft with them > and dig down into all the technical details about how it would actually work > in practice. > > There are actually a number of other interesting things about the design > from a security standpoint that I hopefully will have time to expound upon > further in a couple of days. Indeed, it has been a exhausting but awesome experience! Looking forward to sharing feedback from the hackathon! Best regards Sergio From nobody Mon Mar 19 03:58:26 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585F0126E64 for ; Mon, 19 Mar 2018 03:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 nKR6V6bvK0Gl for ; Mon, 19 Mar 2018 03:58:08 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.199]) (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 417D7126FDC for ; Mon, 19 Mar 2018 03:58:05 -0700 (PDT) Received: from [216.82.242.46] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-7.bemta-8.messagelabs.com id 61/F7-03133-CB79FAA5; Mon, 19 Mar 2018 10:58:04 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSa0hTYRjH956zy/GyOk3LRzGqdSGFLSWqoZV BUH6okOqLItQxT9twFztnloGgGWipqZWprewYTQxLDK2miVGLUrtYmWkpmpJSpnYz6aLNdnam 1bff8/7/73N534fAFa+lQQSdaqEZE2VQSr3FrxbfIFWNJTVxYbV5ak3nYyfSVDuzZZohpx3fh Ec3WHtl0TbbTywGi5PoTQnm1L0S3Wn7oCT5SFRqX02TJAM9W5+DvAkx+QmDhkc9Yj5QkMUYjJ /qkwlBP4KpHJskB3kRUjIMOpuaMZ79SS2cGOVNXgROLoFvlZyUZz9yI7QdqZIJnijo6WjDBd4 B9ypsiGcxuRy4gjvuPHIyHk7ZM92sIOsx+D60imcvcgOUXe5250TkAvj+8Com1AqA7kHOzUD6 w8DzR1KB58PwW6dE8MdD2bjDc66EsaEiicALoZ3LRfxgQHbK4PjvKVwQVPD5zBkXEy7eDnkNK wVPO4Lp4seeYqFQOHhDLHASZGSWegpEwnBbo0S4YMPB8aDHIwRDaV2BR+CkMPD2ukwYMxGKqm bam8Qgty6tEIVa/5nO6rqDkxyCX+23kNX9TPOg9eygWDCp4NbtO7jAi8A+dt7DkVD6667U6vm SotwBmcBrYOT+F1SOiCq0kqWZgzSjCl+rTmD0Wp3FSOkNqvAwjdpIsyylpQ1UAqveZzbWIteC pYtEqB4VNm51oEACU86Xm0/WxCnmJJgTD+soVreHSTHQrAMFE4QS5CPFLm0eQ2vp1P16g2tLZ 2QgfJX+8nO8LGeTKSOr1wrSQ7Sa6Ch5l4UTr96PZOEKsclsooMC5A7eSvJWXYppNtHMxrejhU F+ciQSiRS+yTRj1Fv+1z+gAAIp/eRNfBZfvckyW++DqxXM1cq2iqt8KxbqrxSUgSwr3uzPPHq h1Tm8LWUiKeDrj4jKcme0/5aIPntSS9pLLrt/z2TZyJXu6/kh9av7LvZeUzPrWnVZl0VnJxIz H1yypB8dr/7YbPcqyY9H+cSzzT+P7bJxsSG1N6fnerccWBSLRYSFjC572uZTsvRQyJPdmpjYQ HgxUdAlHe3y4WJ37lOKWR0VHoozLPUHNCKTmuwDAAA= X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-9.tower-96.messagelabs.com!1521457082!100332451!1 X-Originating-IP: [216.32.181.16] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 909 invoked from network); 19 Mar 2018 10:58:03 -0000 Received: from mail-co1nam03lp0016.outbound.protection.outlook.com (HELO NAM03-CO1-obe.outbound.protection.outlook.com) (216.32.181.16) by server-9.tower-96.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 19 Mar 2018 10:58:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=72tPgcR2HaBuUM6LBTSpYe5PYeDNtHfjaWybYDCq4wI=; b=qyAJfT9g1dTrR7BQzn5zpX0CRnbwZvnXPtPfac9DSV13tXpPLf8eLZTkyr7nMEOXsQi5MyOobsLNdaneY0mX3BGHvD++k47zi+7T8jerGsdPhJQcBss5XOoVx+FqM78/qZgZ3HBJdtB8xbLQSUz7eXiPYXvou8RWpiZKqtvqB5c= Received: from MWHPR14MB1376.namprd14.prod.outlook.com (10.173.232.139) by MWHPR14MB1503.namprd14.prod.outlook.com (10.173.233.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Mon, 19 Mar 2018 10:58:01 +0000 Received: from MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::7929:3f48:4a4f:1e32]) by MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::7929:3f48:4a4f:1e32%18]) with mapi id 15.20.0588.016; Mon, 19 Mar 2018 10:58:01 +0000 From: Tim Hollebeek To: Sergio Garcia Murillo , Martin Thomson CC: RTCWeb IETF Thread-Topic: [rtcweb] Possible identity security vulnerability Thread-Index: AQHTv2Fbf2/O/UlBVk2jAz9KxqI00qPXTSyAgAAEY4CAAAAskIAAB1QAgAAKAQA= Date: Mon, 19 Mar 2018 10:58:01 +0000 Message-ID: References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> In-Reply-To: <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [31.133.148.144] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR14MB1503; 6:8eaqP2NmKqzNQnui0rDq63comGF6Ju128rcJbcOjHDVhgimgZnoUSQqwYmgtV7IXxT4TLeA7ynWpTVaY3bit7UIMNAO7Y20HHzAHUET2FHGC/+YjnhGv4jD/Tvm3m+m4MuU8sQu9kmXvrTx4RotS6hpZMdXTaddEMr7IAufN9eabUJg6UaiyinU0336Ss0UVMoA95jDeaeYikhjS1+XT4HOjn9VmnQwNZOOgPVUMDliaqawWuVXtV0iomfEO9GiP0NsKF3GFiYro8dNM477qWYXFLKVCtu9GALbALD9iAks3O+CHMjmxNnfB5xroa94g+spx7nNgoplmm3geSlPFaYoQZLnKe2rPeJDVA6dUc8PMoJJRTYzDrDxkgHojPydN; 5:FQRm/LVzsV+hKzsCeeSthH1zHvqmxCbyseXBHIVvm7KhxvsH5qTo7RBWvuH1cZuQkKyPLFzntFQlfaCSMwMdd9plmOUs1FyBvGXBR/00U9jpWQk44U+yDoMpzv3pobcqTu+201MRk/aWh+mLCQUj+0wdLz4f4AQqjWcX0hOXY8Y=; 24:P1wTPZMuTD7U/qsxgARszkTPP8+Mt6l1nYPxtUppx9Kw2e/vDe835YwLM+0RC+xe6CzQRrV9enFCs6LGLZjA+QOa3ExQmt8YbeNvgOEk7hU=; 7:k0H93FqllJ1ZR/6IbtKbHHk2KWXCI1Qvx95clTO+GuKawyHHGPv555pZEHFDtfNkXr+8E30Tmwa/hdeGB5VxgnAB1g0tek/CxSotXL7MUbc5R346GM8K0ZoDozuxJX2uWpB9c9jXG7m3qPFa7jBmK3ELi747q5qSJd8WvdBgCU1HMnrbJsUXwoS5EQoVXJKmKY1o9xgJy/7rRhFAIwH3Lu70949Hb2hulV6Hoj8qmfwTlTaurlCdVA4LBWOOypD2 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: b01d5343-d423-4a22-8f5a-08d58d88489a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:MWHPR14MB1503; x-ms-traffictypediagnostic: MWHPR14MB1503: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231221)(944501300)(52105095)(10201501046)(6041310)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:MWHPR14MB1503; BCL:0; PCL:0; RULEID:; SRVR:MWHPR14MB1503; x-forefront-prvs: 06167FAD59 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(346002)(366004)(39850400004)(39380400002)(376002)(396003)(51444003)(189003)(199004)(97736004)(316002)(74316002)(110136005)(6506007)(9686003)(76176011)(53936002)(478600001)(305945005)(3660700001)(14454004)(5250100002)(8676002)(7736002)(106356001)(3280700002)(7696005)(81166006)(105586002)(81156014)(59450400001)(8936002)(5660300001)(229853002)(102836004)(99936001)(93886005)(66066001)(99286004)(26005)(86362001)(2900100001)(4326008)(55016002)(2906002)(33656002)(3846002)(15650500001)(6246003)(25786009)(2950100002)(39060400002)(6436002)(68736007)(186003)(6116002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR14MB1503; H:MWHPR14MB1376.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: E/Vq0O7q5X6+xGjW2Q6DIDFBCE5DIkP6icYwp5KEmYRsYcEWYMGsKSQjInT3p4TWCbfWGy1Id0mAsDymDEEvxbT5MspJgN636uaQEOpYj5Z5Y5XyXzdhP7EJpLW7rYw8xOabBJTJbF5cCz+yV0Pz7e8OQBeB7eCZwJkDSBuqeL36x7krXnVi1RD6L/Sy76Mv9GWWtdCZ8xwC/oxbX9UERf3IjAH/Nlqfcgz3q2vo4X913PZQpzPddkBqsZ9HC4ep3wqU+8KQBqanC6TgS+fhpMR5wPdr3M+370AdABd5HBLB+zev3FDPQBslRYcQY31IeliDlXisoENBrO47APO6BA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0420_01D3BF71.249BDB40" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: b01d5343-d423-4a22-8f5a-08d58d88489a X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2018 10:58:01.4700 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1503 Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 10:58:13 -0000 ------=_NextPart_000_0420_01D3BF71.249BDB40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > > Therefore, I'd personally suggest that the rtcweb-id require that the > > tokens be one time use, and perhaps even specify a reasonable > > mechanism to prevent unnecessary "innovation" in this space. > > Preventing replay is a basic security goal, and it would be > > unfortunate to leave it up to Identity Providers to notice that and > > get it right. Someone please correct me if that requirement already > > exists somewhere that I didn't notice. I read all these documents and > > Cullen's excellent overview slides with only about 5% of my brain cells > functioning. > > I agree that the tokens should be one time use, but the I think that the only > way of enforcing it is by generating and unique opaque nonce (the > ExternalSessionId exchanged on the DTLS setup) and couple it to be consumed > only by the PC. Yup, after understanding your concern, modifying the API to add a required nonce would be my suggestion, as it expresses the security requirement in a simple way that's hard to get wrong. -Tim ------=_NextPart_000_0420_01D3BF71.249BDB40 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgwMzE5MTA1NzU5WjAvBgkqhkiG9w0BCQQxIgQgu0W8/hlkvvUa7ljAOzrJ7YaNhOPe XI0oqz9O2VB1csMwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBACMEsHQgPBaJmGmApyrjyGeU24SC7r1AEsSdBlMxwlQL+AkQZ8383Ose9vhQ9CHQV7J21UG0 nLosXeEd5XrY/ep16YCns5Vtm4kguOkChM9CrTDeBMfcxrs1YhvfZjxH5xsmU9iLxtjBa6MnM+EX Lqp3euqbCdvFcF1nUd9OfJAQAo2hScyAUiI9wjb9T759JkxyFJaBPUQD8C/lszH/TqPCnPTTsZFl oGw7uGCD+fGDeCimxl5uapvlZgDfmRj/IGnrX9uGhOBH18tyRl2m++0TfObSwjr+BAgYoDxceFlb F8kZEifpQm22gn30V2fP8n6AVjROfDeIrQ9V3v8wbBoAAAAAAAA= ------=_NextPart_000_0420_01D3BF71.249BDB40-- From nobody Mon Mar 19 04:06:18 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE97812D873 for ; Mon, 19 Mar 2018 04:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 0lyHjsa9jvZ5 for ; Mon, 19 Mar 2018 04:06:15 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 B8D9B12751F for ; Mon, 19 Mar 2018 04:06:02 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id e194so14280315wmd.3 for ; Mon, 19 Mar 2018 04:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rrMc8ZejpUr93juPW+HACXMaqNCtk0iqWhqh6QaPRGI=; b=KOKpw7MIebcxaFlJ4jcIJG4AfOPDvd5vs5knnzK4O+MXOEhN4eHOSB30gQGIkw1dUI DBk2h5f77LtQxkvlFioS/LjnqwUw/qW2wM7M5SxaU7r3gMlrTVG2/eX1UGkjz5tbfGft NEyX4bdvnKz4tA0uvvRyjzcVuH1klpmQ3lVGk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=rrMc8ZejpUr93juPW+HACXMaqNCtk0iqWhqh6QaPRGI=; b=mEyYvqgh5rjUkW0aoI7LpiiJs6ml5a1MZyOtee1A9PaxAd2nzoMK0oXLSNKGU9usao OFBKl1ML98pGn3EFRsHMwsO44H6ywvlb4MHIu4NlGwOOsK6bLFz758dfbWNMz0RO5sd+ Sxh5DXGH/0+b1H8sWyPNce3nr+dfMl40Q9eRR8+94enSkT/2k7LdcTJsal+yocjFVpY1 NsO7Rn78hwhoNAlQYAGeCq380bG1l5W0RYZPkOJzUpN0wKT72ZftHte9bmXXeUCpv0Y+ vGf23p4VSAl/GE28w1Qe9MZzt27Rblmj65YcmG+P9Iw6jvEauCq7nQlRhmEvKga0sxHo 5Y+w== X-Gm-Message-State: AElRT7G5g9B8as0ytusd2fRhW197j8Ju6HxXKYJekktxI9NtYAKophC7 EKvu6ywKcKqyWwCqb3tjGkgmMQ== X-Google-Smtp-Source: AG47ELve4jDF41AJC2ELOSg3NHMUAuwbwvDKEE1Dk6beylR2Hp34ojq9UdyECSm5NDbQSslhzfJ8vQ== X-Received: by 10.28.105.19 with SMTP id e19mr1510780wmc.3.1521457561103; Mon, 19 Mar 2018 04:06:01 -0700 (PDT) Received: from ?IPv6:2001:67c:370:1998:b12f:dff3:a0d5:7431? ([2001:67c:370:1998:b12f:dff3:a0d5:7431]) by smtp.gmail.com with ESMTPSA id n64sm118404wmd.11.2018.03.19.04.05.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 04:05:59 -0700 (PDT) From: Nils Ohlmeier Message-Id: <2AB51FBE-21ED-4BFC-A0F0-A6BCF89B9C5B@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_410D1202-0676-4C4B-A42F-D6863E32DCA9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 19 Mar 2018 11:05:58 +0000 In-Reply-To: Cc: Sergio Garcia Murillo , Martin Thomson , RTCWeb IETF To: Tim Hollebeek References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 11:06:17 -0000 --Apple-Mail=_410D1202-0676-4C4B-A42F-D6863E32DCA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 19, 2018, at 10:58, Tim Hollebeek = wrote: >> I agree that the tokens should be one time use, but the I think that = the > only >> way of enforcing it is by generating and unique opaque nonce (the >> ExternalSessionId exchanged on the DTLS setup) and couple it to be > consumed >> only by the PC. >=20 > Yup, after understanding your concern, modifying the API to add a = required > nonce > would be my suggestion, as it expresses the security requirement in a > simple > way that's hard to get wrong. While I agree that adding a nonce would make the assertion stronger = (assuming the nonce value has enough entropy). But who is going to create the nonce in these scenarios? I would guess that often the nonce would get created by the signaling = server. But as far as I understand the potential attack here, the = stealing of the assertion would have to happen exactly on that signaling = path. So if you don=E2=80=99t trust that part of your setup, you should = not trust it to create a unique nonce to improve things. Best Nils Ohlmeier --Apple-Mail=_410D1202-0676-4C4B-A42F-D6863E32DCA9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAlqvmZYACgkQY2o/VmzJ +KG6IhAA2b0DK2psPJN3UJe9z+HXIilrUObPxwdkrnCf/YRGGean5jp5A560hft6 P9j84fLlIUt589HQsFDNGBmy7NsFQo20oo30AMcii2itowTip0mVdio2njlWqVj1 bV5Zom+jchl71p/bUNxYFj+z7RqN+9lWQZokk7FFqw2AVJV2SBoCI3d7kXLm4HIs KE8VRLk2CD+XaWL2NttcQwqERqDczQAXOS0oMgIkZHkJBuAPNaQUwGsgJjJ7Ejhb LOl13ta/qaQYC+zuBMWq3svwDNmaSoVGF2TUa3OM8jprkLDCoc1NEDZcLK5recPj rXpKTmnDCXJpfgQMVJNBt4zAO4rXmTa7+EmEp9uKwrDe4LneDGeyc289IINWGq/f n2wiMPpPqyBmOqndwy5i9Ms6y3vIzt8+vG43EL/2uHAS+rFCXz3xSmfOXPn7wuCn oHV/UQR1b5OC/mCrUB6UWasXHcZWLlSJY7Eh8mQRLFjIWUY60Gkj7vhP3Z8CUezC GqHNsO2EuDmO5eREu8YJeO6vJBnEeRIcrrc6dm5z0ENUOf4y4+J/n39+vZsMDlxz U1ke67arpeGMuwaRnWkoo2KjcNIJCPF/rhW8NXzY2dfDMZiqrCqjHwN554lTObJq ZCeCPaZn9pbzCJSJn5VZzmLFStW+hy/6OAnCsaU//9sNIOeFDCw= =x4sr -----END PGP SIGNATURE----- --Apple-Mail=_410D1202-0676-4C4B-A42F-D6863E32DCA9-- From nobody Mon Mar 19 04:06:34 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 290FE12DA11 for ; Mon, 19 Mar 2018 04:06:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1521457582; bh=kZ6ZR3xvRdcvuUfWbE34VzMpYMZqJhXksIgiqru4klU=; h=From:Subject:Date:In-Reply-To:Cc:References:To; b=oaelhqRPfMgbXE61M5ew6l3uwGTy08AHwlcjvw6woNH9THcVX0TS9ndZ4M5ntFp6V F9/PKgbFb0j4G/KUuJgI/SjzAI874yCfCSrxadJp4MSbxyhIu3Sgqs1A5D8b/qqxh/ LRNqYGgt5Q65vEnPQv43pDfCJv9xe7uE56vzKT6w= X-Mailbox-Line: From nohlmeier@mozilla.com Mon Mar 19 04:06:20 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2757712D9FF; Mon, 19 Mar 2018 04:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1521457580; bh=kZ6ZR3xvRdcvuUfWbE34VzMpYMZqJhXksIgiqru4klU=; h=From:Subject:Date:In-Reply-To:Cc:References:To; b=gBfUofYa2g0skgC7WD5+Wn7JAhBjNvru7Jwp+J4c+ewR8d4hy1gLjPUdyRignhRmE bI4UbdsOMD6ro9CGWicCjTxrhsRBNxpJzRjJrAeuDpqFgkZgxiqIUgWximGI/e4Gpo /+8aR6sM3vKXaf9M14FY0OC7t2EGgpHgyLXd7D7s= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB0E12D954 for ; Mon, 19 Mar 2018 04:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 CmYzLDZH7D1p for ; Mon, 19 Mar 2018 04:06:18 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 F35E3128D2E for ; Mon, 19 Mar 2018 04:06:02 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id h21so14296552wmd.1 for ; Mon, 19 Mar 2018 04:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rrMc8ZejpUr93juPW+HACXMaqNCtk0iqWhqh6QaPRGI=; b=KOKpw7MIebcxaFlJ4jcIJG4AfOPDvd5vs5knnzK4O+MXOEhN4eHOSB30gQGIkw1dUI DBk2h5f77LtQxkvlFioS/LjnqwUw/qW2wM7M5SxaU7r3gMlrTVG2/eX1UGkjz5tbfGft NEyX4bdvnKz4tA0uvvRyjzcVuH1klpmQ3lVGk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=rrMc8ZejpUr93juPW+HACXMaqNCtk0iqWhqh6QaPRGI=; b=BerUfHawqaCXC1fo7tLzMRiVF6jsIvYw0UKKxisjY2r8tiBlFrBHvCzguI3dFnPd9D 5N67qV4aKOnkOHakIg11xF3wjWsZgmHWagiNFgdObq2pw6CmClCfw/ethBZfh+InC6jB LEd5/qsHGEGoS0t355OJUEZQ4Yi4J7oz9s9OVZeFIBJzi0VULn4xDj6SG66MjypIF6gc XIk/HTONow4mZwaySKhcWRTZgp/uSbJv1eCMjAnh6sWeOurUCTw9913VWlvkU6wAZlf2 bcrFHkAcQryaIZixLRMZqM71JPugC4yXmK/DMqdSDfm+JJwK5k+MrOSgfEAZE27RbKOT owlA== X-Gm-Message-State: AElRT7H+gq5VkkHXHNMw6vuInD0TxoXaD9f9xRwYV/kfBEPOXVh6l96Z nEKCfz3x78woyr9VgPkA+K3hJuXR6Ys= X-Google-Smtp-Source: AG47ELve4jDF41AJC2ELOSg3NHMUAuwbwvDKEE1Dk6beylR2Hp34ojq9UdyECSm5NDbQSslhzfJ8vQ== X-Received: by 10.28.105.19 with SMTP id e19mr1510780wmc.3.1521457561103; Mon, 19 Mar 2018 04:06:01 -0700 (PDT) Received: from ?IPv6:2001:67c:370:1998:b12f:dff3:a0d5:7431? ([2001:67c:370:1998:b12f:dff3:a0d5:7431]) by smtp.gmail.com with ESMTPSA id n64sm118404wmd.11.2018.03.19.04.05.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 04:05:59 -0700 (PDT) From: Nils Ohlmeier Message-Id: <2AB51FBE-21ED-4BFC-A0F0-A6BCF89B9C5B@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_410D1202-0676-4C4B-A42F-D6863E32DCA9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 19 Mar 2018 11:05:58 +0000 In-Reply-To: Cc: Sergio Garcia Murillo , Martin Thomson , RTCWeb IETF References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) To: Tim Hollebeek Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 11:06:24 -0000 --Apple-Mail=_410D1202-0676-4C4B-A42F-D6863E32DCA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 19, 2018, at 10:58, Tim Hollebeek = wrote: >> I agree that the tokens should be one time use, but the I think that = the > only >> way of enforcing it is by generating and unique opaque nonce (the >> ExternalSessionId exchanged on the DTLS setup) and couple it to be > consumed >> only by the PC. >=20 > Yup, after understanding your concern, modifying the API to add a = required > nonce > would be my suggestion, as it expresses the security requirement in a > simple > way that's hard to get wrong. While I agree that adding a nonce would make the assertion stronger = (assuming the nonce value has enough entropy). But who is going to create the nonce in these scenarios? I would guess that often the nonce would get created by the signaling = server. But as far as I understand the potential attack here, the = stealing of the assertion would have to happen exactly on that signaling = path. So if you don=E2=80=99t trust that part of your setup, you should = not trust it to create a unique nonce to improve things. Best Nils Ohlmeier --Apple-Mail=_410D1202-0676-4C4B-A42F-D6863E32DCA9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAlqvmZYACgkQY2o/VmzJ +KG6IhAA2b0DK2psPJN3UJe9z+HXIilrUObPxwdkrnCf/YRGGean5jp5A560hft6 P9j84fLlIUt589HQsFDNGBmy7NsFQo20oo30AMcii2itowTip0mVdio2njlWqVj1 bV5Zom+jchl71p/bUNxYFj+z7RqN+9lWQZokk7FFqw2AVJV2SBoCI3d7kXLm4HIs KE8VRLk2CD+XaWL2NttcQwqERqDczQAXOS0oMgIkZHkJBuAPNaQUwGsgJjJ7Ejhb LOl13ta/qaQYC+zuBMWq3svwDNmaSoVGF2TUa3OM8jprkLDCoc1NEDZcLK5recPj rXpKTmnDCXJpfgQMVJNBt4zAO4rXmTa7+EmEp9uKwrDe4LneDGeyc289IINWGq/f n2wiMPpPqyBmOqndwy5i9Ms6y3vIzt8+vG43EL/2uHAS+rFCXz3xSmfOXPn7wuCn oHV/UQR1b5OC/mCrUB6UWasXHcZWLlSJY7Eh8mQRLFjIWUY60Gkj7vhP3Z8CUezC GqHNsO2EuDmO5eREu8YJeO6vJBnEeRIcrrc6dm5z0ENUOf4y4+J/n39+vZsMDlxz U1ke67arpeGMuwaRnWkoo2KjcNIJCPF/rhW8NXzY2dfDMZiqrCqjHwN554lTObJq ZCeCPaZn9pbzCJSJn5VZzmLFStW+hy/6OAnCsaU//9sNIOeFDCw= =x4sr -----END PGP SIGNATURE----- --Apple-Mail=_410D1202-0676-4C4B-A42F-D6863E32DCA9-- From nobody Mon Mar 19 04:09:37 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C6C12DA07 for ; Mon, 19 Mar 2018 04:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 PN2ZBNWb38SV for ; Mon, 19 Mar 2018 04:09:29 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.198]) (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 B38F71200B9 for ; Mon, 19 Mar 2018 04:09:28 -0700 (PDT) Received: from [216.82.241.100] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-6.bemta-8.messagelabs.com id 43/1D-28268-76A9FAA5; Mon, 19 Mar 2018 11:09:27 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTURzHd+7dvbuVt07T8tdIqFUQmqK9EIq KoFpQkbEgllHXvG2zPezeFRZBhmKl9NSZTnKFZiSaUJKZZDmL3kpr1Cp6WPbSnig9FKrdnfX6 73Pu93u+39/h/jha+5TVcWKOS5Qcgk3PDlUHxzWeTjR7GkzJ/i/Rqfcri1Fq/Y9dmtROTyE7j zZcqwkwhurq75Rh36VCZjltYqyODGfOOsbS3vqTyX6wIOeS96I6F7nnF6KhnBp/pODVTh+lHL TYTUHxzfMacniG4M3jSqYQDeFYnAz3LlylFI7BZshvec4qTOPx0H/CG+ZoPAc6dtZqiGcuPAp 00IRNEDyYH85R40lwO08p4Dgep8O10jTS1UpD26m+cP6Q0N3X75rDmQiPhq836ijSFQsPu71h BhwDXXdusoRHwdsXPxjiT4cjfb7Idz28f1nCEI4Dv7cIKWWAGyk4WRqgiZAIn9zuCC+FgaJbL DH5EfT5g4gI8XDiW7uG8EborrgcmWIWvO1oYciFahruHi2OmMZC2Zn9kep+Bs7mDVNYizOhpN YXaRikILB3r+YAivf88zxPSKOxF0HbQCmrCDweCdfLu9XEFA/u+p4IJ0DNsV6a8CwoG2hjPZF /UlLUpSE8A3qvfEZHEVeLJsuitEWUEqemJGVIVrPFZRestsSU5NQkuyjLglm0CRly0nqn/TQK rdkOlQqdQ82di3xoDEfpR/HOgw0m7fAMZ+ZWiyBb1kqbbaLsQ2M5Tg/83bKQNlISzWLOBqstt Ku/ZeCi9DF8kyLzcrZgl61mIt1A07jA4dcFNBd801tAa9UOp0PUxfLp5SErVqyWzY4/Qb/33o /idNE8UqlU2qhsUbJbXf/rPSiWQ/pofoWSEmV1uP709YRGoUKjLDlep4ziEv5Kulw0vH+Jb32 l9oPx8JPp59vXWpdVzK2LW9z5dM24zIoRU1at2SanLDUmVE00NmQ1QXke6MbfL8j/uKsqa2rj 8uZpk5sODRqw3eu9PDvNGIgy7PEPfjAEx5ySV0umTQn1u3u25670dWEVvKzJHfgyc94EVfMV4 8ICbad6ZQ1dkZXsZvRq2SKkxNOSLPwCbOtoS/IDAAA= X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-13.tower-220.messagelabs.com!1521457766!194599379!1 X-Originating-IP: [216.32.180.178] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19134 invoked from network); 19 Mar 2018 11:09:27 -0000 Received: from mail-bn3nam01lp0178.outbound.protection.outlook.com (HELO NAM01-BN3-obe.outbound.protection.outlook.com) (216.32.180.178) by server-13.tower-220.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 19 Mar 2018 11:09:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YxuH3RSczsx68Tpt2DkLj/r8qUZ2XhqV4EPwH2HlWZw=; b=UnkE5LEClF7cD/b+in0hM3DQQzBqFjq7cTNPsw17WNZpVoBSpKNmDCa/46Bi+c7Lno6jGpLjTWF43TLPWvWB5jz5q8nCcn045ihEX8CT01t6Atc1lfikpMh39F26zoPKAacaDmOw2CFmW+pasZCaIZdHYQjJ/RqOphILsACb1TU= Received: from MWHPR14MB1376.namprd14.prod.outlook.com (10.173.232.139) by MWHPR14MB1743.namprd14.prod.outlook.com (10.171.147.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Mon, 19 Mar 2018 11:09:24 +0000 Received: from MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::7929:3f48:4a4f:1e32]) by MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::7929:3f48:4a4f:1e32%18]) with mapi id 15.20.0588.016; Mon, 19 Mar 2018 11:09:24 +0000 From: Tim Hollebeek To: Nils Ohlmeier , Tim Hollebeek CC: RTCWeb IETF Thread-Topic: [rtcweb] Possible identity security vulnerability Thread-Index: AQHTv2Fbf2/O/UlBVk2jAz9KxqI00qPXTSyAgAAEY4CAAAAskIAAB1QAgAAKAQCAAAKxAIAAAE4w Date: Mon, 19 Mar 2018 11:09:24 +0000 Message-ID: References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> <2AB51FBE-21ED-4BFC-A0F0-A6BCF89B9C5B@mozilla.com> In-Reply-To: <2AB51FBE-21ED-4BFC-A0F0-A6BCF89B9C5B@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [31.133.148.144] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR14MB1743; 7:a4PTfmKoXcgZso4c7CwkxOmnP2IInL2M4RKfvJTqc6h56wbZEb/i+KsnYAgAFpZoLjlNK03Zf2v0quOZG9nLeD8iQnfOONVnV6UPtuhKmv2zZV0zb+Joq4ZG5/IJ+pI0sLUNhrGGTJGf69Gd/SQreYwB0cfAETcWiHfcYznBF5cNOh1bRojL5SjiYo7ilQmlpHz0Ag05ka7UYw61AbcIbbWNQyeM2shfmD/Cb2ehDicLm+dPOC2MtkyVQVHqZen2 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 074a1165-40f8-4735-b4ec-08d58d89dfe7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:MWHPR14MB1743; x-ms-traffictypediagnostic: MWHPR14MB1743: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231221)(944501244)(52105095)(10201501046)(6041310)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:MWHPR14MB1743; BCL:0; PCL:0; RULEID:; SRVR:MWHPR14MB1743; x-forefront-prvs: 06167FAD59 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(39850400004)(396003)(376002)(39380400002)(13464003)(189003)(51444003)(199004)(3660700001)(316002)(93886005)(97736004)(53546011)(6506007)(55016002)(59450400001)(15650500001)(7736002)(305945005)(14454004)(2906002)(5250100002)(74316002)(229853002)(8936002)(81156014)(81166006)(110136005)(68736007)(2900100001)(8676002)(5660300001)(33656002)(186003)(102836004)(26005)(4326008)(105586002)(9686003)(7696005)(25786009)(3280700002)(66066001)(76176011)(2950100002)(99286004)(6436002)(106356001)(6246003)(53936002)(99936001)(6116002)(3846002)(86362001)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR14MB1743; H:MWHPR14MB1376.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ttgu+OiTu68IO70nP4ur6t3XK20n43rczaltfWxEN1GT1M3SSX1/ZTQVEGOuE1I5ct+4VY3LREcmhK24VOnKPefYQjWifNgYFF0tHal20/aKPWRsiFh50y4Bsc2S/2DdIRcILpbh7T/IOFGCF1jZvOZG0nO+4ovcCngSkDA76eWxDAMLDLIet6o0ZacqCN+olUsfQXSwDlftaGx/8RkCyjxe1Tvmcvq4cD7R0wvU2k4c/8pDzLC3EpvfbVBGHWeZWDoiqw7OxwNXZWUQbPqlllDHNjDPH0x/zK+RnWFqjJa73mhX9Cz2oDsaG8KqXdqAR0N1ATMoaAuzq5PZtiDQcA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0425_01D3BF72.BBA7F540" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 074a1165-40f8-4735-b4ec-08d58d89dfe7 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2018 11:09:24.8552 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1743 Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 11:09:33 -0000 ------=_NextPart_000_0425_01D3BF72.BBA7F540 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I would think the IDP would create the nonce, and verify non-reuse. The = IDP=20 is a trusted component in this system. There are almost certainly details that have to be worked out about how exactly that changes the APIs, and that may expose future problems, but that's what I'm currently thinking. Happy to help figure this stuff out since I happen to be familiar with = it now. -Tim > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Nils = Ohlmeier > Sent: Monday, March 19, 2018 11:06 AM > To: Tim Hollebeek > Cc: RTCWeb IETF > Subject: Re: [rtcweb] Possible identity security vulnerability >=20 >=20 >=20 > > On Mar 19, 2018, at 10:58, Tim Hollebeek > wrote: > >> I agree that the tokens should be one time use, but the I think = that > >> the > > only > >> way of enforcing it is by generating and unique opaque nonce (the > >> ExternalSessionId exchanged on the DTLS setup) and couple it to be > > consumed > >> only by the PC. > > > > Yup, after understanding your concern, modifying the API to add a > > required nonce would be my suggestion, as it expresses the security > > requirement in a simple way that's hard to get wrong. >=20 > While I agree that adding a nonce would make the assertion stronger > (assuming the nonce value has enough entropy). >=20 > But who is going to create the nonce in these scenarios? > I would guess that often the nonce would get created by the signaling = server. > But as far as I understand the potential attack here, the stealing of = the > assertion would have to happen exactly on that signaling path. So if = you don=E2=80=99t > trust that part of your setup, you should not trust it to create a = unique nonce > to improve things. >=20 > Best > Nils Ohlmeier ------=_NextPart_000_0425_01D3BF72.BBA7F540 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgwMzE5MTEwOTIxWjAvBgkqhkiG9w0BCQQxIgQgG7aLhUBnlRzNk4CWqRjelT2e7jsW S1gL+FFXl1jpYqswgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBABLwLrWWff6KKoVW0BIuVVxBDpLJ8ti3s7pwJ7fCpIGJnQJbcYNAu2wXno61CBYcL6CBSjGL pAPjbg+n+YCXcrMBEoGgyd/+A+TqWcCzfPOGT93aj9txm+9PjWdmD/XclI+yhvg+xtnSSa0eIbHm xrFQfIfG9W0pF8fQW6vjaQVpWn8V5GWBgI1SamZ0pRg119edTE9fKNNpXL2mtrQm068h9kTxr/6G uC87z95u5IQUHZpy0yQDpwCulHbuVC+32zAZE6THfYSufoqRXJcM1f/QIKld8RQPctQ/v5EzB/Z0 WqyK2gdf6VI3PwTHjalInQsnAE6KosQMaJugMlu8gbQAAAAAAAA= ------=_NextPart_000_0425_01D3BF72.BBA7F540-- From nobody Mon Mar 19 04:09:52 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 858ED12DA6E for ; Mon, 19 Mar 2018 04:09:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1521457777; bh=cHnk7dnGEY35YxxFHIdHTum9SuZun959XbwrLXD891E=; h=From:CC:Subject:Date:References:In-Reply-To:To:To; b=dG8H8zNKMwi+HMYKl+TFY/eDS5ehQnQEkhAfQK9+3lV5cziwRXENwH0xfd+pHKqQO YjefRTRXQrxZpJMtuZz9zw+eLowDOwBXJpLycgzjoVDWBndpG78Wu+chENUOouNvQp wyncjBCOxzMwa3gQZJawo5j7l5DGn3wV6l5TFEU0= X-Mailbox-Line: From tim.hollebeek@digicert.com Mon Mar 19 04:09:34 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1605E12D87D for ; Mon, 19 Mar 2018 04:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1521457774; bh=cHnk7dnGEY35YxxFHIdHTum9SuZun959XbwrLXD891E=; h=From:CC:Subject:Date:References:In-Reply-To:To:To; b=Q6l0881bsvHrRGxxskoIUb+ydG/QUSEM8D29y9Ih8mKpB7cjENpiO6soTbs0MqBzm HIA4bx29lQEURGk/yZ5SScFhWL+l/BUvbZutFdK/BRM0ZbdTBGDdttTAUbvuispU3v t7Ei5AYIh9Q+0FMFI7wP01T8UhL2GFa8XOTOy+RI= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7FE12DA2B for ; Mon, 19 Mar 2018 04:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 Z5Ouzs-12ygK for ; Mon, 19 Mar 2018 04:09:29 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.198]) (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 B8D90127522 for ; Mon, 19 Mar 2018 04:09:28 -0700 (PDT) Received: from [216.82.241.100] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-6.bemta-8.messagelabs.com id 43/1D-28268-76A9FAA5; Mon, 19 Mar 2018 11:09:27 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTURzHd+7dvbuVt07T8tdIqFUQmqK9EIq KoFpQkbEgllHXvG2zPezeFRZBhmKl9NSZTnKFZiSaUJKZZDmL3kpr1Cp6WPbSnig9FKrdnfX6 73Pu93u+39/h/jha+5TVcWKOS5Qcgk3PDlUHxzWeTjR7GkzJ/i/Rqfcri1Fq/Y9dmtROTyE7j zZcqwkwhurq75Rh36VCZjltYqyODGfOOsbS3vqTyX6wIOeS96I6F7nnF6KhnBp/pODVTh+lHL TYTUHxzfMacniG4M3jSqYQDeFYnAz3LlylFI7BZshvec4qTOPx0H/CG+ZoPAc6dtZqiGcuPAp 00IRNEDyYH85R40lwO08p4Dgep8O10jTS1UpD26m+cP6Q0N3X75rDmQiPhq836ijSFQsPu71h BhwDXXdusoRHwdsXPxjiT4cjfb7Idz28f1nCEI4Dv7cIKWWAGyk4WRqgiZAIn9zuCC+FgaJbL DH5EfT5g4gI8XDiW7uG8EborrgcmWIWvO1oYciFahruHi2OmMZC2Zn9kep+Bs7mDVNYizOhpN YXaRikILB3r+YAivf88zxPSKOxF0HbQCmrCDweCdfLu9XEFA/u+p4IJ0DNsV6a8CwoG2hjPZF /UlLUpSE8A3qvfEZHEVeLJsuitEWUEqemJGVIVrPFZRestsSU5NQkuyjLglm0CRly0nqn/TQK rdkOlQqdQ82di3xoDEfpR/HOgw0m7fAMZ+ZWiyBb1kqbbaLsQ2M5Tg/83bKQNlISzWLOBqstt Ku/ZeCi9DF8kyLzcrZgl61mIt1A07jA4dcFNBd801tAa9UOp0PUxfLp5SErVqyWzY4/Qb/33o /idNE8UqlU2qhsUbJbXf/rPSiWQ/pofoWSEmV1uP709YRGoUKjLDlep4ziEv5Kulw0vH+Jb32 l9oPx8JPp59vXWpdVzK2LW9z5dM24zIoRU1at2SanLDUmVE00NmQ1QXke6MbfL8j/uKsqa2rj 8uZpk5sODRqw3eu9PDvNGIgy7PEPfjAEx5ySV0umTQn1u3u25670dWEVvKzJHfgyc94EVfMV4 8ICbad6ZQ1dkZXsZvRq2SKkxNOSLPwCbOtoS/IDAAA= X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-13.tower-220.messagelabs.com!1521457766!194599379!1 X-Originating-IP: [216.32.180.178] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19134 invoked from network); 19 Mar 2018 11:09:27 -0000 Received: from mail-bn3nam01lp0178.outbound.protection.outlook.com (HELO NAM01-BN3-obe.outbound.protection.outlook.com) (216.32.180.178) by server-13.tower-220.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 19 Mar 2018 11:09:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YxuH3RSczsx68Tpt2DkLj/r8qUZ2XhqV4EPwH2HlWZw=; b=UnkE5LEClF7cD/b+in0hM3DQQzBqFjq7cTNPsw17WNZpVoBSpKNmDCa/46Bi+c7Lno6jGpLjTWF43TLPWvWB5jz5q8nCcn045ihEX8CT01t6Atc1lfikpMh39F26zoPKAacaDmOw2CFmW+pasZCaIZdHYQjJ/RqOphILsACb1TU= Received: from MWHPR14MB1376.namprd14.prod.outlook.com (10.173.232.139) by MWHPR14MB1743.namprd14.prod.outlook.com (10.171.147.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Mon, 19 Mar 2018 11:09:24 +0000 Received: from MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::7929:3f48:4a4f:1e32]) by MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::7929:3f48:4a4f:1e32%18]) with mapi id 15.20.0588.016; Mon, 19 Mar 2018 11:09:24 +0000 From: Tim Hollebeek CC: RTCWeb IETF Thread-Topic: [rtcweb] Possible identity security vulnerability Thread-Index: AQHTv2Fbf2/O/UlBVk2jAz9KxqI00qPXTSyAgAAEY4CAAAAskIAAB1QAgAAKAQCAAAKxAIAAAE4w Date: Mon, 19 Mar 2018 11:09:24 +0000 Message-ID: References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> <2AB51FBE-21ED-4BFC-A0F0-A6BCF89B9C5B@mozilla.com> In-Reply-To: <2AB51FBE-21ED-4BFC-A0F0-A6BCF89B9C5B@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [31.133.148.144] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR14MB1743; 7:a4PTfmKoXcgZso4c7CwkxOmnP2IInL2M4RKfvJTqc6h56wbZEb/i+KsnYAgAFpZoLjlNK03Zf2v0quOZG9nLeD8iQnfOONVnV6UPtuhKmv2zZV0zb+Joq4ZG5/IJ+pI0sLUNhrGGTJGf69Gd/SQreYwB0cfAETcWiHfcYznBF5cNOh1bRojL5SjiYo7ilQmlpHz0Ag05ka7UYw61AbcIbbWNQyeM2shfmD/Cb2ehDicLm+dPOC2MtkyVQVHqZen2 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 074a1165-40f8-4735-b4ec-08d58d89dfe7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:MWHPR14MB1743; x-ms-traffictypediagnostic: MWHPR14MB1743: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231221)(944501244)(52105095)(10201501046)(6041310)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:MWHPR14MB1743; BCL:0; PCL:0; RULEID:; SRVR:MWHPR14MB1743; x-forefront-prvs: 06167FAD59 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(39850400004)(396003)(376002)(39380400002)(13464003)(189003)(51444003)(199004)(3660700001)(316002)(93886005)(97736004)(53546011)(6506007)(55016002)(59450400001)(15650500001)(7736002)(305945005)(14454004)(2906002)(5250100002)(74316002)(229853002)(8936002)(81156014)(81166006)(110136005)(68736007)(2900100001)(8676002)(5660300001)(33656002)(186003)(102836004)(26005)(4326008)(105586002)(9686003)(7696005)(25786009)(3280700002)(66066001)(76176011)(2950100002)(99286004)(6436002)(106356001)(6246003)(53936002)(99936001)(6116002)(3846002)(86362001)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR14MB1743; H:MWHPR14MB1376.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ttgu+OiTu68IO70nP4ur6t3XK20n43rczaltfWxEN1GT1M3SSX1/ZTQVEGOuE1I5ct+4VY3LREcmhK24VOnKPefYQjWifNgYFF0tHal20/aKPWRsiFh50y4Bsc2S/2DdIRcILpbh7T/IOFGCF1jZvOZG0nO+4ovcCngSkDA76eWxDAMLDLIet6o0ZacqCN+olUsfQXSwDlftaGx/8RkCyjxe1Tvmcvq4cD7R0wvU2k4c/8pDzLC3EpvfbVBGHWeZWDoiqw7OxwNXZWUQbPqlllDHNjDPH0x/zK+RnWFqjJa73mhX9Cz2oDsaG8KqXdqAR0N1ATMoaAuzq5PZtiDQcA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0425_01D3BF72.BBA7F540" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 074a1165-40f8-4735-b4ec-08d58d89dfe7 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2018 11:09:24.8552 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1743 To: Nils Ohlmeier To: Tim Hollebeek Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 11:09:40 -0000 ------=_NextPart_000_0425_01D3BF72.BBA7F540 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I would think the IDP would create the nonce, and verify non-reuse. The = IDP=20 is a trusted component in this system. There are almost certainly details that have to be worked out about how exactly that changes the APIs, and that may expose future problems, but that's what I'm currently thinking. Happy to help figure this stuff out since I happen to be familiar with = it now. -Tim > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Nils = Ohlmeier > Sent: Monday, March 19, 2018 11:06 AM > To: Tim Hollebeek > Cc: RTCWeb IETF > Subject: Re: [rtcweb] Possible identity security vulnerability >=20 >=20 >=20 > > On Mar 19, 2018, at 10:58, Tim Hollebeek > wrote: > >> I agree that the tokens should be one time use, but the I think = that > >> the > > only > >> way of enforcing it is by generating and unique opaque nonce (the > >> ExternalSessionId exchanged on the DTLS setup) and couple it to be > > consumed > >> only by the PC. > > > > Yup, after understanding your concern, modifying the API to add a > > required nonce would be my suggestion, as it expresses the security > > requirement in a simple way that's hard to get wrong. >=20 > While I agree that adding a nonce would make the assertion stronger > (assuming the nonce value has enough entropy). >=20 > But who is going to create the nonce in these scenarios? > I would guess that often the nonce would get created by the signaling = server. > But as far as I understand the potential attack here, the stealing of = the > assertion would have to happen exactly on that signaling path. So if = you don=E2=80=99t > trust that part of your setup, you should not trust it to create a = unique nonce > to improve things. >=20 > Best > Nils Ohlmeier ------=_NextPart_000_0425_01D3BF72.BBA7F540 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgwMzE5MTEwOTIxWjAvBgkqhkiG9w0BCQQxIgQgG7aLhUBnlRzNk4CWqRjelT2e7jsW S1gL+FFXl1jpYqswgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBABLwLrWWff6KKoVW0BIuVVxBDpLJ8ti3s7pwJ7fCpIGJnQJbcYNAu2wXno61CBYcL6CBSjGL pAPjbg+n+YCXcrMBEoGgyd/+A+TqWcCzfPOGT93aj9txm+9PjWdmD/XclI+yhvg+xtnSSa0eIbHm xrFQfIfG9W0pF8fQW6vjaQVpWn8V5GWBgI1SamZ0pRg119edTE9fKNNpXL2mtrQm068h9kTxr/6G uC87z95u5IQUHZpy0yQDpwCulHbuVC+32zAZE6THfYSufoqRXJcM1f/QIKld8RQPctQ/v5EzB/Z0 WqyK2gdf6VI3PwTHjalInQsnAE6KosQMaJugMlu8gbQAAAAAAAA= ------=_NextPart_000_0425_01D3BF72.BBA7F540-- From nobody Mon Mar 19 04:10:34 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631C112D875 for ; Mon, 19 Mar 2018 04:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Y3W2GdffUBsR for ; Mon, 19 Mar 2018 04:10:31 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 0193812D870 for ; Mon, 19 Mar 2018 04:10:24 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id a189so6961254oii.2 for ; Mon, 19 Mar 2018 04:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=h4RRrefNiTa2m6Saxe9KjF4GD7S1qeLH8CjAHbMwnx8=; b=WsXXm95X9IG7HLIrgARpp1CY4Ihz09+eXOCITgaGllKkJXtOlpOEjTI/zhGab/AUyd i0vyeWN+UxTHkTOyz7ERSHMhskba8EJpnBKbajWtz8HLM0/7gZ8R0Lh1rCLqTB8I5X2E nyFiuU6xHTNnHzsY/316lFPhXt6JH804+tpAfXo6MfQi67d8ILX9onCkjjpT65HtzIVG VWTb5yOaphejXAiINe/n+eLIveEj2uFLEVoc8SeIFpdJ6ehiU1DdFLLyTHynLWoTgjjA 3RUSFZz9RqZC7PIqpsogMeUO68HazagnZdXkRfOrytNptpBpN07pio5M3MpCaf2BNfGg mmtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=h4RRrefNiTa2m6Saxe9KjF4GD7S1qeLH8CjAHbMwnx8=; b=KT4OmgtCJLbe9mKC4gDVAmyffA0xujruN0MVeXjp9ymxX2wpF39+MmPoRFHLada+kf 86TZh/rheQ1XKMQRfo0ej9iypy3o0VrVXwSxXAqjBkMMBSkH1QNBS36AsZZDDvDxAC7W SVRfDB0R77DEdP54kw3E6UoLsXf9v/mCveEHyxRDEXD2HFB0iEEmhfdtpdtL4aykSgKk MPYgkx2uuT2eRGPi5573Cq/hic29s6yXac9Ham51y7Qy8bj+1OoKV3V87ZhKUarN0Mz2 JNU81cvWENW3kVrTT6+yQkSwaSYp7XYGRsrf8+FP67XWe5ucyeWMbDZBOpfL2iUYDIy2 ZKPw== X-Gm-Message-State: AElRT7EYeA1fAtbzPV0aST1woOLBm78ER3vvE/yIN4RcGdrpTtYmTbWQ gRRFl5PVkbE+d1H1SqgrFB7cjVvs7fuV4LjyC70= X-Google-Smtp-Source: AG47ELt9+tGfdla1J/XekXcCYuzGyn/APrLZW7adEyJ8rWoz00OP5pM12OYHiQaE7E9ijgfSLkVhOf0BY46CCFwvx/o= X-Received: by 10.202.56.87 with SMTP id f84mr6349768oia.254.1521457823287; Mon, 19 Mar 2018 04:10:23 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Mon, 19 Mar 2018 04:10:22 -0700 (PDT) In-Reply-To: References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> From: Martin Thomson Date: Mon, 19 Mar 2018 11:10:22 +0000 Message-ID: To: Tim Hollebeek Cc: Sergio Garcia Murillo , RTCWeb IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 11:10:32 -0000 On Mon, Mar 19, 2018 at 10:58 AM, Tim Hollebeek wrote: > Yup, after understanding your concern, modifying the API to add a required > nonce > would be my suggestion, as it expresses the security requirement in a > simple > way that's hard to get wrong. FWIW, in the common case, there is a nonce: the certificate. That is generally unique to a RTCPeerConnection instance. From nobody Mon Mar 19 04:10:44 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9960112D870 for ; Mon, 19 Mar 2018 04:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1521457833; bh=ijbDTeNR9Qe62eHbOoRTmEIRND6Qft186/pAfXzce4Y=; h=Subject:Cc:References:From:Date:In-Reply-To:To:To; b=PbUroYwf5B0TTwq3h5jOIxAP3xmsBOjMOJgxCBIso+8Q+4NeDfTPKTtWI/20KZ/13 N3U1IZdlHaD1uYMJh/S1RsKA8lP91QL3W4MilHXtxQ4CUXsyLAsbs/cvjMIh1ujj/w Tfa9mVQYNvc2ReFTocG5Giyev0GwjOoaCMPMOBx0= X-Mailbox-Line: From sergio.garcia.murillo@gmail.com Mon Mar 19 04:10:33 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B10B127522; Mon, 19 Mar 2018 04:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1521457833; bh=ijbDTeNR9Qe62eHbOoRTmEIRND6Qft186/pAfXzce4Y=; h=Subject:Cc:References:From:Date:In-Reply-To:To:To; b=PbUroYwf5B0TTwq3h5jOIxAP3xmsBOjMOJgxCBIso+8Q+4NeDfTPKTtWI/20KZ/13 N3U1IZdlHaD1uYMJh/S1RsKA8lP91QL3W4MilHXtxQ4CUXsyLAsbs/cvjMIh1ujj/w Tfa9mVQYNvc2ReFTocG5Giyev0GwjOoaCMPMOBx0= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A64C12D870 for ; Mon, 19 Mar 2018 04:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 DP-IPGm3yBhI for ; Mon, 19 Mar 2018 04:10:32 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 F1AA0127522 for ; Mon, 19 Mar 2018 04:10:23 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id s206so12146045wme.0 for ; Mon, 19 Mar 2018 04:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=VgQ6GuoO5o497cIxfzmmYd4ASNLp8WcPgeCzZKJx/RE=; b=MvRsFtgu7mfqbe23csecQMTsoPehmwqCPIhHOHS0KxjaGHJ1htC8yxmE2tFmW42LgU go0xl+Ctzl3Xaae0uWhePA2YyJxXqr9cgjtGSc4Fnf5FdL48rr3LFoLyHN29DKT3l0Q+ gcA+mvTAskKuaSua8t3anXrsNp4MzJf2fleQNyQ/8iWoIpVIl5nzEErCzEMg+xk75osA B5EYNdTjnxIZcVMspWPMBf8KwckZQygc9TronlNtnG1emKYecE7nJCXbE7I+nWjAIAov VVRz1Qb3dNZfLMXGbD7Rl6Gl3XcVJDMdA2bDJo9QmO3Q1YHYx5RpB7qWAFTbJ9/Au3oc dt0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=VgQ6GuoO5o497cIxfzmmYd4ASNLp8WcPgeCzZKJx/RE=; b=WpBO8R9lNmu5/oNpozYraDUIOY6pKrcKsD9nyuYI/ZB9FD+lNBZrjGepTeY8TkY7Vg BqpxvKV1kpLEs5+PAH8adnmpci8TNfotY/cOQZUQvrQ67VfEORsLao2FBFFLoQLVnqTy 6+LmyO0M8elvVM3em3rUAOULpJ6hwqgQUvhL785MzI17yaD0rwdx3t9Qt3p5wGWbFh5s JhvkVCZDat48Pw6y0WQ4irBMy4eCInh7mL7L0yBo9LW3zufMJgOwReqlZbjr0RGJTigC Sq800Cv2+SglHreexn2T00I6S/mqZh992Rn133KQsaJ0MFCqSrPYN9sZB3j0EgObWAq+ Qbeg== X-Gm-Message-State: AElRT7HAi2oelC+NsRU3sOvprKdleTp3EHB8E0AGa+kNoxVNHJiEIL43 TcCLnaHuhIb0NZNn+cJCnE4Zwn9m X-Google-Smtp-Source: AG47ELuhVSWYzJd4KQjvwa4KI2WHPTMqCIP38Af/wcE2ZA7YMo4Z1Rj2ZyHw6Xtk0moIWmSZWsPSzQ== X-Received: by 10.80.192.1 with SMTP id r1mr12965416edb.222.1521457822478; Mon, 19 Mar 2018 04:10:22 -0700 (PDT) Received: from [192.168.0.101] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id v9sm56826edi.16.2018.03.19.04.10.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 04:10:21 -0700 (PDT) Cc: Martin Thomson , RTCWeb IETF References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> <2AB51FBE-21ED-4BFC-A0F0-A6BCF89B9C5B@mozilla.com> From: Sergio Garcia Murillo Message-ID: <01843e44-25ff-f834-e38e-59f7a34746f2@gmail.com> Date: Mon, 19 Mar 2018 12:10:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <2AB51FBE-21ED-4BFC-A0F0-A6BCF89B9C5B@mozilla.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US To: Nils Ohlmeier To: Tim Hollebeek Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 11:10:34 -0000 On 19/03/2018 12:05, Nils Ohlmeier wrote: >> On Mar 19, 2018, at 10:58, Tim Hollebeek wrote: >>> I agree that the tokens should be one time use, but the I think that the only way of enforcing it is by generating and unique opaque nonce (the ExternalSessionId exchanged on the DTLS setup) and couple it to be consumed only by the PC. >> Yup, after understanding your concern, modifying the API to add a required nonc would be my suggestion, as it expresses the security requirement in a simple way that's hard to get wrong. > While I agree that adding a nonce would make the assertion stronger (assuming the nonce value has enough entropy). > > But who is going to create the nonce in these scenarios? > I would guess that often the nonce would get created by the signaling server. But as far as I understand the potential attack here, the stealing of the assertion would have to happen exactly on that signaling path. So if you don’t trust that part of your setup, you should not trust it to create a unique nonce to improve things. > The nonce should generated internally by the PC and exchanged on the dtls setup via the ExternalSessionId field from the sdp-uks draft. That way the remote PC will be able to access the nonce and pass it to the validate assertion call. Best regards Sergio From nobody Mon Mar 19 04:10:48 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E54D12D870 for ; Mon, 19 Mar 2018 04:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 wLQvX5aqiLNq for ; Mon, 19 Mar 2018 04:10:32 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 34AF912D871 for ; Mon, 19 Mar 2018 04:10:24 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id a20so12138912wmd.1 for ; Mon, 19 Mar 2018 04:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=VgQ6GuoO5o497cIxfzmmYd4ASNLp8WcPgeCzZKJx/RE=; b=MvRsFtgu7mfqbe23csecQMTsoPehmwqCPIhHOHS0KxjaGHJ1htC8yxmE2tFmW42LgU go0xl+Ctzl3Xaae0uWhePA2YyJxXqr9cgjtGSc4Fnf5FdL48rr3LFoLyHN29DKT3l0Q+ gcA+mvTAskKuaSua8t3anXrsNp4MzJf2fleQNyQ/8iWoIpVIl5nzEErCzEMg+xk75osA B5EYNdTjnxIZcVMspWPMBf8KwckZQygc9TronlNtnG1emKYecE7nJCXbE7I+nWjAIAov VVRz1Qb3dNZfLMXGbD7Rl6Gl3XcVJDMdA2bDJo9QmO3Q1YHYx5RpB7qWAFTbJ9/Au3oc dt0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=VgQ6GuoO5o497cIxfzmmYd4ASNLp8WcPgeCzZKJx/RE=; b=EfMQCKfq8pPxjWqztKFotxvRrN324x3UXEIHGReMjnICbbxbrCvgXQBEGwHwPjf7K5 Oh2KKMDEvpTFGYWcGMtRQjp/kr2G7Ob7gXjWzDlNcJizai4kfXjSN1xwMdF892RiQX4M Ft5kjTncHTrV+je5tEa1alVjhB4Hg6fBqUjBkQ2T3EaqjEB+2pOjbgi7qa5HDYlOEo6N IJOHg+s7KuVAbRp1dVj50UXWCUsLxi23WMFgAZhCS81UsC1SsdG6PmLHp5lpT1JO8+48 V1PRpzfZF8+zNuN8B7b900L4GyWHGbyxp5e6/z+i7052/cs4PubW/dOAc9u1JemtZkr4 XbFw== X-Gm-Message-State: AElRT7EdlDP7anUbaW9oCnB9a6QWvib7gaGr9hgNj4EnaQrg5O1b/f9P mRllNFBb/3BnkhRHomJweyGTQ50x X-Google-Smtp-Source: AG47ELuhVSWYzJd4KQjvwa4KI2WHPTMqCIP38Af/wcE2ZA7YMo4Z1Rj2ZyHw6Xtk0moIWmSZWsPSzQ== X-Received: by 10.80.192.1 with SMTP id r1mr12965416edb.222.1521457822478; Mon, 19 Mar 2018 04:10:22 -0700 (PDT) Received: from [192.168.0.101] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id v9sm56826edi.16.2018.03.19.04.10.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 04:10:21 -0700 (PDT) To: Nils Ohlmeier , Tim Hollebeek Cc: Martin Thomson , RTCWeb IETF References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> <2AB51FBE-21ED-4BFC-A0F0-A6BCF89B9C5B@mozilla.com> From: Sergio Garcia Murillo Message-ID: <01843e44-25ff-f834-e38e-59f7a34746f2@gmail.com> Date: Mon, 19 Mar 2018 12:10:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <2AB51FBE-21ED-4BFC-A0F0-A6BCF89B9C5B@mozilla.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 11:10:35 -0000 On 19/03/2018 12:05, Nils Ohlmeier wrote: >> On Mar 19, 2018, at 10:58, Tim Hollebeek wrote: >>> I agree that the tokens should be one time use, but the I think that the only way of enforcing it is by generating and unique opaque nonce (the ExternalSessionId exchanged on the DTLS setup) and couple it to be consumed only by the PC. >> Yup, after understanding your concern, modifying the API to add a required nonc would be my suggestion, as it expresses the security requirement in a simple way that's hard to get wrong. > While I agree that adding a nonce would make the assertion stronger (assuming the nonce value has enough entropy). > > But who is going to create the nonce in these scenarios? > I would guess that often the nonce would get created by the signaling server. But as far as I understand the potential attack here, the stealing of the assertion would have to happen exactly on that signaling path. So if you don’t trust that part of your setup, you should not trust it to create a unique nonce to improve things. > The nonce should generated internally by the PC and exchanged on the dtls setup via the ExternalSessionId field from the sdp-uks draft. That way the remote PC will be able to access the nonce and pass it to the validate assertion call. Best regards Sergio From nobody Mon Mar 19 04:21:33 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E4E127077 for ; Mon, 19 Mar 2018 04:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 NxGzlL5rIFOh for ; Mon, 19 Mar 2018 04:21:30 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.13]) (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 68735126FDC for ; Mon, 19 Mar 2018 04:21:30 -0700 (PDT) Received: from [216.82.249.212] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-13.bemta-12.messagelabs.com id D8/0F-26056-93D9FAA5; Mon, 19 Mar 2018 11:21:29 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTYRjG952zy9Fcnabm20is0Y3hJA3BCrp DkglGf2l2OcvTznAX2ZllBLX+qTRCrVm6KVNTStOsFK0kqEUXK22aSVqBQ02dSUZFZDU7Z2d2 +e/H9zzf87zfx0vgin6pkqDzrLTFRBlU0lDx68Ut4Zo1FU0Zq6o8c5L6nvtRUqP/lCxpxN+Gb 8STbzveyZJrar5jaViGRG/SmvP2S5gv3TY8x7kp70p+odSGPOsLUCghJj9iYOv0YQUohFCQFz BwdUh4QUEOInC2t4t5QUqugr67jwOmCFID1Z2DMp5xcjc8L29FPIeT66HrRL1M8GyAN71duMA Z0H/uFRdKcG3L4PuXQIyczIQn104hocuDw938sUBXCLkTRh85AyZELoBvTxswoSsKBoZdAQYy Arzdz6QCR8L4kF8i+DOh4rM7eK6CyRG7ROBo6HGdCZQB2YJBy9e3wSANTJWU4PxwQKbCL1ea4 OlB8KpoKBikhqL+08GgbPAOfA1yChTM8GX8hRocvNPfkCAsgtLmQokgzEhgvKpVKvxvFtjrZ2 /8wGDw5Vm8CKkd/zzPwWk46ULQfKkOOQIfNR86yobFgkkNJY2+IMdA22Q5LvA6KJ2+LxV4Cdj PeGUCJ8LEw0+oEhH1aCVLWw7RFk1CYpzWotcxViOlN2ji4xPijDTLUjraQGnZuANm403ELdhx kQjdQi0ntrvRQgJTRcrNxU0Zirlac9YRhmKZfZZcA8260SKCUIGcLue0+RZaR+cd1Bu4LZ2Vg QhTRcg7nZwsZ3MoI6vXCdJTtJrovTh6Eidej02cxBVik9lEK6PkP3kryVuZXNOfoNmN70HRyn A5EolEirAc2mLUW//XfSiKQKpwuZafJ0xvsv7p83GjYNwoO2ob+FGs1F9JaUNaO7H23b6+maz K9F3NHo/e6GCckQfRuo6h+/CCsbpTYtekpPq2Dhwbim+c2ave1nQn+uLh4uL0paXZyu7J5DFv 3Wb3m1j/kXm2zKrY3ebrD2znb1R9APCEfC5dcXTg6tubussenWyaed8bZVIs3hDT3rZleW112 dQe+73uEVuRSswyVLwat7DUb9Ob1/fsAwAA X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-8.tower-219.messagelabs.com!1521458488!184575992!1 X-Originating-IP: [216.32.180.19] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20202 invoked from network); 19 Mar 2018 11:21:29 -0000 Received: from mail-sn1nam02lp0019.outbound.protection.outlook.com (HELO NAM02-SN1-obe.outbound.protection.outlook.com) (216.32.180.19) by server-8.tower-219.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 19 Mar 2018 11:21:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cYib4JIdWGOjkJsNOpVaTgTGq0eMH3FAVnSb/j5Is1o=; b=mgA57ABZ9DnXcqhcS4mugKwLwYoto6K1/KemnutzXrAGH9Rid2jfZu0dYfKXlgYGI14DMLmS+R72WK8Tg9mGa8AE1YArv4b3x52sB3LInKJSOoC6otBrajbUkaYMYBlck0LZ+ABLDPFRiAZG12bRl7cbDxqeGqT50H1meSMBtNc= Received: from MWHPR14MB1376.namprd14.prod.outlook.com (10.173.232.139) by MWHPR14MB1325.namprd14.prod.outlook.com (10.173.102.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Mon, 19 Mar 2018 11:21:27 +0000 Received: from MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::7929:3f48:4a4f:1e32]) by MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::7929:3f48:4a4f:1e32%18]) with mapi id 15.20.0588.016; Mon, 19 Mar 2018 11:21:27 +0000 From: Tim Hollebeek To: Martin Thomson CC: Sergio Garcia Murillo , RTCWeb IETF Thread-Topic: [rtcweb] Possible identity security vulnerability Thread-Index: AQHTv2Fbf2/O/UlBVk2jAz9KxqI00qPXTSyAgAAEY4CAAAAskIAAB1QAgAAKAQCAAAPsAIAAARHA Date: Mon, 19 Mar 2018 11:21:27 +0000 Message-ID: References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [31.133.148.144] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR14MB1325; 7:8otlTQ2PWbjo0rBxMOncXJ/wV7KLORsT7C8vNQirI6Fz1mL3ok1pmvqQJaWLxj1X9pQTw4W2ZzCa0GexaxE46E1hwQhyp8rD5LIaU+HXo6U72T6ggAkjZ9+uSs7qxLr43sOXhim0q0UGCizA3ZDABXf+qf3mN83z2BGbEoe07lXBx+lnSJXCCzXiBRwOtJzohZtYvwY1o3zhhwrDOqKXTe3QJxa6cyxkCYqDX/nuLfH83mzhHDqFnirYNFw0s9RP x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: a41e74c7-4e89-4278-e9aa-08d58d8b8e6b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:MWHPR14MB1325; x-ms-traffictypediagnostic: MWHPR14MB1325: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231221)(944501244)(52105095)(10201501046)(6041310)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:MWHPR14MB1325; BCL:0; PCL:0; RULEID:; SRVR:MWHPR14MB1325; x-forefront-prvs: 06167FAD59 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(346002)(39380400002)(39850400004)(396003)(13464003)(189003)(199004)(2906002)(25786009)(4326008)(26005)(3660700001)(6506007)(53546011)(97736004)(106356001)(6116002)(3280700002)(54906003)(2950100002)(6916009)(186003)(2900100001)(316002)(5660300001)(59450400001)(229853002)(102836004)(86362001)(39060400002)(99286004)(8676002)(81156014)(81166006)(66066001)(6436002)(55016002)(53936002)(15650500001)(8936002)(14454004)(76176011)(68736007)(74316002)(105586002)(305945005)(93886005)(99936001)(3846002)(478600001)(33656002)(7736002)(6246003)(9686003)(7696005)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR14MB1325; H:MWHPR14MB1376.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: vjuatiFyKe7V7ffTvf9M+9oiGDKS+O3eFVOy+UsKJKzkLsyBm9VxVda8R1+XoNpmSwQqi62yBG6vZgD3i25eKtVXAZiZ7OHnALc+o/HfzoJvWMZGMDd1c3E4Hr4xI97fs3P6YIOhrHbBIIWnbc6pTtQE1TTj2UCBofZ+6xMbR2SBljOsjb7sTDMCzrYXLV2Hy82rfp5F3GUNAFcaBAVwcE2EqREHQ/9dj6NTgzIkWpPF1tY1u6RNfqqdOy8AKPtICyQ9t2Rl+Dazx6Ccx9003PrRo/ND0c7liA1twfvBBSiaBht5iUgc9fqynK9zpo1y4t9gWAIhay0GN0OAu8ws/Q== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0435_01D3BF74.6A28D9D0" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: a41e74c7-4e89-4278-e9aa-08d58d8b8e6b X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2018 11:21:27.1106 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1325 Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 11:21:32 -0000 ------=_NextPart_000_0435_01D3BF74.6A28D9D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Well, generally unique ... but not enforced, right? The fact that it is unique in the common case does not give me warm fuzzies when analyzing its security properties. We have to think about not only uncommon cases, but malicious cases. That said, your point is interesting, and I think it may at least limit what you can do with token re-use, for example, only re-create a connection back to the original originator instead of an arbitrary one, as no one else has the right fingerprint. But even that seems like something worth preventing. -Tim > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Monday, March 19, 2018 11:10 AM > To: Tim Hollebeek > Cc: Sergio Garcia Murillo ; RTCWeb IETF > > Subject: Re: [rtcweb] Possible identity security vulnerability > > On Mon, Mar 19, 2018 at 10:58 AM, Tim Hollebeek > wrote: > > Yup, after understanding your concern, modifying the API to add a > > required nonce would be my suggestion, as it expresses the security > > requirement in a simple way that's hard to get wrong. > > FWIW, in the common case, there is a nonce: the certificate. That is > generally > unique to a RTCPeerConnection instance. ------=_NextPart_000_0435_01D3BF74.6A28D9D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgwMzE5MTEyMTI0WjAvBgkqhkiG9w0BCQQxIgQga84NfTyGuM0sSpJ22LD7RiQBLHYd kJE6xoCOdu1V/0YwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAG19gV5BF7c9ZRXQlLowvSjmpEhkxAIvzQOe4zYn/Neq1ZCq7JFU9QumRsqlv2aLEGVf4cCo zQ0GKOzizt2om4plbVGoZzh/AxOH29pO/8V71Hli6rk+JC06krj7aYNYDE5lgQIOeDCUIHb7JXPH NFu32r7elE8pBh+ONlDpEqai4xvlyMpVONNas6iBWnDyWq6SJ6g4Q+Y5EK0JvzYT8ZlsgkHcU6Go 6MHcEoc7Z2aVU9R14VO0VyEpfsGcOD9X4RN3ZP4OkiAqisi66T1/hJISQSXsvqAL7gS5HOgqkfEY jf1qMLoZASI5uFTsUC6fUDiHCXGGt8m5/xg9YGVucPsAAAAAAAA= ------=_NextPart_000_0435_01D3BF74.6A28D9D0-- From nobody Mon Mar 19 04:24:02 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDAD1275F4 for ; Mon, 19 Mar 2018 04:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 WtdCw3K1KZ9D for ; Mon, 19 Mar 2018 04:23:59 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 4FB54127077 for ; Mon, 19 Mar 2018 04:23:59 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id f125so6536732wme.4 for ; Mon, 19 Mar 2018 04:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=V9uFR6oiLwWrXCOKmV80eOzIzkygdQVp6JNUH2MVFcY=; b=vb/WqhVz3Vz2JmS0mwaXd4/M5yyFH9k/t7rvcSynBpbNrLIiljaYcWxV5c6e754Jli JGHe/1OpbkFYOcoVnwOdkpJ1BdZgAgnRvt4Hkf1BQzCFLmBL4NDFcpx5FdSmn0P7wYf+ bvlhRjBhHlVCFhB4zMOkK3OR8Up5+bcSmvXu8/qZmlW47JX53faTDiNjJtiY4JvVI2nD MWumClH6e6Bv+kjxczhEJ1O6KbWkZNksqNzD69VhsAyzZrouxKENwe44JloVD7WISWL2 ZB0vvWS8gNsm7Ub/p6jm0uQnV4VKDOR9WlW7EQfRyhZI0F0TQ5/WYXM1pfq3mX608S+M Hwsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=V9uFR6oiLwWrXCOKmV80eOzIzkygdQVp6JNUH2MVFcY=; b=gcIeh0PuscvIyetepLgsF4ejtDNW3ivU/A0j21Ng2nbZ5cqF///Z4uV2U1krFs4MaK mB0vgwX6129glAvCG+q9mRLGGm1ZPhvACRkmzyt3ULQi4Mfxc/tmrk0bQkI54WABiNX1 xNzMaMdpGQ67DuGyU7dmFCAGmat4ez/xYi77rp4povCfGej5lyYNzyZekfPTvD8IspaG eTeJuryPbrPguric7NVvNGu1cde0+sSM+bARrhkPQ3V1lpD/AozrHQsu77stB6glGN0u 8Ha0M7L0888EP1qgm3BiB3MSzSjxftlRGfFTDyF+ZuWeK5nzRRQYp6M9reyucsqarytO lgOA== X-Gm-Message-State: AElRT7HTnpKT/PrRGw9UZS8dvzQzUxPUKH+PwtXRPWVGYCZUVSd883s3 T5jt9cV+wqKn2jgSQL18yVTBfsw7 X-Google-Smtp-Source: AG47ELunK6Ne/V8otC/mIuJZUjIYhcraOnCGdAnay1aTXyH/+VVNFqCsGjZdLMnG1VvVTeDBfEkdQQ== X-Received: by 10.80.153.24 with SMTP id k24mr1628483edb.45.1521458637540; Mon, 19 Mar 2018 04:23:57 -0700 (PDT) Received: from [192.168.0.101] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id q7sm41510edl.92.2018.03.19.04.23.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 04:23:56 -0700 (PDT) To: Martin Thomson , Tim Hollebeek Cc: RTCWeb IETF References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> From: Sergio Garcia Murillo Message-ID: Date: Mon, 19 Mar 2018 12:23:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4F874763FDAE07AE68A34B91" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 11:24:01 -0000 This is a multi-part message in MIME format. --------------4F874763FDAE07AE68A34B91 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 19/03/2018 12:10, Martin Thomson wrote: > On Mon, Mar 19, 2018 at 10:58 AM, Tim Hollebeek > wrote: >> Yup, after understanding your concern, modifying the API to add a required >> nonce >> would be my suggestion, as it expresses the security requirement in a >> simple >> way that's hard to get wrong. > FWIW, in the common case, there is a nonce: the certificate. That is > generally unique to a RTCPeerConnection instance. But it can be saved and reused: https://www.w3.org/TR/webrtc/#dom-rtcconfiguration     This option allows applications to establish key continuity. An|RTCCertificate|can be persisted in [INDEXEDDB ] and reused. Persistence and reuse also avoids the cost of key generation. Best regards Sergio --------------4F874763FDAE07AE68A34B91 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 19/03/2018 12:10, Martin Thomson wrote:
On Mon, Mar 19, 2018 at 10:58 AM, Tim Hollebeek
<tim.hollebeek@digicert.com> wrote:

Yup, after understanding your concern, modifying the API to add a required
nonce
would  be my suggestion, as it expresses the security requirement in a
simple
way that's hard to get wrong.

FWIW, in the common case, there is a nonce: the certificate.  That is
generally unique to a RTCPeerConnection instance.

But it can be saved and reused:

https://www.w3.org/TR/webrtc/#dom-rtcconfiguration

    This option allows applications to establish key continuity. An RTCCertificate can be persisted in [INDEXEDDB] and reused. Persistence and reuse also avoids the cost of key generation.

Best regards

Sergio

--------------4F874763FDAE07AE68A34B91-- From nobody Mon Mar 19 04:30:38 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A3612D77D for ; Mon, 19 Mar 2018 04:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1521459036; bh=8L0KoFFw80J4s9O8YpEUBQNG50vFr/P6a2+EgnnRBoo=; h=Subject:From:Cc:References:Date:In-Reply-To:To:To; b=LPmJrafKoYaF/WZpFC3hhPq6idgvjD7Xh106fgSVWcGt4Y85uv7m6/ecYUo2gbRvV DTeLwD0eChIrVpbxM0iLtMLMNvla9N+jPlV5UW17IGMv3MLY4WVBmr+a2mgF8sFlhg we3fcvSTB7FJJoyoPM1cg+TET2Dc7HvMJotBqfB8= X-Mailbox-Line: From sergio.garcia.murillo@gmail.com Mon Mar 19 04:30:36 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2B3127867; Mon, 19 Mar 2018 04:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1521459036; bh=8L0KoFFw80J4s9O8YpEUBQNG50vFr/P6a2+EgnnRBoo=; h=Subject:From:Cc:References:Date:In-Reply-To:To:To; b=LPmJrafKoYaF/WZpFC3hhPq6idgvjD7Xh106fgSVWcGt4Y85uv7m6/ecYUo2gbRvV DTeLwD0eChIrVpbxM0iLtMLMNvla9N+jPlV5UW17IGMv3MLY4WVBmr+a2mgF8sFlhg we3fcvSTB7FJJoyoPM1cg+TET2Dc7HvMJotBqfB8= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F9A12D777 for ; Mon, 19 Mar 2018 04:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 7JAzlX5NTygr for ; Mon, 19 Mar 2018 04:30:34 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 5417A127867 for ; Mon, 19 Mar 2018 04:30:34 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id t7so1628331wmh.5 for ; Mon, 19 Mar 2018 04:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=FNy325Y3eUZcwnApTARzpwOAfggcv0wIIhGjbePVXa4=; b=Nn259XeCh1OjBVZJZI80kk6eBIXBwjWtB0mnlQg346QHVgLsENrh442zhSCiEsp6dj Q6gOm2LMEi4OrdUzyfaxs9QwdGF5EFzwShaMjjd7wi+UuH3M3z1GfUIlRaIQQBAx21Mt ZrdO32BDClSNpjO3khd1HiSrG1xDhLg+fxCDbIz9XLytKVE+YAdcg674cSln8P7C8zU3 cTjoUs73fYMRPxACtpWAInbDSExoV0U3qBvrsqHieeNpNjvc6MFEpRFj0DdOWC46JkLR p5x+nI+MEx/y89BKlzuSD+P0Xba+34/sYPA5AoheQROX6VGIFaUdEGpN3WXg6sJ4o7fk tH1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=FNy325Y3eUZcwnApTARzpwOAfggcv0wIIhGjbePVXa4=; b=rEhCMnVH7yudHbaRrEi7iHsoAq5WQQwYkcLohaKcmzDSnxPpUY9Z0XstJALEtjTC5t rMwZx7lQIFZxm2UcpfSzbF22PIETdvN9yCxGcRcKOTSPqkOsdhy7uvvhY4OnEc998/pV YlfR9K3yoheB183oYvTMSdhcg0WQMTAx/AN2uW52w1NF0822hB9TvcPgthwpFfOod0Hg nHeabkFz8+u8mO1vqOAKF9s7NmXz71a/514bC8GhfKAyhH93ks0nnX/5qTPNVCaR7XVB Y3cvWA4f8C/DkAfxSlA1eiSKpDEz4Bt/6X4wJziTvKaIL11Or9Y4Ei5sckA+mn9R20+S ivBQ== X-Gm-Message-State: AElRT7EiEYs3bj5lHoAE1D2cDBzeR2pwY0avXHmkbR2z5a+M4dJFMCpM gsC9yY8aEC4Q2wZT6KmwXY7Srz4C X-Google-Smtp-Source: AG47ELtgJ51FwLBhuzJbY+4XWQ6KpVTJhdSSrehAink++moT/ZU3RIArb4yJpjBIZBVglbShAunBMA== X-Received: by 10.80.227.194 with SMTP id c2mr12918463edm.195.1521459032828; Mon, 19 Mar 2018 04:30:32 -0700 (PDT) Received: from [192.168.0.101] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id a10sm56690eda.71.2018.03.19.04.30.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 04:30:31 -0700 (PDT) From: Sergio Garcia Murillo Cc: Martin Thomson , RTCWeb IETF References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> <2AB51FBE-21ED-4BFC-A0F0-A6BCF89B9C5B@mozilla.com> <01843e44-25ff-f834-e38e-59f7a34746f2@gmail.com> Message-ID: <48913ef9-920f-af9c-c02e-1cda51da0750@gmail.com> Date: Mon, 19 Mar 2018 12:30:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <01843e44-25ff-f834-e38e-59f7a34746f2@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US To: Nils Ohlmeier To: Tim Hollebeek Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 11:30:37 -0000 On 19/03/2018 12:10, Sergio Garcia Murillo wrote: > On 19/03/2018 12:05, Nils Ohlmeier wrote: >>> On Mar 19, 2018, at 10:58, Tim Hollebeek >>> wrote: >>>> I agree that the tokens should be one time use, but the I think >>>> that the only way of enforcing it is by generating and unique >>>> opaque nonce (the ExternalSessionId exchanged on the DTLS setup) >>>> and couple it to be consumed only by the PC. >>> Yup, after understanding your concern, modifying the API to add a >>> required nonc would  be my suggestion, as it expresses the security >>> requirement in a simple way that's hard to get wrong. >> While I agree that adding a nonce would make the assertion stronger >> (assuming the nonce value has enough entropy). >> >> But who is going to create the nonce in these scenarios? >> I would guess that often the nonce would get created by the signaling >> server. But as far as I understand the potential attack here, the >> stealing of the assertion would have to happen exactly on that >> signaling path. So if you don’t trust that part of your setup, you >> should not trust it to create a unique nonce to improve things. >> > The nonce should generated internally by the PC and exchanged on the > dtls setup via the ExternalSessionId field from the sdp-uks draft. > That way the remote PC will be able to access the nonce and pass it to > the validate assertion call. By the way, there was already an open issue at w3c webrtc tracker regarding adding a peerconnection id for a different use case: https://github.com/w3c/webrtc-pc/issues/1775 We could reuse that id as dtls external session id/assertion nonce Best regards Sergio From nobody Mon Mar 19 04:30:51 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028CF12DA00 for ; Mon, 19 Mar 2018 04:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 MPnK_tFjUigw for ; Mon, 19 Mar 2018 04:30:35 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 CACE712741D for ; Mon, 19 Mar 2018 04:30:34 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id h76so14487597wme.4 for ; Mon, 19 Mar 2018 04:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=FNy325Y3eUZcwnApTARzpwOAfggcv0wIIhGjbePVXa4=; b=Nn259XeCh1OjBVZJZI80kk6eBIXBwjWtB0mnlQg346QHVgLsENrh442zhSCiEsp6dj Q6gOm2LMEi4OrdUzyfaxs9QwdGF5EFzwShaMjjd7wi+UuH3M3z1GfUIlRaIQQBAx21Mt ZrdO32BDClSNpjO3khd1HiSrG1xDhLg+fxCDbIz9XLytKVE+YAdcg674cSln8P7C8zU3 cTjoUs73fYMRPxACtpWAInbDSExoV0U3qBvrsqHieeNpNjvc6MFEpRFj0DdOWC46JkLR p5x+nI+MEx/y89BKlzuSD+P0Xba+34/sYPA5AoheQROX6VGIFaUdEGpN3WXg6sJ4o7fk tH1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=FNy325Y3eUZcwnApTARzpwOAfggcv0wIIhGjbePVXa4=; b=F0EZgkuI1YbEyxVcsVs0OMQhu3kQ5JvhFg+PGqioBGDiDsff0cYHbaBGkyVinRg15r ShcNMExuikzF8qKXyyMzEcSxZsRTwhv7j9+SUIDgJHBbDWmEFape3E8xoegzG+Jguu5e 2XimBc4dyFFc4u1g4C3SqJDJ80XFCbiTCOUi4dVMJCbqGpoN9jf8iw+zsThmcx2HheY7 KA2rDvPJ64ueqKWFGwsotRhK+qq0Ui2pTsGBMlEeBNIZXOsM0QWGjNawAtMgbe3Ap0hN FFY73zu/IE6yvSOYHvbVgH1SPVdIaMEll9sfTp1vKA/4SodHx+ngxayj02XJ2vPCtX4r XZFQ== X-Gm-Message-State: AElRT7GNUA+e59lROCFCsIe8Vrv1rKpL1zqbflVed9755SwkYACmN9Wl 04iwAwZ2Wofz3ID9R+r38jv1uZGP X-Google-Smtp-Source: AG47ELtgJ51FwLBhuzJbY+4XWQ6KpVTJhdSSrehAink++moT/ZU3RIArb4yJpjBIZBVglbShAunBMA== X-Received: by 10.80.227.194 with SMTP id c2mr12918463edm.195.1521459032828; Mon, 19 Mar 2018 04:30:32 -0700 (PDT) Received: from [192.168.0.101] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id a10sm56690eda.71.2018.03.19.04.30.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 04:30:31 -0700 (PDT) From: Sergio Garcia Murillo To: Nils Ohlmeier , Tim Hollebeek Cc: Martin Thomson , RTCWeb IETF References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> <2AB51FBE-21ED-4BFC-A0F0-A6BCF89B9C5B@mozilla.com> <01843e44-25ff-f834-e38e-59f7a34746f2@gmail.com> Message-ID: <48913ef9-920f-af9c-c02e-1cda51da0750@gmail.com> Date: Mon, 19 Mar 2018 12:30:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <01843e44-25ff-f834-e38e-59f7a34746f2@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 11:30:43 -0000 On 19/03/2018 12:10, Sergio Garcia Murillo wrote: > On 19/03/2018 12:05, Nils Ohlmeier wrote: >>> On Mar 19, 2018, at 10:58, Tim Hollebeek >>> wrote: >>>> I agree that the tokens should be one time use, but the I think >>>> that the only way of enforcing it is by generating and unique >>>> opaque nonce (the ExternalSessionId exchanged on the DTLS setup) >>>> and couple it to be consumed only by the PC. >>> Yup, after understanding your concern, modifying the API to add a >>> required nonc would  be my suggestion, as it expresses the security >>> requirement in a simple way that's hard to get wrong. >> While I agree that adding a nonce would make the assertion stronger >> (assuming the nonce value has enough entropy). >> >> But who is going to create the nonce in these scenarios? >> I would guess that often the nonce would get created by the signaling >> server. But as far as I understand the potential attack here, the >> stealing of the assertion would have to happen exactly on that >> signaling path. So if you don’t trust that part of your setup, you >> should not trust it to create a unique nonce to improve things. >> > The nonce should generated internally by the PC and exchanged on the > dtls setup via the ExternalSessionId field from the sdp-uks draft. > That way the remote PC will be able to access the nonce and pass it to > the validate assertion call. By the way, there was already an open issue at w3c webrtc tracker regarding adding a peerconnection id for a different use case: https://github.com/w3c/webrtc-pc/issues/1775 We could reuse that id as dtls external session id/assertion nonce Best regards Sergio From nobody Mon Mar 19 04:30:57 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89F612DA28 for ; Mon, 19 Mar 2018 04:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 6ERvvNGo-krW for ; Mon, 19 Mar 2018 04:30:51 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 3A0FB12D945 for ; Mon, 19 Mar 2018 04:30:43 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id c18so13983860oiy.9 for ; Mon, 19 Mar 2018 04:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WNxWfP7JuGfvAQQgY/oxzmNh6TY9ja7ogj0kVKw+bRg=; b=bJwNsyP4YAcnbMM3f+dIvLJ7r6ls/x7lzEzI7rmALCIsPICLgA+zcX/MQPUsoZ+3hR hE0vlbGPQhVO5AWaLFuzHh0P4ir6hx186kDnBGWBORI5Gp4IZl5opfeRGVGVgHhESvBQ V8UIi5Y/g5185JZyH7E7EnsMtVjuxwQv3lzEJrqYrR/8/Yiu4by1qZU/fkklJOeV8O75 o8N5KHfNK58glT5Ih4QpSo1ZT1R1H6S1VRRQKxcJOOpepaLo29JlxjOYUrnteYwkZH+/ qLD3PN2v0e9jHNJtPELMGO+GUcxp/SvbMgDY963bBIpKrkwJUNosM5m2vQtfLkwHvsW9 HgYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WNxWfP7JuGfvAQQgY/oxzmNh6TY9ja7ogj0kVKw+bRg=; b=oN67n6FRJjM4fzRmX5+i5k0saOcmc6RWCRFciYBEhlhY3ym545eGySF0bemWGfhLZy b5U8gwxQWkrLvMfZOTutViMkb4gQwU+BDcLnvta7gOPctPvohFr4LB1jW9RQF9zq7WzL rWNRPub8THVmVtLGNsP9BaqqR1Hz+tHe13/sGPvPYZm9EiObMq7kklqgqGY/ejBqEhOz Du0bKj96ZSNddsBKoAa999QTsEhgzG7xc/oeoiF08LXKfDevqBVyoYJwjF7GBRjkRo6f woQsg5VqD54jEs2pJQMY+i13IBElvjbzNHH9jeX2LYL4NEYrdu1KOJSeeBHrtH8H7TTy gpcQ== X-Gm-Message-State: AElRT7F06vdJK1hm6FKK3RXJFnpTI3S22W/f4ixqXogCGDycNNVnlvdr 69QnrP+hG8F/76wem+fOjTsbVmaM0GvnH+HfAQM= X-Google-Smtp-Source: AG47ELue6GdtQtXMzOyHSAT+lS4VZNS5/YFUlCec2kyVIdQ7ztYXRa/4pcPUvsIQtE8k98UlGdf9E9bh1GAQQSWy49Y= X-Received: by 10.202.171.68 with SMTP id u65mr2218260oie.272.1521459042496; Mon, 19 Mar 2018 04:30:42 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Mon, 19 Mar 2018 04:30:41 -0700 (PDT) In-Reply-To: References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> From: Martin Thomson Date: Mon, 19 Mar 2018 11:30:41 +0000 Message-ID: To: Sergio Garcia Murillo Cc: Tim Hollebeek , RTCWeb IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 11:30:55 -0000 So, concretely, the attack that would be enabled is that an origin that operates a service could cause a user to present any of the identities that it presented for use with that same service. Thus, if I visit example.com and it is permitted to generate an assertion for user@example.net, then the associated assertion could be used by example.com for any call that I initiate until the assertion expired. On Mon, Mar 19, 2018 at 11:23 AM, Sergio Garcia Murillo wrote: > On 19/03/2018 12:10, Martin Thomson wrote: > > On Mon, Mar 19, 2018 at 10:58 AM, Tim Hollebeek > wrote: > > Yup, after understanding your concern, modifying the API to add a required > nonce > would be my suggestion, as it expresses the security requirement in a > simple > way that's hard to get wrong. > > FWIW, in the common case, there is a nonce: the certificate. That is > generally unique to a RTCPeerConnection instance. > > But it can be saved and reused: > > https://www.w3.org/TR/webrtc/#dom-rtcconfiguration > > This option allows applications to establish key continuity. An > RTCCertificate can be persisted in [INDEXEDDB] and reused. Persistence and > reuse also avoids the cost of key generation. > > Best regards > > Sergio From nobody Mon Mar 19 04:36:49 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F7C12D877 for ; Mon, 19 Mar 2018 04:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 dz3u3XgNFVWK for ; Mon, 19 Mar 2018 04:36:48 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 AD0F412D875 for ; Mon, 19 Mar 2018 04:36:47 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id t6so15053849wmt.5 for ; Mon, 19 Mar 2018 04:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=zjAhiXYVZL1cLP93yOluuCA7B9aOSyz6xYK1bAtLf4Q=; b=VyjzuKXhcDfEqzXUNYlQqNhBwovDLjq2jwISQMTTT9h9MuF2jbyFDuvw6e/AWKAZQW 12Rn9Y0MzhB1p2Qj2S8kyHtQjqkNaG2z2ey+vWvREeuSanViDqyMOY95WMw8lcE3Meem ma9ONkQ1Zo+DGIBsyeqU/G+3qQOjCVQ+GEHPLDmYqEp/rpSfFW71n2+O7nZJfguGhmWH JXXoK2kZZqqz3DLTtkVNO9hDb6TbKN/5wirWx9NMxx3/NlVQWhQF3CTJhgzeXrKX8la0 pw8OM1iMBvMko922/2bF9Zj230zOSB1W012l1cwB/tfmPjnvBrKtLD5B/cBG9boxZOjg pp4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=zjAhiXYVZL1cLP93yOluuCA7B9aOSyz6xYK1bAtLf4Q=; b=tNsLJIx5cz+M3UbexEZW/xO2btkVjYgnYGEjs7Yo7Nz9+7aYLNXYqitrOmPltUTUNN DdIJBkhNP0IWhPDgQ581RusImgNDIyeoWtB9xPzRrGV8+ycTD0I/D6CDnJmI1bSOQe0N oYaFiQqbMToBzVyEpt8E/qUTPVZys13n8UwpWFJaF0ONKlfQXpgNH51vVzbZQOG3ezF+ k5nbKW5COrRKKT5uTRYR7QFl70nQZA2Bg08Ve4c6zyFaKUiWCj1vaJOOBsg7KjDg9dQ5 n2xBBSz6W+qW/Zk4Shos3xmz0xMOkXc0Px9Hm7XfhquCTcXo+2A0Ar1YGh43SlPUIlSe DWmg== X-Gm-Message-State: AElRT7HMcyCiMd4ldC2ZJLSCuwW38HSZBSFIS8tl3R1CxNnCpeVeh8XJ 59Roc3IXWVqdqnZ38o1yz9DC30SL X-Google-Smtp-Source: AG47ELvzpsfY8p3sp2jUnaoWBw97ISBD9TfohCaJBbatm00hQh7ja0AFrH4d+L0ISWE8RbHlmimLfw== X-Received: by 10.80.165.175 with SMTP id a44mr5801444edc.308.1521459405984; Mon, 19 Mar 2018 04:36:45 -0700 (PDT) Received: from [192.168.0.101] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id y14sm89638ede.18.2018.03.19.04.36.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 04:36:45 -0700 (PDT) To: Martin Thomson Cc: Tim Hollebeek , RTCWeb IETF References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> From: Sergio Garcia Murillo Message-ID: Date: Mon, 19 Mar 2018 12:36:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 11:36:49 -0000 Yep, exactly. On 19/03/2018 12:30, Martin Thomson wrote: > So, concretely, the attack that would be enabled is that an origin > that operates a service could cause a user to present any of the > identities that it presented for use with that same service. > > Thus, if I visit example.com and it is permitted to generate an > assertion for user@example.net, then the associated assertion could be > used by example.com for any call that I initiate until the assertion > expired. > > On Mon, Mar 19, 2018 at 11:23 AM, Sergio Garcia Murillo > wrote: >> On 19/03/2018 12:10, Martin Thomson wrote: >> >> On Mon, Mar 19, 2018 at 10:58 AM, Tim Hollebeek >> wrote: >> >> Yup, after understanding your concern, modifying the API to add a required >> nonce >> would be my suggestion, as it expresses the security requirement in a >> simple >> way that's hard to get wrong. >> >> FWIW, in the common case, there is a nonce: the certificate. That is >> generally unique to a RTCPeerConnection instance. >> >> But it can be saved and reused: >> >> https://www.w3.org/TR/webrtc/#dom-rtcconfiguration >> >> This option allows applications to establish key continuity. An >> RTCCertificate can be persisted in [INDEXEDDB] and reused. Persistence and >> reuse also avoids the cost of key generation. >> >> Best regards >> >> Sergio From nobody Mon Mar 19 04:54:43 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34920127867 for ; Mon, 19 Mar 2018 04:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ecqE1qZRP92j for ; Mon, 19 Mar 2018 04:54:40 -0700 (PDT) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (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 DA5FB1276AF for ; Mon, 19 Mar 2018 04:54:32 -0700 (PDT) Received: by mail-ot0-x22b.google.com with SMTP id 108-v6so17041314otv.3 for ; Mon, 19 Mar 2018 04:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oeRVHaUkgA0TXb6Iom1FFgUbVszYT606S87gCKeBwQo=; b=Egir05CgvDjCmiPnGz1Sq8S/REfTW2R8kFo8JL6BamNP9eSdwjxweWU2X6m/cW3+LR MNKe/KvLnCfmqe4zQc6amVzAnVkfvLSLkZiTE8PZZPwiMKtVQnfbQ3sWxAq7Le1HjoUf sccMXNObW2gSLnDqpHFcpiqX2IySRUUd+RSO3fNv4mEAoS9i8M8i8dIC3+g7IcACpSwJ H3sBwPgmYM1X+Scz1gMNby/2Sff1uAuO+3PBF07QJZzagg0ND2jVx2y/JqqNHmWq1V+x wb3udBF3qpArUnSIzDS2yv6z3w8J0TqpDd8kTSXyd16Yx8yeltYCQ+UxRV1t3kaDnxxk 8gew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oeRVHaUkgA0TXb6Iom1FFgUbVszYT606S87gCKeBwQo=; b=q7ZU/Wy34CGkgtwII+KGUOArpkq5LVRxAblbzMJX6F9y5m3nr6JyEiljR5UB7h8HQK rxGYffmirlQVqMEkSL8Pp9jBbtLXVAoN0ewyXACXNWt1xYhOBd0rm6ZkqKR0tefYUb5J LrI5E3vPDyg67jWAK8ozbmZiPKsC1ruCMQrhiTzcIHHGYNvWEyZzD4WSB0tQzaWi8jUu pXA+33mXuj0gNR+bP+/Dee2wymvvdExfTixqyb2SNC2utAn6SdAnSf348tj1wdt6eY4j v/qoLdcZs9NPlJCFgaL8BRZIMsruCBA1jZ7FCZGlO3Lu6HAc+z/oUWUiUkFp+cAKKaLY uCTw== X-Gm-Message-State: AElRT7EPV8jmEytTTtoZlaCzNOHsFTh/QFlaO+fqFhhvlSXF7m1FDNe/ BiIfU/vkGBEfvpQfFZU0YW18BTTDisPpD0T0Fw0= X-Google-Smtp-Source: AG47ELum1WPWWky3Jp3wJW/fhB8Vd3AUfV0bw2KK/aQwu5kAX++JNtqY5tdh5he4fDc6O3Vpfj727DGoIxUVRiMQ16U= X-Received: by 2002:a9d:29ea:: with SMTP id g39-v6mr3085660otd.241.1521460472190; Mon, 19 Mar 2018 04:54:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Mon, 19 Mar 2018 04:54:31 -0700 (PDT) In-Reply-To: References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> From: Martin Thomson Date: Mon, 19 Mar 2018 11:54:31 +0000 Message-ID: To: Sergio Garcia Murillo Cc: Tim Hollebeek , RTCWeb IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 11:54:42 -0000 Hmm, that's not that interesting. The number and disposition of RTCPeerConnection instances in a page, and the way in which they are used, is not something that is particularly visible. On Mon, Mar 19, 2018 at 11:36 AM, Sergio Garcia Murillo wrote: > Yep, exactly. > > > > On 19/03/2018 12:30, Martin Thomson wrote: >> >> So, concretely, the attack that would be enabled is that an origin >> that operates a service could cause a user to present any of the >> identities that it presented for use with that same service. >> >> Thus, if I visit example.com and it is permitted to generate an >> assertion for user@example.net, then the associated assertion could be >> used by example.com for any call that I initiate until the assertion >> expired. >> >> On Mon, Mar 19, 2018 at 11:23 AM, Sergio Garcia Murillo >> wrote: >>> >>> On 19/03/2018 12:10, Martin Thomson wrote: >>> >>> On Mon, Mar 19, 2018 at 10:58 AM, Tim Hollebeek >>> wrote: >>> >>> Yup, after understanding your concern, modifying the API to add a >>> required >>> nonce >>> would be my suggestion, as it expresses the security requirement in a >>> simple >>> way that's hard to get wrong. >>> >>> FWIW, in the common case, there is a nonce: the certificate. That is >>> generally unique to a RTCPeerConnection instance. >>> >>> But it can be saved and reused: >>> >>> https://www.w3.org/TR/webrtc/#dom-rtcconfiguration >>> >>> This option allows applications to establish key continuity. An >>> RTCCertificate can be persisted in [INDEXEDDB] and reused. Persistence >>> and >>> reuse also avoids the cost of key generation. >>> >>> Best regards >>> >>> Sergio > > > From nobody Mon Mar 19 05:02:45 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF92A124234 for ; Mon, 19 Mar 2018 05:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 1p5tTEEc8VoC for ; Mon, 19 Mar 2018 05:02:41 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.199]) (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 C40C512741D for ; Mon, 19 Mar 2018 05:02:39 -0700 (PDT) Received: from [216.82.242.36] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-7.bemta-8.messagelabs.com id 32/F5-03133-ED6AFAA5; Mon, 19 Mar 2018 12:02:38 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTURzHO/ex3cTZdWr+GtpjoNRoa/ZiIvQ mekLRH4asx11et9EesrvE/imFmDajtJRsVBNaFkMzUtOelKDlIy01kx6UlPhKKlpZBtquZ/Y4 f33O+Xw553fO+TGkvFeiYPhsJ++wcRalJIzq0FySq1+XV6VpSyeTdT1tE0hXOZEn1fVP1JFry E23PG+km3y+n8QOIo022wz27P206dKJWmlm2dZsb+NxOgcNbHSjMIZiPxHQcHOEFCdytoSArq 5mhCfvELzvOClxo5mMhNVCz71HhMjRrBG85eWkyCS7AAJXvFOZKHYVtOf6pTizGl51t5OYsyD /TM5UhmIT4Ot4BRJZxurhftF1WmQ5+4CG58Mb3IhhZrI74XZzpLiM2Nkw1lJB4KNi4eUH7xQD Gw19z1olmGNg6P0EjfN6uPC1IbSuhNH+YhpzPHR6CxDmGgJqLiZiVsPnkhIS83Z4PugK5TsRn OtLxayCq2VuCvNBGDrmC7EeCr5UEuJbAesj4e7Tx1Is4qC0+hSNRb4Enlz5TuFLpkOxX6xOFL 8I+BHoQYVI5fnndp6gI1kvgtzWEaln6pUiofncBwqHVFBSORzieVA3ep7EnAKl4w8lntCPFBf 0STGvgJHGL6gMMX60UOAdWbxDnbRUY3CYjSanlTNb1ElancbKCwJn5C2cQdAcsFtvoGB/zQiO elToWd+A5jCEMkZmL6pKk0cY7OmHTZxg2uc4ZOGFBhTHMEqQHbkcdJEO3shnZ5gtwSad1sCEK 6NlWlHLhEzOKpiNWLWgZUzN2QEXyfQOjrhIOWWz23hFrCxVjLJi1HTI9mej6YbvRPGKKBkKli YPz+QdVrPzfz+MYhmkjJKdFncJN9ucf84bDpZCBEvZdrlCLMXJ/VWKHEStTmkpb/S0xle49uy vH83vS3nTO3cgsHLxrtrv7a51UrpLHqXbe2fsbJN7ZZUirvFeWEbqsUk+sSs5oUpYovYvj4lo /vbC15R5rZtk4jS7M7SDD21K/ZxvTYHN6S/aDMb8j0vyWgIHx6q33Do/a0NPsf/R0I5Fkylh8 4++feVbW6SkBBOXpCIdAvcbB0EVoesDAAA= X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-14.tower-94.messagelabs.com!1521460955!184197143!1 X-Originating-IP: [207.46.163.18] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 77395 invoked from network); 19 Mar 2018 12:02:36 -0000 Received: from mail-dm3nam03lp0018.outbound.protection.outlook.com (HELO NAM03-DM3-obe.outbound.protection.outlook.com) (207.46.163.18) by server-14.tower-94.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 19 Mar 2018 12:02:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=X1p2GPf5LjxuPDkeVMVecpeFFIszHQTieqg5eXQ72i8=; b=F/KVs1vFInUFf/KjytHSq5I35D8/2A5qXsbV9eMDr3HI9aS45uxWj/rA1ypr/qAeyyWGo4nuS8OVNuzuGXfe7OY3U4vbvyo+ccVIFLZeSIAwpCtDAjb6U7VI6VJPNy0TOxFxG/fYsoK2SkYJOesWqVeSKXDWTs+VpKdo00+xzoU= Received: from MWHPR14MB1376.namprd14.prod.outlook.com (10.173.232.139) by MWHPR14MB1469.namprd14.prod.outlook.com (10.173.233.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Mon, 19 Mar 2018 12:02:33 +0000 Received: from MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::7929:3f48:4a4f:1e32]) by MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::7929:3f48:4a4f:1e32%18]) with mapi id 15.20.0588.016; Mon, 19 Mar 2018 12:02:33 +0000 From: Tim Hollebeek To: Martin Thomson , Sergio Garcia Murillo CC: RTCWeb IETF Thread-Topic: [rtcweb] Possible identity security vulnerability Thread-Index: AQHTv2Fbf2/O/UlBVk2jAz9KxqI00qPXTSyAgAAEY4CAAAAskIAAB1QAgAAKAQCAAAPsAIAAA8oAgAAB44CAAAGxAIAABPiAgAAA0oA= Date: Mon, 19 Mar 2018 12:02:33 +0000 Message-ID: References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [31.133.148.144] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR14MB1469; 7:9s6VOr0IlVIKYWMKa0mBxWcSYnhzVAbCi3nb4sIQs9d63lVDdtv5rEGKjBH31nQ8DdhhC3To68p47F7oyUuIkGIt9aqFLKFoQILc/Vg+xDoSvK6lElHUGurHNCAyo6L37Bq6qR/VfT91Q8nWkci8UIwukLzxUr1z5mP/5fGfscE0v5HT3PfKCFz+lL5c+PdVabBF176C8CmpbZwGGDEMEWOnCP5AR48tAEmjpC3KWAwg7Fad648ivbXgp9Mb6Tl4 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 277e0c99-6a8b-49f5-0e8d-08d58d914c76 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:MWHPR14MB1469; x-ms-traffictypediagnostic: MWHPR14MB1469: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501244)(52105095)(3002001)(93006095)(93001095)(10201501046)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:MWHPR14MB1469; BCL:0; PCL:0; RULEID:; SRVR:MWHPR14MB1469; x-forefront-prvs: 06167FAD59 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(396003)(39850400004)(39380400002)(199004)(189003)(13464003)(102836004)(4326008)(39060400002)(9686003)(6306002)(14454004)(6506007)(316002)(966005)(55016002)(59450400001)(105586002)(3660700001)(8676002)(5250100002)(99936001)(25786009)(93886005)(81156014)(81166006)(68736007)(2906002)(8936002)(2950100002)(6436002)(3280700002)(2900100001)(15650500001)(7736002)(26005)(110136005)(305945005)(7696005)(3846002)(74316002)(106356001)(76176011)(99286004)(86362001)(186003)(53546011)(33656002)(97736004)(478600001)(53936002)(66066001)(6116002)(229853002)(5660300001)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR14MB1469; H:MWHPR14MB1376.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: UqYVt26ujevf+H7ZUnYhAPSigpTCdNo8Sqwi0YGFn0OEvqDbx3y6DRfYAMw/CfIRpemqeHRHX9w2GF1uLFdvnSjGtroQ0fuK4zddBG6pfh+xAG53xgisiMyyQ3I4CyYhGE25Ch+U+mocSk2/hzRPgJt/IXKoyUo2UHCNM+CQWdUBdZlox7IQU7fh507O1sbTR3TWfwndJBOD8RG9E7ts5/oSQooLOpsg2glTU7wAf0fhBmUYRcLi9xnMPEOEqt+8MJLq6HLSrl2myMl3H8W2qu90ByzbXihEJwtaIygJHeOj47qVdjCpI6ab5/BM3BdYWbIH6B5QnQfeSKoocx/YYQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0441_01D3BF7A.27D2FB50" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 277e0c99-6a8b-49f5-0e8d-08d58d914c76 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2018 12:02:33.3654 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1469 Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 12:02:43 -0000 ------=_NextPart_000_0441_01D3BF7A.27D2FB50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Wait, what? The details of how a particular page is implemented is pretty easy to discover for even a moderately sophisticated technical person. Where in the security model does it say that attackers can only use information visible on the page? If I'm going through the trouble of re-using assertions, I will have certainly have figured out how the target page uses RTCPeerConnections before trying to re-use assertions. -Tim > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Monday, March 19, 2018 11:55 AM > To: Sergio Garcia Murillo > Cc: Tim Hollebeek ; RTCWeb IETF > > Subject: Re: [rtcweb] Possible identity security vulnerability > > Hmm, that's not that interesting. The number and disposition of > RTCPeerConnection instances in a page, and the way in which they are used, > is > not something that is particularly visible. > > On Mon, Mar 19, 2018 at 11:36 AM, Sergio Garcia Murillo > wrote: > > Yep, exactly. > > > > > > > > On 19/03/2018 12:30, Martin Thomson wrote: > >> > >> So, concretely, the attack that would be enabled is that an origin > >> that operates a service could cause a user to present any of the > >> identities that it presented for use with that same service. > >> > >> Thus, if I visit example.com and it is permitted to generate an > >> assertion for user@example.net, then the associated assertion could > >> be used by example.com for any call that I initiate until the > >> assertion expired. > >> > >> On Mon, Mar 19, 2018 at 11:23 AM, Sergio Garcia Murillo > >> wrote: > >>> > >>> On 19/03/2018 12:10, Martin Thomson wrote: > >>> > >>> On Mon, Mar 19, 2018 at 10:58 AM, Tim Hollebeek > >>> wrote: > >>> > >>> Yup, after understanding your concern, modifying the API to add a > >>> required nonce would be my suggestion, as it expresses the security > >>> requirement in a simple way that's hard to get wrong. > >>> > >>> FWIW, in the common case, there is a nonce: the certificate. That > >>> is generally unique to a RTCPeerConnection instance. > >>> > >>> But it can be saved and reused: > >>> > >>> https://www.w3.org/TR/webrtc/#dom-rtcconfiguration > >>> > >>> This option allows applications to establish key continuity. An > >>> RTCCertificate can be persisted in [INDEXEDDB] and reused. > >>> Persistence and reuse also avoids the cost of key generation. > >>> > >>> Best regards > >>> > >>> Sergio > > > > > > ------=_NextPart_000_0441_01D3BF7A.27D2FB50 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgwMzE5MTIwMjI5WjAvBgkqhkiG9w0BCQQxIgQgBQMf/ee6Ct6ewJeub6pCzyds9aSi rvAMBNOqeOFZxCgwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBALp3+W4hmpr6w1z6HoPhyzmMVqqAYj+nXV4ZjAqyRZcvqmunGDyVP4DWYLCKMwiaBSjQMRE+ aHyEjhzmpcgQdFQcB56BcRI7tFRdT35eVNlVQbWeBXWg0p8TLxSrYmfaofrF2a1PC/qR2yHj3Bea ldqieCe+//JuqQe4WPGC2uOzousQiWYG1V7Dtt5WCPBhOJS8pFIl+7VRdpeDif6iZR5zrER6ERI6 cUAKd0/I9Iya+dGBUHvj9tbI4QaUezgRsmkvaOiVcPccuWwEEfGStNnHA0asQy4LNtUk5Ahs7yLp MXjQZHlDSeJl44jossBCPkZvKULIwolkgMdGcFKW/PUAAAAAAAA= ------=_NextPart_000_0441_01D3BF7A.27D2FB50-- From nobody Mon Mar 19 05:30:02 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AF012785F for ; Mon, 19 Mar 2018 05:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 bhH3jU9w6a43 for ; Mon, 19 Mar 2018 05:29:58 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 64F3C12D777 for ; Mon, 19 Mar 2018 05:29:58 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id f125so6946010wme.4 for ; Mon, 19 Mar 2018 05:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=UK2lmgmwW+V0zkUiezXiEO4fZmGuxYFNukKaXUwRAH0=; b=DAfQ8x2UZtBjGbsoJkYcYLIAEuK1x95WYCDjR+af37YAyJvZRJGZLYB7z8e0tDLgWm RZ6iIuiO8NQUYpU5F65t1bpHY1nOMHr/3NCs6rDQh/7HPjoAZ1O8+ppsky7HBFD/66W+ tcSL3jVgZ8aqCboB/ETNfWUAxvP+xF4bw5dq8XUra5JxqTJmghQvkQFr3cnq/JCyLLzL /JeNItjd8XLydNMrUnorXDkVfrAvY7YysLQadWhUEYUhdVy+iymNX4VMFGPX+VgZSyf9 xq7URwYR/S1dlNTckaynBNiCFLLCdjOqQJEVxhC8BV74/5HrWfh4cUHHska9aw5YeS+I l5ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=UK2lmgmwW+V0zkUiezXiEO4fZmGuxYFNukKaXUwRAH0=; b=ZxBCipGXPKtGVcE4KqJowLMp1tSflyNM+SxgNGq6FJQEJ3wXjtLS/ViJ9S0SVLBpJF 4rWWpDw3bZ2GfrC241BnWzzweJrqFFK1Pe9tccl93azAIoo65YkJU39S8RNnzvivB/DG bex6ZUnlcc+U8soqbI3rCKwOqTfcYxGbiOnCMIL6TE84Rf22YDPSMoTIiGY+AN7MwvOg 0lRZbsP0TQnjaL9dluN+PtISYVbanfzj6UQkLDPPcpTxdXvdu34YELno70TVdwcq8Jnj m/6E1nODBXAzSRHPQt5nz8+w1Gcgz9LXKDkXPFkMQCm5L26LISfJxyNj/z5ylmPwUhTl /nwQ== X-Gm-Message-State: AElRT7FkrHRpGFaGEWjQH22amGmDO5V00nP58Qb2DTU3da8YB+4Yg/9P Z5tmbV5UolxXbWi+CDZfHnpLOqVY X-Google-Smtp-Source: AG47ELsspMsSxqKY5iPhltJTrVMAmQNmd6gb4MRRdhZ8AYo8Coo/drnRPzpwe7ZG1MjwEPQAg94eDg== X-Received: by 10.80.142.70 with SMTP id 6mr9038483edx.141.1521462596719; Mon, 19 Mar 2018 05:29:56 -0700 (PDT) Received: from [192.168.0.101] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id c9sm146367edl.23.2018.03.19.05.29.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 05:29:55 -0700 (PDT) To: Martin Thomson Cc: Tim Hollebeek , RTCWeb IETF References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> From: Sergio Garcia Murillo Message-ID: <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> Date: Mon, 19 Mar 2018 13:29:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 12:30:00 -0000 BTW, note that it is not "any call that I initiate until the assertion expired" but "any call that the browser initiates until the assertion expired". Best regards Sergio On 19/03/2018 12:54, Martin Thomson wrote: > Hmm, that's not that interesting. The number and disposition of > RTCPeerConnection instances in a page, and the way in which they are > used, is not something that is particularly visible. > > On Mon, Mar 19, 2018 at 11:36 AM, Sergio Garcia Murillo > wrote: >> Yep, exactly. >> >> >> >> On 19/03/2018 12:30, Martin Thomson wrote: >>> So, concretely, the attack that would be enabled is that an origin >>> that operates a service could cause a user to present any of the >>> identities that it presented for use with that same service. >>> >>> Thus, if I visit example.com and it is permitted to generate an >>> assertion for user@example.net, then the associated assertion could be >>> used by example.com for any call that I initiate until the assertion >>> expired. >>> >>> On Mon, Mar 19, 2018 at 11:23 AM, Sergio Garcia Murillo >>> wrote: >>>> On 19/03/2018 12:10, Martin Thomson wrote: >>>> >>>> On Mon, Mar 19, 2018 at 10:58 AM, Tim Hollebeek >>>> wrote: >>>> >>>> Yup, after understanding your concern, modifying the API to add a >>>> required >>>> nonce >>>> would be my suggestion, as it expresses the security requirement in a >>>> simple >>>> way that's hard to get wrong. >>>> >>>> FWIW, in the common case, there is a nonce: the certificate. That is >>>> generally unique to a RTCPeerConnection instance. >>>> >>>> But it can be saved and reused: >>>> >>>> https://www.w3.org/TR/webrtc/#dom-rtcconfiguration >>>> >>>> This option allows applications to establish key continuity. An >>>> RTCCertificate can be persisted in [INDEXEDDB] and reused. Persistence >>>> and >>>> reuse also avoids the cost of key generation. >>>> >>>> Best regards >>>> >>>> Sergio >> >> From nobody Mon Mar 19 05:52:06 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23265127869 for ; Mon, 19 Mar 2018 05:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.916 X-Spam-Level: X-Spam-Status: No, score=-0.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982, URIBL_BLOCKED=0.001] autolearn=no 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 MYDmoj7J-Mfg for ; Mon, 19 Mar 2018 05:51:57 -0700 (PDT) Received: from odu.duckdns.org (business-178-48-31-65.business.broadband.hu [178.48.31.65]) (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 90DD912DB6F for ; Mon, 19 Mar 2018 05:51:56 -0700 (PDT) Received: from alma.ki.iif.hu ([193.6.222.35]) by odu.duckdns.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1exuGU-0006zn-Bp; Mon, 19 Mar 2018 13:51:50 +0100 To: Harald Alvestrand , Cullen Jennings , WebRTC WG , RTCWeb IETF References: <2C22A535-0F8D-496D-B8BF-C74ACB17958C@iii.ca> From: =?UTF-8?B?TcOpc3rDoXJvcyBNaWjDoWx5?= Message-ID: <20849d66-d0ba-e988-e818-51d9b43dfaac@odu.duckdns.org> Date: Mon, 19 Mar 2018 13:51:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E2CF885AF0C01A5ABE0437DB" Content-Language: en-GB Archived-At: Subject: Re: [rtcweb] WebRTC REF for OAUTH based TURN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 12:52:05 -0000 This is a multi-part message in MIME format. --------------E2CF885AF0C01A5ABE0437DB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 2018-03-14 17:46 keltez=C3=A9ssel, Harald Alvestrand =C3=ADrta: > Den 14. mars 2018 16:05, skrev M=C3=A9sz=C3=A1ros Mih=C3=A1ly: >> >> 2018-03-14 08:37 keltez=C3=A9ssel, Harald Alvestrand =C3=ADrta: >>> Den 13. mars 2018 15:14, skrev Cullen Jennings: >>>> From a dependency point of view, I would like to note that right now= the WebRTC PC spec references >>>> >>>> * draft-ietf-oauth-pop-key-distribution >>>> >>>> Which rumor has it has been replaced by=20 >>>> >>>> * datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz >>>> >>>> Which normatively references the following: >>>> >>>> * draft-ietf-ace-cbor-web-token >>>> * ietf-ace-cwt-proof-of-possession >>>> * draft-ietf-ace-cbor-web-token >>>> * draft-ietf-ace-cwt-proof-of-possession >>>> >>>> More discussion of this at https://github.com/w3c/webrtc-pc/issues/1= 642 >>>> >>>> What needs to happen with all this so we can finish up the stuff Web= RTC needs to reference from IETF ? >>>> >>>> >>>> >>>> >>>> >>> >From a WG product management point of view, I consider that this has= not >>> deployed, and is not likely to deploy in the present timeframe, given= >>> that no consensus specifiation has emerged. >>> >>> My suggestion would be to replace this text: >>> >>> An OAuth 2.0 based authentication method, as described in [RFC7635]. = It >>> uses the OAuth 2.0 Implicit Grant type, with PoP (Proof-of-Possession= ) >>> Token type, as described in [RFC6749] and [OAUTH-POP-KEY-DISTRIBUTION= ]. >>> .... rest of section .... >>> >>> with >>> >>> An OAuth 2.0 based authentication method, as described in [RFC7635].= >>> >>> The amount of detail currently in the webrtc-pc document is, to my mi= nd, >>> inappropriate for a W3C spec. If the IETF has failed to come up with = a >>> single "handle" by which all this detail can be referenced, the IETF= >>> needs to solve that problem. >>> >> After the confusion around RTCIceCredential OAuth parameters in >> WebRTC-PC, I just want to close the gap between W3C WebRTC-PC and IETF= >> RFC7635. >> RFC7635 is complex and confusing without a guide. >> My intention was to remove confusion and define an example guideline >> howto use RFC7635 in WebRTC context, and put all this info into the >> WebRTC-PC spec. >> >> Now I see I went too far, and PC spec should step back and mention OAu= th >> PoP only as a possible way of the key distribution, but in other hand >> the information in webrtc PC is inline with the RFC7635 example Append= ix B. >> >> Is it better to leave totally undefined howto use RFC7635 in WebRTC >> context as Harald proposed? >> I am not sure. > I think it would be better to publish an IETF document that describes > "one clear way to do it", and see if we can get interoperable > implementations of that. Then we can insert a reference to that in the > WebRTC spec when it's ready. > > The current text is unimplementable because it refers to documents that= > don't exist (formally) any more, which is an untenable situation. I started my discussion with Simon in TRAM wg. chair about it. The conclusion was it is not clear if IETF informational RFC is the right place to put it. That time it seem the oauth-pop-key-distribution is the only way howto implement it, (RFC7635 also gave in appendix an example based on it). I thought that RFCs/specs are already so heavily fragmented in this topic, and it's easy to get lost in RFCs, even to understand OAuth & PoP, so it would be the right place to put the specialities in WebRTC context in WebRTC PC spec.. After my various failed PRs Taylor helped and put this text together. I still believe that the actual text in PC is still a good guidance and example howto implement it using RFC7635 + oauth-pop-key-distribution. It is detailed enough to understand howto implement it. Now during rereading it I recognized one mistake: It is wrong and misleading from that aspects that it does not state that oauth-pop-key-distribution is only an example of key distribution. However I understand your reasons to move it out to an RFC, I still don't know if it would help for implementers or not. > The current text is unimplementable because it refers to documents that= > don't exist (formally) any more, which is an untenable situation. For me it seems easier to follow oauth (http) based key distribution, and so for me it is still not so clear why the OAuth pop key distribution is an obsoleted idea. Personally I am not sure which way is more implementable today. Please notice that CWT/CBOR PoP is also in draft state. Both has pro and contra, * stable dead end VS. moving working draft * more stable VS. less mature in progress. All in all both cwt-proof-of-possession and oauth-pop-key-distribution are in working draft state and not yet an RFC. For an RFC7635 implementer for WebRTC I think today it is still much more easy and safe to implement oauth-pop-key-distribution (with coturn open implementation backend). All in all I would be happy to keep it inside WebRTC-PC with some slight change, fix the mentioned issue:(oauth-pop-key-distribution is only an example way of key distribution implementation), because IMHO it would help for implementers a lot. Sorry for my late reply. Misi --------------E2CF885AF0C01A5ABE0437DB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



2018-03-14 17:46 keltezéssel, Harald Alvestrand írta:
Den 14. mars 2018 16:05, skrev Mészáros Mihály:


2018-03-14 08:37 keltezéssel, Harald Alvestrand írta:

Den 13. mars 2018 15:14, skrev Cullen Jennings:

From a dependency point of view, I would like to note that right now the WebRTC PC spec references

* draft-ietf-oauth-pop-key-distribution

Which rumor has it has been replaced by 

* datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz

Which normatively references the following:

* draft-ietf-ace-cbor-web-token
* ietf-ace-cwt-proof-of-possession
* draft-ietf-ace-cbor-web-token
* draft-ietf-ace-cwt-proof-of-possession

More discussion of this at https://github.com/w3c/webrtc-pc/issues/1642

What needs to happen with all this so we can finish up the stuff WebRTC needs to reference from IETF ?






>From a WG product management point of view, I consider that this has not
deployed, and is not likely to deploy in the present timeframe, given
that no consensus specifiation has emerged.

My suggestion would be to replace this text:

An OAuth 2.0 based authentication method, as described in [RFC7635]. It
uses the OAuth 2.0 Implicit Grant type, with PoP (Proof-of-Possession)
Token type, as described in [RFC6749] and [OAUTH-POP-KEY-DISTRIBUTION].
 .... rest of section ....

with

 An OAuth 2.0 based authentication method, as described in [RFC7635].

The amount of detail currently in the webrtc-pc document is, to my mind,
inappropriate for a W3C spec. If the IETF has failed to come up with a
single "handle" by which all this detail  can be referenced, the IETF
needs to solve that problem.


After the confusion around RTCIceCredential OAuth parameters in
WebRTC-PC, I just want to close the gap between W3C WebRTC-PC and IETF
RFC7635.
RFC7635 is complex and confusing without a guide.
My intention was to remove confusion and define an example guideline
howto use RFC7635 in WebRTC context, and put all this info into the
WebRTC-PC spec.

Now I see I went too far, and PC spec should step back and mention OAuth
PoP only as a possible way of the key distribution, but in other hand
the information in webrtc PC is inline with the RFC7635 example Appendix B.

Is it better to leave totally undefined howto use RFC7635 in WebRTC
context as Harald proposed?
I am not sure.

I think it would be better to publish an IETF document that describes
"one clear way to do it", and see if we can get interoperable
implementations of that. Then we can insert a reference to that in the
WebRTC spec when it's ready.

The current text is unimplementable because it refers to documents that
don't exist (formally) any more, which is an untenable situation.
I started my discussion with Simon in TRAM wg. chair about it. The conclusion was it is not clear if IETF informational RFC is the right place to put it.
That time it seem the oauth-pop-key-distribution is the only way howto implement it, (RFC7635 also gave in appendix an example based on it).

I thought that RFCs/specs are already so heavily fragmented in this topic, and it's easy to get lost in RFCs,
even to understand OAuth & PoP, so it would be the right place to put the specialities in WebRTC context in WebRTC PC spec..

After my various failed PRs Taylor helped and put this text together.
I still believe that the actual text in PC is still a good guidance and example howto implement it using RFC7635 + oauth-pop-key-distribution.

It is detailed enough to understand howto implement it.

Now during rereading it I recognized one mistake: It is wrong and misleading from that aspects that it does not state that oauth-pop-key-distribution is only an example of key distribution.

However I understand your reasons to move it out to an RFC, I still don't know if it would help for implementers or not.
The current text is unimplementable because it refers to documents that
don't exist (formally) any more, which is an untenable situation.
For me it seems easier to follow oauth (http) based key distribution, and so for me it is still not so clear why the OAuth pop key distribution is an obsoleted idea.

Personally I am not sure which way is more implementable today.
Please notice that CWT/CBOR PoP is also in draft state.

Both has pro and contra,
  • stable dead end VS. moving working draft
  • more stable VS. less mature in progress.

All in all both cwt-proof-of-possession and oauth-pop-key-distribution are in working draft state and not yet an RFC.
For an RFC7635 implementer for WebRTC I think today it is still much more easy and safe to implement oauth-pop-key-distribution (with coturn open implementation backend).

All in all I would be happy to keep it inside WebRTC-PC with some slight change, fix the mentioned issue:(oauth-pop-key-distribution is only an example way of key distribution implementation),
because IMHO it would help for implementers a lot.

Sorry for my late reply.
Misi
--------------E2CF885AF0C01A5ABE0437DB-- From nobody Mon Mar 19 06:40:49 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209D712778E for ; Mon, 19 Mar 2018 06:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 DiljL7rUNFNH for ; Mon, 19 Mar 2018 06:40:38 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 AADBA12DA1A for ; Mon, 19 Mar 2018 06:40:38 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id q71so4041778oic.6 for ; Mon, 19 Mar 2018 06:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s2xLm9CpyLaGtHHwvbDXfCR22b+KKrTePrPDrCKr+8g=; b=ptMfhbTSSXDvAtdouYv9YcRr62KrnPlYqM8qXFf6Eu45efXf1tJdHw0P8qCF5wCOG7 5AP04YKWmaE5g0smMyqdl9NdvVwycqln+5f2jnnBYJ7wgrVEIo6NooWCjeO/u3yxDNr1 VfYnWQw7qfEdqik8vbr+GQ76NslQ47wwbF+Ufn1ARL/mn1pzEx4KsEMUkh8dR4n536dn YmfGMtvNNVoOoUW+g322jshryGuG1emXUn6UVXgiVHXCjp6fox0KDAX+qvrc0+LXEl8O ZlUCIo4pM8XWQsZBsR41gsEbYGtAI+eeLbsjT4+mBweoh9RoXqS8gg3gzhemVS0ZeFSA Yo/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=s2xLm9CpyLaGtHHwvbDXfCR22b+KKrTePrPDrCKr+8g=; b=A7XTJKwBxpJhhKldT2h2wGiqMKN+WEuWK73Zy7sILCPfDMKvfVZapDX8Gkqyhyrc6m 3BPm/s/uXiBZHlJWb011txcFmq+9THvXhf5dfyrWYyIumJkX7NEG2bAz5jLTwhzkBDZ7 nA0/7FhqUJ0M6j3fwAACiQh4RkTbkLxvIKnK2hzKQPCR3HO2OSf3inqkd7WPo3nvkxbW xEx0mSbUL3d9vpMaemw4uBQP2qDlE2x32I5u5l6UaPk4oQl2000BCVDxStnA8eRd1KcS wWOGtbQYPSCQnJ8/l/7zv7e2UJDfcS4jYULRaXaFvGLu+Tas89JkD6qOCdSIRn2NNVB9 CUBg== X-Gm-Message-State: AElRT7F2dhcjjU+YBmNPUOcXTgZMZ1P1d9Q8FXVTh+Zi9cfCFycBpYqY jH1lhV7Uol+HVdtxcTybMMHCYtr3DECQF6AXFMY= X-Google-Smtp-Source: AG47ELtKSeG9K8uKMD0A9+h48MQlkQvS5UUOlrDCamJtJyVNMJL07tfPNm3+JDIg/rI3qGY6N92APhMco6ItNswJ34Y= X-Received: by 10.202.223.133 with SMTP id w127mr7369882oig.346.1521466837927; Mon, 19 Mar 2018 06:40:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Mon, 19 Mar 2018 06:40:37 -0700 (PDT) In-Reply-To: <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> From: Martin Thomson Date: Mon, 19 Mar 2018 13:40:37 +0000 Message-ID: To: Sergio Garcia Murillo Cc: Tim Hollebeek , RTCWeb IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 13:40:48 -0000 It's anything that *the site* initiates (not so much the browser). Certificates are origin-scoped. On Mon, Mar 19, 2018 at 12:29 PM, Sergio Garcia Murillo wrote: > BTW, note that it is not "any call that I initiate until the assertion > expired" but "any call that the browser initiates until the assertion > expired". > > Best regards > Sergio > > > On 19/03/2018 12:54, Martin Thomson wrote: >> >> Hmm, that's not that interesting. The number and disposition of >> RTCPeerConnection instances in a page, and the way in which they are >> used, is not something that is particularly visible. >> >> On Mon, Mar 19, 2018 at 11:36 AM, Sergio Garcia Murillo >> wrote: >>> >>> Yep, exactly. >>> >>> >>> >>> On 19/03/2018 12:30, Martin Thomson wrote: >>>> >>>> So, concretely, the attack that would be enabled is that an origin >>>> that operates a service could cause a user to present any of the >>>> identities that it presented for use with that same service. >>>> >>>> Thus, if I visit example.com and it is permitted to generate an >>>> assertion for user@example.net, then the associated assertion could be >>>> used by example.com for any call that I initiate until the assertion >>>> expired. >>>> >>>> On Mon, Mar 19, 2018 at 11:23 AM, Sergio Garcia Murillo >>>> wrote: >>>>> >>>>> On 19/03/2018 12:10, Martin Thomson wrote: >>>>> >>>>> On Mon, Mar 19, 2018 at 10:58 AM, Tim Hollebeek >>>>> wrote: >>>>> >>>>> Yup, after understanding your concern, modifying the API to add a >>>>> required >>>>> nonce >>>>> would be my suggestion, as it expresses the security requirement in a >>>>> simple >>>>> way that's hard to get wrong. >>>>> >>>>> FWIW, in the common case, there is a nonce: the certificate. That is >>>>> generally unique to a RTCPeerConnection instance. >>>>> >>>>> But it can be saved and reused: >>>>> >>>>> https://www.w3.org/TR/webrtc/#dom-rtcconfiguration >>>>> >>>>> This option allows applications to establish key continuity. An >>>>> RTCCertificate can be persisted in [INDEXEDDB] and reused. Persistence >>>>> and >>>>> reuse also avoids the cost of key generation. >>>>> >>>>> Best regards >>>>> >>>>> Sergio >>> >>> >>> > From nobody Mon Mar 19 06:46:05 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C7F126D74 for ; Mon, 19 Mar 2018 06:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 rAzySjzJb08f for ; Mon, 19 Mar 2018 06:46:00 -0700 (PDT) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (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 C0037126D3F for ; Mon, 19 Mar 2018 06:45:59 -0700 (PDT) Received: (qmail 66844 invoked from network); 19 Mar 2018 13:45:57 -0000 X-APM-Authkey: 255286/0(159927/0) 1103 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 19 Mar 2018 13:45:57 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id BE1DE18A0693; Mon, 19 Mar 2018 13:45:57 +0000 (GMT) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id cjCyjLMmb8zj; Mon, 19 Mar 2018 13:45:57 +0000 (GMT) Received: from [192.67.4.84] (unknown [192.67.4.84]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 9518F18A0401; Mon, 19 Mar 2018 13:45:57 +0000 (GMT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: westhawk In-Reply-To: Date: Mon, 19 Mar 2018 13:45:56 +0000 Cc: Sergio Garcia Murillo , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 13:46:03 -0000 > On 19 Mar 2018, at 13:40, Martin Thomson = wrote: >=20 > It's anything that *the site* initiates (not so much the browser). > Certificates are origin-scoped. Are they? is the private key needed in the re-use of the assertion? (I haven=E2=80=99t looked at this for ages) If not the you could push the ASN1 of the public cert somewhere not = scoped to the origin and have another site re-use it. (e.g. transfer it to an advert = iframe with postmessage) T. >=20 > On Mon, Mar 19, 2018 at 12:29 PM, Sergio Garcia Murillo > wrote: >> BTW, note that it is not "any call that I initiate until the = assertion >> expired" but "any call that the browser initiates until the assertion >> expired". >>=20 >> Best regards >> Sergio >>=20 >>=20 >> On 19/03/2018 12:54, Martin Thomson wrote: >>>=20 >>> Hmm, that's not that interesting. The number and disposition of >>> RTCPeerConnection instances in a page, and the way in which they are >>> used, is not something that is particularly visible. >>>=20 >>> On Mon, Mar 19, 2018 at 11:36 AM, Sergio Garcia Murillo >>> wrote: >>>>=20 >>>> Yep, exactly. >>>>=20 >>>>=20 >>>>=20 >>>> On 19/03/2018 12:30, Martin Thomson wrote: >>>>>=20 >>>>> So, concretely, the attack that would be enabled is that an origin >>>>> that operates a service could cause a user to present any of the >>>>> identities that it presented for use with that same service. >>>>>=20 >>>>> Thus, if I visit example.com and it is permitted to generate an >>>>> assertion for user@example.net, then the associated assertion = could be >>>>> used by example.com for any call that I initiate until the = assertion >>>>> expired. >>>>>=20 >>>>> On Mon, Mar 19, 2018 at 11:23 AM, Sergio Garcia Murillo >>>>> wrote: >>>>>>=20 >>>>>> On 19/03/2018 12:10, Martin Thomson wrote: >>>>>>=20 >>>>>> On Mon, Mar 19, 2018 at 10:58 AM, Tim Hollebeek >>>>>> wrote: >>>>>>=20 >>>>>> Yup, after understanding your concern, modifying the API to add a >>>>>> required >>>>>> nonce >>>>>> would be my suggestion, as it expresses the security requirement = in a >>>>>> simple >>>>>> way that's hard to get wrong. >>>>>>=20 >>>>>> FWIW, in the common case, there is a nonce: the certificate. = That is >>>>>> generally unique to a RTCPeerConnection instance. >>>>>>=20 >>>>>> But it can be saved and reused: >>>>>>=20 >>>>>> https://www.w3.org/TR/webrtc/#dom-rtcconfiguration >>>>>>=20 >>>>>> This option allows applications to establish key continuity. = An >>>>>> RTCCertificate can be persisted in [INDEXEDDB] and reused. = Persistence >>>>>> and >>>>>> reuse also avoids the cost of key generation. >>>>>>=20 >>>>>> Best regards >>>>>>=20 >>>>>> Sergio >>>>=20 >>>>=20 >>>>=20 >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Mar 19 06:46:38 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5BA1242F5 for ; Mon, 19 Mar 2018 06:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 icy6O6l5uC8J for ; Mon, 19 Mar 2018 06:46:33 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 705111270A3 for ; Mon, 19 Mar 2018 06:46:33 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id h21so15247372wmd.1 for ; Mon, 19 Mar 2018 06:46:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Av4HZSSmg/cflnQzRnFbru6KJ1gc2LlX4der2+CmkSc=; b=ZEwnKQ40bcZzn83jbiaj1zOEoPyUr+w5wDnATJFPSXz7CA50W81dgfucL95I7u7npJ GXh3ABog7mk04bVw2e+ojQxgM6NQCd4HA2j2JLJuonNza7THzNFzg3vyOYyyh9Spbfen mRwqaebGmvRp8SE3h2i6Y3L192ItdyjGy5r66SVDoO1iauUdeQ7gdv5yZttawKyTtSnk HWa0WiNoLkc/nR7YHRhvGN6II03ZpP0mmI5DUaxvWWmCj2oRviDBiz16GB/BriXucJ5g hyHqkgKvxWRoT68VSx89iN0rE4LSv4aY8bDNXc+1UQk86FeL8cIL9/mjmhNOmG5DDgCZ FLRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Av4HZSSmg/cflnQzRnFbru6KJ1gc2LlX4der2+CmkSc=; b=jvUALp4e6JxgwYdqLY3ccoEHpUrWrPx+F07EmMD0QCkzuyg+uRZhmCUj23dDV2UkI+ pXrs+Fh/52MjKO0EYzVqbQrBQIX6oS67UQucRY/IdszjglpHZ2FmohnSa1B0y1syvISQ tEfk2Mpitnb6Tk6JWAGLv43qEoAs40vVOH/nFuYS5d4PwpW6MkbCcfE3yIbYy00U8ZsV oEyYb7mkT7WCzS5pCoyvHWG7Zee3LARVlcxF6w7FnHWZWN98u5LhWiSZow1o/cbtGJdw Dh77AMioBii1CgGN95qD+SPeXXteMpsODcfBbzrbJJ7OEm9I5OJ6OFhVk+N2umVOTaez ZXHQ== X-Gm-Message-State: AElRT7FeuOkGM60hMhuYvbt2VFT3xfwRNZfRSFA+KLW/4pdM1PZEDGE3 OFMdaegOZRYPnN4GoMifbtUglG0a X-Google-Smtp-Source: AG47ELvXZU3wWe/GuHCmgY4PgSwCVfbD++kJVGZls0MIXnjmU6jXOcRBeL95D0FGMPKfyB80q+GT2A== X-Received: by 10.80.163.239 with SMTP id t44mr13750869edb.56.1521467191789; Mon, 19 Mar 2018 06:46:31 -0700 (PDT) Received: from [192.168.0.101] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id l23sm248280edc.27.2018.03.19.06.46.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 06:46:30 -0700 (PDT) To: Martin Thomson Cc: Tim Hollebeek , RTCWeb IETF References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> From: Sergio Garcia Murillo Message-ID: Date: Mon, 19 Mar 2018 14:46:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 13:46:37 -0000 Yes, that's what I meant (although not correctly expressed). The assertion can only be reused by the same browser (keying is stored securely and can't be exported) on same site. Most probably not a huge problem after all, but if the solution is simple maybe we should address it now. Best regards Sergio On 19/03/2018 14:40, Martin Thomson wrote: > It's anything that *the site* initiates (not so much the browser). > Certificates are origin-scoped. > > On Mon, Mar 19, 2018 at 12:29 PM, Sergio Garcia Murillo > wrote: >> BTW, note that it is not "any call that I initiate until the assertion >> expired" but "any call that the browser initiates until the assertion >> expired". >> >> Best regards >> Sergio >> >> >> On 19/03/2018 12:54, Martin Thomson wrote: >>> Hmm, that's not that interesting. The number and disposition of >>> RTCPeerConnection instances in a page, and the way in which they are >>> used, is not something that is particularly visible. >>> >>> On Mon, Mar 19, 2018 at 11:36 AM, Sergio Garcia Murillo >>> wrote: >>>> Yep, exactly. >>>> >>>> >>>> >>>> On 19/03/2018 12:30, Martin Thomson wrote: >>>>> So, concretely, the attack that would be enabled is that an origin >>>>> that operates a service could cause a user to present any of the >>>>> identities that it presented for use with that same service. >>>>> >>>>> Thus, if I visit example.com and it is permitted to generate an >>>>> assertion for user@example.net, then the associated assertion could be >>>>> used by example.com for any call that I initiate until the assertion >>>>> expired. >>>>> >>>>> On Mon, Mar 19, 2018 at 11:23 AM, Sergio Garcia Murillo >>>>> wrote: >>>>>> On 19/03/2018 12:10, Martin Thomson wrote: >>>>>> >>>>>> On Mon, Mar 19, 2018 at 10:58 AM, Tim Hollebeek >>>>>> wrote: >>>>>> >>>>>> Yup, after understanding your concern, modifying the API to add a >>>>>> required >>>>>> nonce >>>>>> would be my suggestion, as it expresses the security requirement in a >>>>>> simple >>>>>> way that's hard to get wrong. >>>>>> >>>>>> FWIW, in the common case, there is a nonce: the certificate. That is >>>>>> generally unique to a RTCPeerConnection instance. >>>>>> >>>>>> But it can be saved and reused: >>>>>> >>>>>> https://www.w3.org/TR/webrtc/#dom-rtcconfiguration >>>>>> >>>>>> This option allows applications to establish key continuity. An >>>>>> RTCCertificate can be persisted in [INDEXEDDB] and reused. Persistence >>>>>> and >>>>>> reuse also avoids the cost of key generation. >>>>>> >>>>>> Best regards >>>>>> >>>>>> Sergio >>>> >>>> From nobody Mon Mar 19 06:57:59 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A189126D45 for ; Mon, 19 Mar 2018 06:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_LOW=-0.7, 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=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 KLKU4lVW2_NH for ; Mon, 19 Mar 2018 06:57:55 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 916F31204DA for ; Mon, 19 Mar 2018 06:57:55 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id f19so2759339wmc.0 for ; Mon, 19 Mar 2018 06:57:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=OxYsZw8+TrlUpGH70BXry3kV314kc7ImNAr7BaN1F0s=; b=pteVGKjDCxE87r0590jIJxyVGwOKsHhfpPMcz5DZsPNHOOpwqAoTyrijKR54Bb1K3Q gE1oFj1z8o7AKMXXExZf/Lc9e5dXoJdAy9ZKT1FMr1/g/kL9N64uYnJvyAOCjJxdgODl 1WoADV7ZSJkDlAW1icEsJozepwBM+XkJIXuy6vbLQ6NG01ZWshT/uInbc/PbyfgAKISK eTbSmr6IVCGzVnpZjUqJLKutyx5nwfVPvd/+7J+TDHWyHpKjoWrWcAsMQiDQHCVpD5Yk L2MdQ8B1kFFniAs71Bd0M4NbS04qxK0GQcF+t3OzoxT0a2uq8t7RLUjpTfSbj7wuIf60 cmtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=OxYsZw8+TrlUpGH70BXry3kV314kc7ImNAr7BaN1F0s=; b=FpX3kes/xoS1OEL0KCgihU+wIrpi5E4gcuikLHQNQVpbyku6GcbkFw276LmF9OINsi dklIAG/yhMdHxaWoIElFsBJKcP4EFpoc2Hzwp+ggxm9g8fQg3aj7GmWXmCyOoJGtZ0Fa vSqBL6m9HIOZjTfLCvjDS+niDnZ1BnrMRwEePCtoFuCX8/O352MED6DrpHa1mGuLnj8K 12ah62xMZ2ORgzrPXQ8ngSFJSbfeIQQxN8eexWlbtRVNZ2gSKQx71BoPTcDJgJntpvqz CngzGuG6I2zCFit0iCc1McMmBdgQH7DCzo6mlPk19MyOEJG5V/qfzr+TJ4ASEmPFmFIG QB9w== X-Gm-Message-State: AElRT7GZcqyWwYo2AwpkPEBa2o7LxNxktuThVv+atosPN0gm4uDRkQzL rrUueOPET4Adctdsb/SpKw9Fv6Kw X-Google-Smtp-Source: AG47ELvsmLjwtEVWsiN8RTGwmSZpVRiMnwD9K8Yq+l8TXc29Zz7LvmftlRJswjc8/CkuIxf4Vphe7g== X-Received: by 10.80.164.14 with SMTP id u14mr13183828edb.115.1521467873720; Mon, 19 Mar 2018 06:57:53 -0700 (PDT) Received: from [192.168.0.101] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id c35sm220319edb.87.2018.03.19.06.57.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 06:57:52 -0700 (PDT) To: westhawk , Martin Thomson Cc: RTCWeb IETF References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> From: Sergio Garcia Murillo Message-ID: <5d59eec9-62d6-94e4-517e-da6d0b9e3c41@gmail.com> Date: Mon, 19 Mar 2018 14:57:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> Content-Type: multipart/alternative; boundary="------------C0A745B00A3ECBE46D0365BD" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 13:57:57 -0000 This is a multi-part message in MIME format. --------------C0A745B00A3ECBE46D0365BD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 19/03/2018 14:45, westhawk wrote: >> On 19 Mar 2018, at 13:40, Martin Thomson wrote: >> >> It's anything that *the site* initiates (not so much the browser). >> Certificates are origin-scoped. > Are they? is the private key needed in the re-use of the assertion? > (I haven’t looked at this for ages) > If not the you could push the ASN1 of the public cert somewhere not scoped to the > origin and have another site re-use it. (e.g. transfer it to an advert iframe with postmessage) After checking if further, that may not be clearly explicit on the webrtc w3c spec: For the purposes of this API, the[[Certificate]] slot contains unstructured binary data. No mechanism is provided for applications to access the[[KeyingMaterial]] internal slot. Implementations/MUST/support applications storing and retrieving|RTCCertificate|objects from persistent storage. In implementations where an|RTCCertificate| might not directly hold private keying material (it might be stored in a secure module), a reference to the private key can be held in the[[KeyingMaterial]] internal slot, allowing the private key to be stored and used. So it is not clear to me if certificates are origin-scoped or if the key materials could be exported outside of the browser. Worst case, certificate could be exported and identity assertion reused even by a different service. Best regards Sergio --------------C0A745B00A3ECBE46D0365BD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 19/03/2018 14:45, westhawk wrote:
On 19 Mar 2018, at 13:40, Martin Thomson <martin.thomson@gmail.com> wrote:

It's anything that *the site* initiates (not so much the browser).
Certificates are origin-scoped.

Are they? is the private key needed in the re-use of the assertion?
(I haven’t looked at this for ages)
If not the you could push the ASN1 of the public cert somewhere not scoped to the
origin and have another site re-use it. (e.g. transfer it to an advert iframe with postmessage)

After checking if further, that may not be clearly explicit on the webrtc w3c spec:

For the purposes of this API, the [[Certificate]] slot contains unstructured binary data. No mechanism is provided for applications to access the [[KeyingMaterial]] internal slot. Implementations MUST support applications storing and retrieving RTCCertificate objects from persistent storage. In implementations where an RTCCertificate might not directly hold private keying material (it might be stored in a secure module), a reference to the private key can be held in the [[KeyingMaterial]] internal slot, allowing the private key to be stored and used.

So it is not clear to me if certificates are origin-scoped or if the key materials could be exported outside of the browser. Worst case, certificate could be exported and identity assertion reused even by a different service.

Best regards
Sergio

--------------C0A745B00A3ECBE46D0365BD-- From nobody Mon Mar 19 07:37:45 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BFA126FB3 for ; Mon, 19 Mar 2018 07:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Tki8854HtHuW for ; Mon, 19 Mar 2018 07:37:39 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 668BC1241F3 for ; Mon, 19 Mar 2018 07:37:39 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id 71so3076274oie.12 for ; Mon, 19 Mar 2018 07:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=VT3Ob43EX7a37g88IWeLkr/eoefJ2gWFPEaZPExE4eA=; b=TVrJo+gx4DdPHfYEtiRfbRyhlUlqSRC7ArwZSmB3AaZmsGVTr4W3Ad8Vhj7ExOm/jA 1pp+uV/uYYQYBIMDdJBHL9pdPnathh0SlS2XXOQ6Zg8IpaBYM/nnKyLHflgPYXXCcVaL sC3KoCQuW0qLUISbslhngV3StgrHeSE+wpnGHiqnk6rQSvTw9gVzQwJ26OMoYz6Yjmv5 JzwRI5t0aQaWZA3jXL98c7YM2g91obUInmpxhRGOOtydBjtkffqcHziCaKp82wBU+OQ0 ucrA7+A7I9oyo+osZWpAinTyptH7Ethqx/KTETBVYD1a9DWLvcdMtzksKChOgr0UrfrT rQNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=VT3Ob43EX7a37g88IWeLkr/eoefJ2gWFPEaZPExE4eA=; b=AyWJPXlVAKILylKWFkttbrE3hvCfaVPqYAUdSNSC0qNEI0oGkkFyoRx4hX40p52JPi jDH0nIR3O80q2CyP8RdNGlKIuh6hSpkgtzT6NkgoFMWVW/Heu433Pd7CuGCO12a6wczi a9D+REJ08pIUTsTbTqbmOuCzmtnGDpHipgokFSictG5T8+D1vQQcKIVVfewfyo1dN+wV n9i6YnsJyWTKR7jXLT1GChx4GvYfqVtwNzHuIB7qzByXo4rn3ykkNia+Vm3iH9g4AaCt SpZgazkXlb5kzzA+AhwAi7ZNElDUS0s256Bmq4do+jLjI/ieYbereTLNyFndKi1Dd7cV soiw== X-Gm-Message-State: AElRT7Hvh/faGf9PGw54yfygP/S4AJq6wrHEP04FDd1obWLBEv///Pdj aw+xHuws5ZiPZq1j30tDJ0cInwuaPwr89nb7sHU= X-Google-Smtp-Source: AG47ELvv/pwPzzXmsGYzEJ/HYfEw3LuDKmXDVyNvdSolBS2b7dltznofB+5NoWVWZosmS/a3n8IIANPI/7s/6xAHLoQ= X-Received: by 10.202.198.141 with SMTP id w135mr7465058oif.215.1521470258737; Mon, 19 Mar 2018 07:37:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Mon, 19 Mar 2018 07:37:38 -0700 (PDT) In-Reply-To: <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> From: Martin Thomson Date: Mon, 19 Mar 2018 14:37:38 +0000 Message-ID: To: westhawk Cc: Sergio Garcia Murillo , RTCWeb IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 14:37:41 -0000 Yes, you can't use an assertion without being able to prove control over the private key (this is transitively ensured via the fingerprints and certificate). On Mon, Mar 19, 2018 at 1:45 PM, westhawk wrote: > > >> On 19 Mar 2018, at 13:40, Martin Thomson wrot= e: >> >> It's anything that *the site* initiates (not so much the browser). >> Certificates are origin-scoped. > > Are they? is the private key needed in the re-use of the assertion? > (I haven=E2=80=99t looked at this for ages) > If not the you could push the ASN1 of the public cert somewhere not scope= d to the > origin and have another site re-use it. (e.g. transfer it to an advert if= rame with postmessage) > > T. > > > >> >> On Mon, Mar 19, 2018 at 12:29 PM, Sergio Garcia Murillo >> wrote: >>> BTW, note that it is not "any call that I initiate until the assertion >>> expired" but "any call that the browser initiates until the assertion >>> expired". >>> >>> Best regards >>> Sergio >>> >>> >>> On 19/03/2018 12:54, Martin Thomson wrote: >>>> >>>> Hmm, that's not that interesting. The number and disposition of >>>> RTCPeerConnection instances in a page, and the way in which they are >>>> used, is not something that is particularly visible. >>>> >>>> On Mon, Mar 19, 2018 at 11:36 AM, Sergio Garcia Murillo >>>> wrote: >>>>> >>>>> Yep, exactly. >>>>> >>>>> >>>>> >>>>> On 19/03/2018 12:30, Martin Thomson wrote: >>>>>> >>>>>> So, concretely, the attack that would be enabled is that an origin >>>>>> that operates a service could cause a user to present any of the >>>>>> identities that it presented for use with that same service. >>>>>> >>>>>> Thus, if I visit example.com and it is permitted to generate an >>>>>> assertion for user@example.net, then the associated assertion could = be >>>>>> used by example.com for any call that I initiate until the assertion >>>>>> expired. >>>>>> >>>>>> On Mon, Mar 19, 2018 at 11:23 AM, Sergio Garcia Murillo >>>>>> wrote: >>>>>>> >>>>>>> On 19/03/2018 12:10, Martin Thomson wrote: >>>>>>> >>>>>>> On Mon, Mar 19, 2018 at 10:58 AM, Tim Hollebeek >>>>>>> wrote: >>>>>>> >>>>>>> Yup, after understanding your concern, modifying the API to add a >>>>>>> required >>>>>>> nonce >>>>>>> would be my suggestion, as it expresses the security requirement i= n a >>>>>>> simple >>>>>>> way that's hard to get wrong. >>>>>>> >>>>>>> FWIW, in the common case, there is a nonce: the certificate. That = is >>>>>>> generally unique to a RTCPeerConnection instance. >>>>>>> >>>>>>> But it can be saved and reused: >>>>>>> >>>>>>> https://www.w3.org/TR/webrtc/#dom-rtcconfiguration >>>>>>> >>>>>>> This option allows applications to establish key continuity. A= n >>>>>>> RTCCertificate can be persisted in [INDEXEDDB] and reused. Persiste= nce >>>>>>> and >>>>>>> reuse also avoids the cost of key generation. >>>>>>> >>>>>>> Best regards >>>>>>> >>>>>>> Sergio >>>>> >>>>> >>>>> >>> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Mon Mar 19 07:43:05 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D841275FD for ; Mon, 19 Mar 2018 07:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ho7Hmy5StRFc for ; Mon, 19 Mar 2018 07:43:02 -0700 (PDT) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (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 3D8981241F3 for ; Mon, 19 Mar 2018 07:43:02 -0700 (PDT) Received: by mail-ot0-x22d.google.com with SMTP id r30-v6so17645781otr.2 for ; Mon, 19 Mar 2018 07:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=VqrmWgVmEFUEIjEtiP4S+J2mVOeZ4HIJ/cGp63sw9Mg=; b=TUtA9GvW4yqZU3bHVcRJbfXBYCptEF3X6W5r4o9cdSDmaG4D2BJZSiGozfmPm+KDjY b8SsswsnhyFgk/YJEKseTG+tXv34pWBKXGTK/5rZJ1BDHKGaCZlDkMreIVymc3dTENlj lv0hwKmD9LurPP3eNVKgdluFf2VX5Vl33BBpQKlYcxuosp9EKCxDOwYvr3NI1DprrqtF USkSgCImKRm5TkXdYvY2yCweBuArlnwSKhraYRrFVTWIQHi7pDv1WGQqx4TuLC3yeCcw S5w1GBFLyhs0Chn4l1cd1CQgJaz53NnmDFRyVijJjgUL4ZrDzgj53pl4VFltwxy4cULP 0JMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=VqrmWgVmEFUEIjEtiP4S+J2mVOeZ4HIJ/cGp63sw9Mg=; b=aF1uFrfLyNszdOSeFcoHvihjd7UIWJvJtiS4ckyGET9zF98phOdqu+SxKwz1/e6JeJ /QOVrJQ9mmqFEeTdaDkcndivNM/XhtMRZ4Jl3Ye39gkZYy1kYRxHULPhHNHRCnyOwI4L BC5tWm/dR+VZXDHYfXO5V1OOJvvP60HJinNNJWnbgcdAx9zojD2x8RkzzkE6fW50RonY LG6D/78PiN3/Atvtu6BzpnJ41bt5AwRoGAZ0lFoxNMlr2e3MpSC1+9ka+X05VH8uEWp1 sP2oMYVXreP4tZVcINr6izmIX9Sxt1Ag+xjYUsaytSm3S8B2OAtkPz769+ePeBLx9pDP 84jA== X-Gm-Message-State: AElRT7FybXVaqhAVoXuU3TH2JMNO88mw3qwd5Pdty2WeCsZX49WrnWb/ xcGORtzrZZkTczVHBU6JtqkO5GfPVLjv3nL6f2WbFg== X-Google-Smtp-Source: AG47ELuwbKNxcyu1MGo5I84cyTeFzPURYBkzLF0juE0sU8PXkwqLA6V0XyYpC6hCWPo8cpV07ulB9YPGotQQQ8uGp8s= X-Received: by 2002:a9d:4e10:: with SMTP id p16-v6mr8347021otf.15.1521470581564; Mon, 19 Mar 2018 07:43:01 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Mon, 19 Mar 2018 07:43:00 -0700 (PDT) In-Reply-To: <5d59eec9-62d6-94e4-517e-da6d0b9e3c41@gmail.com> References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> <5d59eec9-62d6-94e4-517e-da6d0b9e3c41@gmail.com> From: Martin Thomson Date: Mon, 19 Mar 2018 14:43:00 +0000 Message-ID: To: Sergio Garcia Murillo Cc: westhawk , RTCWeb IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 14:43:04 -0000 As a practical matter, if the browser were to use the same certificate for multiple origins, then it would create a massive privacy problem that enables linkability (aka user tracking). I couldn't find that written down, but I thought it was. If it isn't written down, then we should correct that. On Mon, Mar 19, 2018 at 1:57 PM, Sergio Garcia Murillo wrote: > On 19/03/2018 14:45, westhawk wrote: > > On 19 Mar 2018, at 13:40, Martin Thomson wrote= : > > It's anything that *the site* initiates (not so much the browser). > Certificates are origin-scoped. > > Are they? is the private key needed in the re-use of the assertion? > (I haven=E2=80=99t looked at this for ages) > If not the you could push the ASN1 of the public cert somewhere not scope= d > to the > origin and have another site re-use it. (e.g. transfer it to an advert > iframe with postmessage) > > > After checking if further, that may not be clearly explicit on the webrtc > w3c spec: > > For the purposes of this API, the [[Certificate]] slot contains unstructu= red > binary data. No mechanism is provided for applications to access the > [[KeyingMaterial]] internal slot. Implementations MUST support applicatio= ns > storing and retrieving RTCCertificate objects from persistent storage. In > implementations where an RTCCertificate might not directly hold private > keying material (it might be stored in a secure module), a reference to t= he > private key can be held in the [[KeyingMaterial]] internal slot, allowing > the private key to be stored and used. > > So it is not clear to me if certificates are origin-scoped or if the key > materials could be exported outside of the browser. Worst case, certifica= te > could be exported and identity assertion reused even by a different servi= ce. > > Best regards > Sergio > From nobody Mon Mar 19 07:57:59 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FAD127867 for ; Mon, 19 Mar 2018 07:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 VojiZZzjrz87 for ; Mon, 19 Mar 2018 07:57:55 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) (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 E564E126C0F for ; Mon, 19 Mar 2018 07:57:54 -0700 (PDT) Received: (qmail 64079 invoked from network); 19 Mar 2018 14:57:52 -0000 X-APM-Authkey: 255286/0(159927/0) 1330 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 19 Mar 2018 14:57:52 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 9C89918A0693; Mon, 19 Mar 2018 14:57:52 +0000 (GMT) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id y9FtPLYM7yzn; Mon, 19 Mar 2018 14:57:52 +0000 (GMT) Received: from [192.67.4.84] (unknown [192.67.4.84]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 69C2618A0566; Mon, 19 Mar 2018 14:57:52 +0000 (GMT) From: westhawk Message-Id: <9F29E525-85AE-4E04-AF8E-14E1F4DD0291@westhawk.co.uk> Content-Type: multipart/alternative; boundary="Apple-Mail=_D59FA5AE-7C7A-4B68-899E-DAD7357F606F" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 19 Mar 2018 14:57:51 +0000 In-Reply-To: Cc: Sergio Garcia Murillo , RTCWeb IETF To: Martin Thomson References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> <5d59eec9-62d6-94e4-517e-da6d0b9e3c41@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 14:57:58 -0000 --Apple-Mail=_D59FA5AE-7C7A-4B68-899E-DAD7357F606F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 19 Mar 2018, at 14:43, Martin Thomson = wrote: >=20 > As a practical matter, if the browser were to use the same certificate > for multiple origins, then it would create a massive privacy problem > that enables linkability (aka user tracking). I couldn't find that > written down, but I thought it was. If it isn't written down, then we > should correct that. As currently implemented you can=E2=80=99t move a cert from one origin = to another. I just had a discussion with Bernard about the language here - since it = also means that certs can not be backed up. - lose your phone, lose your = certs. https://github.com/w3c/webrtc-pc/issues/1694 = Tim. >=20 > On Mon, Mar 19, 2018 at 1:57 PM, Sergio Garcia Murillo > wrote: >> On 19/03/2018 14:45, westhawk wrote: >>=20 >> On 19 Mar 2018, at 13:40, Martin Thomson = wrote: >>=20 >> It's anything that *the site* initiates (not so much the browser). >> Certificates are origin-scoped. >>=20 >> Are they? is the private key needed in the re-use of the assertion? >> (I haven=E2=80=99t looked at this for ages) >> If not the you could push the ASN1 of the public cert somewhere not = scoped >> to the >> origin and have another site re-use it. (e.g. transfer it to an = advert >> iframe with postmessage) >>=20 >>=20 >> After checking if further, that may not be clearly explicit on the = webrtc >> w3c spec: >>=20 >> For the purposes of this API, the [[Certificate]] slot contains = unstructured >> binary data. No mechanism is provided for applications to access the >> [[KeyingMaterial]] internal slot. Implementations MUST support = applications >> storing and retrieving RTCCertificate objects from persistent = storage. In >> implementations where an RTCCertificate might not directly hold = private >> keying material (it might be stored in a secure module), a reference = to the >> private key can be held in the [[KeyingMaterial]] internal slot, = allowing >> the private key to be stored and used. >>=20 >> So it is not clear to me if certificates are origin-scoped or if the = key >> materials could be exported outside of the browser. Worst case, = certificate >> could be exported and identity assertion reused even by a different = service. >>=20 >> Best regards >> Sergio >>=20 --Apple-Mail=_D59FA5AE-7C7A-4B68-899E-DAD7357F606F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 19 Mar 2018, at 14:43, Martin Thomson <martin.thomson@gmail.com> wrote:

As a = practical matter, if the browser were to use the same certificate
for multiple origins, then it would create a massive privacy = problem
that enables linkability (aka user tracking). =  I couldn't find that
written down, but I thought it = was.  If it isn't written down, then we
should = correct that.

As currently implemented you can=E2=80=99t move a = cert from one origin to another.
I just had a discussion with = Bernard about the language here - since it also
means that = certs can not be backed up. - lose your phone, lose your = certs.


Tim.


On Mon, Mar = 19, 2018 at 1:57 PM, Sergio Garcia Murillo
<sergio.garcia.murillo@gmail.com> wrote:
On 19/03/2018 14:45, = westhawk wrote:

On 19 Mar 2018, at 13:40, = Martin Thomson <martin.thomson@gmail.com> wrote:

It's anything that *the site* initiates (not so much the = browser).
Certificates are origin-scoped.

Are they? is the private key needed in the re-use of the = assertion?
(I haven=E2=80=99t looked at this for ages)
If not the you could push the ASN1 of the public cert = somewhere not scoped
to the
origin and have = another site re-use it. (e.g. transfer it to an advert
iframe with postmessage)


After checking if further, that may not be clearly explicit = on the webrtc
w3c spec:

For = the purposes of this API, the [[Certificate]] slot contains = unstructured
binary data. No mechanism is provided for = applications to access the
[[KeyingMaterial]] internal = slot. Implementations MUST support applications
storing = and retrieving RTCCertificate objects from persistent storage. In
implementations where an RTCCertificate might not directly = hold private
keying material (it might be stored in a = secure module), a reference to the
private key can be held = in the [[KeyingMaterial]] internal slot, allowing
the = private key to be stored and used.

So it is = not clear to me if certificates are origin-scoped or if the key
materials could be exported outside of the browser. Worst = case, certificate
could be exported and identity assertion = reused even by a different service.

Best = regards
Sergio


= --Apple-Mail=_D59FA5AE-7C7A-4B68-899E-DAD7357F606F-- From nobody Mon Mar 19 08:04:10 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3866C12708C for ; Mon, 19 Mar 2018 08:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_LOW=-0.7, 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=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 ZzgdczCzt5ki for ; Mon, 19 Mar 2018 08:03:59 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 AAD41126C0F for ; Mon, 19 Mar 2018 08:03:58 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id h21so15756487wmd.1 for ; Mon, 19 Mar 2018 08:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=FZDc8O/IicCgpdcLaS98DXN0zYgTWQmlNm808IV0xog=; b=GcBoTF64vkZV8h8Enev1LhMdW0brGXc8DNdNemgFA9OePf7a6Dz45W89QQ8ByMwOaj hp7pANLYYNp3WuWaxuTTp8dXKz5KCw6cjbi5U2vM4WIyJAr5npXNLKTMBthvRWL+c95O JgPid4n+2uqME+PQA7pf0sIIasYWkVR0btOr0rnUlAEZiv3wAlNgB3DwDoXXGdIDrch5 UIeSgRyki9wH0HKXNswn52zwr2cmgv7aIHOA/dA0Hv6SjZ8sggX2FvZW7Ei/1Y728jd6 /lGpdzP+WPnxcbwG5dU2FEcC4WgJFX2s40NfZA6Db/HfReBgFAfAZePi2u7rtJSDTqg4 UdkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=FZDc8O/IicCgpdcLaS98DXN0zYgTWQmlNm808IV0xog=; b=YYprw+XmXILjK/KZddo9sIC2JRju+rJG9aeLG3eXb1LnP21z4nSYfdEL0K8ORiDWeS KGtdo57xJa55wQ0UeeYD4jYLM4zvy5nryj09UyiuUtfs6bkcim9sWmsmWaX8JGkvzVe6 npwsgc6BZmHwTMAzGlTiJ8FzZyGdNS0eVQ5tSf2zH4hAEIfqAvXrCYGxCQZvm9riHryd 6Kmn7ZxY/gs22dPphoYgjswnuO01q+gjk8lCi1yxc68/VfZh27U05pPqAU85N0Vi4SfL 5QjUedLdhPMF71Q3H7F0ikaGw+Z9KcGbLsrHeqT+wRhHOjMXvsEynBvY5mP8YcO7lQHj 613A== X-Gm-Message-State: AElRT7GL5HKfofKP/qyMW6cwQrUQlCTB1CpGTLrlhPSarRrsbKl8h7Yc iqoSAZFjtxVgTI7ALgVy1epQ1Xl6 X-Google-Smtp-Source: AG47ELt1iTzTPHg2a8JrhHufOC9dsl8AncoVtlUHEEFeALCYEcDZrleRndAaJGhihdvjc+Pk0wVVyQ== X-Received: by 10.80.187.75 with SMTP id y69mr13982910ede.251.1521471836979; Mon, 19 Mar 2018 08:03:56 -0700 (PDT) Received: from [192.168.0.101] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id a88sm312531edf.64.2018.03.19.08.03.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 08:03:56 -0700 (PDT) To: Martin Thomson Cc: westhawk , RTCWeb IETF References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> <5d59eec9-62d6-94e4-517e-da6d0b9e3c41@gmail.com> From: Sergio Garcia Murillo Message-ID: <74c8e7ba-13f7-b92b-29b5-f4d43a6c9978@gmail.com> Date: Mon, 19 Mar 2018 16:03:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8C9B60905E6BFCF6CE7DDC38" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 15:04:01 -0000 This is a multi-part message in MIME format. --------------8C9B60905E6BFCF6CE7DDC38 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Found it, they are not origin bounded: The|RTCCertificate|object can be stored and retrieved from persistent storage by an application. When auser agent is required to obtain a structured clone [HTML51 ] of an|RTCCertificate|object, it performs the following steps And on HTML5 spec: Cloneable objects support being cloned acrossevent loops . That is, they support being cloned across|Document |and|Worker |boundaries, including across|Document |s of differentorigins . Not all objects arecloneable objects and not all aspects of objects that arecloneable objects are necessarily preserved when cloned. So you can perfectly do the following: RTCPeerConnection.generateCertificate({     name: 'RSASSA-PKCS1-v1_5',     hash: 'SHA-256',     modulusLength: 2048,     publicExponent: new Uint8Array([1, 0, 1]) }).then(function(cert) {     windowInOderDomain.postMessage(cert,"*") }); And the other window will able to reuse it. However, the certificate won't be serialized in anyway that could be extracted from the browser. Best regards Sergio On 19/03/2018 15:43, Martin Thomson wrote: > As a practical matter, if the browser were to use the same certificate > for multiple origins, then it would create a massive privacy problem > that enables linkability (aka user tracking). I couldn't find that > written down, but I thought it was. If it isn't written down, then we > should correct that. > > On Mon, Mar 19, 2018 at 1:57 PM, Sergio Garcia Murillo > wrote: >> On 19/03/2018 14:45, westhawk wrote: >> >> On 19 Mar 2018, at 13:40, Martin Thomson wrote: >> >> It's anything that *the site* initiates (not so much the browser). >> Certificates are origin-scoped. >> >> Are they? is the private key needed in the re-use of the assertion? >> (I haven’t looked at this for ages) >> If not the you could push the ASN1 of the public cert somewhere not scoped >> to the >> origin and have another site re-use it. (e.g. transfer it to an advert >> iframe with postmessage) >> >> >> After checking if further, that may not be clearly explicit on the webrtc >> w3c spec: >> >> For the purposes of this API, the [[Certificate]] slot contains unstructured >> binary data. No mechanism is provided for applications to access the >> [[KeyingMaterial]] internal slot. Implementations MUST support applications >> storing and retrieving RTCCertificate objects from persistent storage. In >> implementations where an RTCCertificate might not directly hold private >> keying material (it might be stored in a secure module), a reference to the >> private key can be held in the [[KeyingMaterial]] internal slot, allowing >> the private key to be stored and used. >> >> So it is not clear to me if certificates are origin-scoped or if the key >> materials could be exported outside of the browser. Worst case, certificate >> could be exported and identity assertion reused even by a different service. >> >> Best regards >> Sergio >> --------------8C9B60905E6BFCF6CE7DDC38 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Found it, they are not origin bounded:

The RTCCertificate object can be stored and retrieved from persistent storage by an application. When a user agent is required to obtain a structured clone [HTML51] of an RTCCertificate object, it performs the following steps

And on HTML5 spec:

Cloneable objects support being cloned across event loops. That is, they support being cloned across Documentand Worker boundaries, including across Documents of different origins. Not all objects are cloneable objectsand not all aspects of objects that are cloneable objects are necessarily preserved when cloned.

So you can perfectly do the following:

RTCPeerConnection.generateCertificate({
    name: 'RSASSA-PKCS1-v1_5',
    hash: 'SHA-256',
    modulusLength: 2048,
    publicExponent: new Uint8Array([1, 0, 1])
}).then(function(cert) {
    windowInOderDomain.postMessage(cert,"*")
});

And the other window will able to reuse it. However, the certificate won't be serialized in anyway that could be extracted from the browser.

Best regards
Sergio


On 19/03/2018 15:43, Martin Thomson wrote:
As a practical matter, if the browser were to use the same certificate
for multiple origins, then it would create a massive privacy problem
that enables linkability (aka user tracking).  I couldn't find that
written down, but I thought it was.  If it isn't written down, then we
should correct that.

On Mon, Mar 19, 2018 at 1:57 PM, Sergio Garcia Murillo
<sergio.garcia.murillo@gmail.com> wrote:

On 19/03/2018 14:45, westhawk wrote:

On 19 Mar 2018, at 13:40, Martin Thomson <martin.thomson@gmail.com> wrote:

It's anything that *the site* initiates (not so much the browser).
Certificates are origin-scoped.

Are they? is the private key needed in the re-use of the assertion?
(I haven’t looked at this for ages)
If not the you could push the ASN1 of the public cert somewhere not scoped
to the
origin and have another site re-use it. (e.g. transfer it to an advert
iframe with postmessage)


After checking if further, that may not be clearly explicit on the webrtc
w3c spec:

For the purposes of this API, the [[Certificate]] slot contains unstructured
binary data. No mechanism is provided for applications to access the
[[KeyingMaterial]] internal slot. Implementations MUST support applications
storing and retrieving RTCCertificate objects from persistent storage. In
implementations where an RTCCertificate might not directly hold private
keying material (it might be stored in a secure module), a reference to the
private key can be held in the [[KeyingMaterial]] internal slot, allowing
the private key to be stored and used.

So it is not clear to me if certificates are origin-scoped or if the key
materials could be exported outside of the browser. Worst case, certificate
could be exported and identity assertion reused even by a different service.

Best regards
Sergio


--------------8C9B60905E6BFCF6CE7DDC38-- From nobody Mon Mar 19 08:05:41 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC2F12708C for ; Mon, 19 Mar 2018 08:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 enqCbfXmlq0w for ; Mon, 19 Mar 2018 08:05:38 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 D3B08126C0F for ; Mon, 19 Mar 2018 08:05:37 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id s206so13123663wme.0 for ; Mon, 19 Mar 2018 08:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=KWPo3BjZ0cexrnCDVZ9ooFwIndNyvxFmmReIJ7KassY=; b=CXP6w3niJ3FqFjfRMXRTd14UwTfQN1BDHzbsD3JNKQT/vzUMErfSzAh0crXA5hemPd inB+tLOyYrt5HXZS+OFxHYeiraulDpx4KVW0o+PVqv5vip+ajmztRcrTDws9ZRDC26Wt p0JG74VNx0oPmkLNskK7jFTCRACZsLMMdYAvmBP7R4C7MdhDTaDgwKuINyEYCVPy8mo0 eae5TNIy7Ldrk7QZ7iGiHsV9tBnpgoy+R6ndDt0u0F1OeDciV6d4+cJN9aTum1NENRDA vancTFrmwcSSS2Yt7tcYuv1ke603v066v0AtIr4TumHWHVu/PEFs19aD5KUv6mqBkon7 KG3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=KWPo3BjZ0cexrnCDVZ9ooFwIndNyvxFmmReIJ7KassY=; b=JVyVyx7Stsm5011XuliWP5h0D9S6Zop5VRaTEL8GxPD0euK9QI88f99l4RKyJQC0sy nbgvqSVBGECWotldwJ96IUYEpIQ94tMVPKfJVuSlfPJsTwtvv9Y/+SEJWtpuxmK7A6fn udK+hZNw1lCyqckA/yOyTMhgJGM8dllWa3kZBQ7VlluGTUB5BP2qU48NK7rkYh8ZQR1B osOJODZ1xRkQY6pID8dqjWViPIxi9HnDBvCDRKv7Qahd9VQ9ZJPm2DnApdUPqjsmvh3M GxJVpdq0IGpxpXH4ZYs4L5VIijY54hU9uUrRmtzrL6tbHeIaO8Dq5+B2+oWaQ4nULp5v JlNg== X-Gm-Message-State: AElRT7HQYzB4XQqiMMv6luUWva7KIpyeAN43lsVzxyGruTSEaXjREkqT qOjJnuo4FWPduOQq7FWc+opyXKdM X-Google-Smtp-Source: AG47ELvThYKJer2A+b2UL9e2YGwPjf+XBSKeiI8Acno6QtDHpZnws+/Ugpyulv68GHa5Bw4p2wXKfA== X-Received: by 10.80.193.146 with SMTP id m18mr13562765edf.249.1521471936205; Mon, 19 Mar 2018 08:05:36 -0700 (PDT) Received: from [192.168.0.101] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id k7sm313665edb.51.2018.03.19.08.05.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 08:05:35 -0700 (PDT) To: westhawk , Martin Thomson Cc: RTCWeb IETF References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> <5d59eec9-62d6-94e4-517e-da6d0b9e3c41@gmail.com> <9F29E525-85AE-4E04-AF8E-14E1F4DD0291@westhawk.co.uk> From: Sergio Garcia Murillo Message-ID: <3c4a0dc3-5dec-96f0-6a60-b0880cb23574@gmail.com> Date: Mon, 19 Mar 2018 16:05:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <9F29E525-85AE-4E04-AF8E-14E1F4DD0291@westhawk.co.uk> Content-Type: multipart/alternative; boundary="------------B8CDC5188073FE956E94211F" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 15:05:40 -0000 This is a multi-part message in MIME format. --------------B8CDC5188073FE956E94211F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 19/03/2018 15:57, westhawk wrote: > > >> On 19 Mar 2018, at 14:43, Martin Thomson > > wrote: >> >> As a practical matter, if the browser were to use the same certificate >> for multiple origins, then it would create a massive privacy problem >> that enables linkability (aka user tracking).  I couldn't find that >> written down, but I thought it was.  If it isn't written down, then we >> should correct that. > > As currently implemented you can’t move a cert from one origin to another. > I just had a discussion with Bernard about the language here - since > it also > means that certs can not be backed up. - lose your phone, lose your certs. > > https://github.com/w3c/webrtc-pc/issues/1694 > You can't export/import them (at least from js), but you can move it between origins (or to a web worker) via postMessage within the same browser. Best regards Sergio --------------B8CDC5188073FE956E94211F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 19/03/2018 15:57, westhawk wrote:


On 19 Mar 2018, at 14:43, Martin Thomson <martin.thomson@gmail.com> wrote:

As a practical matter, if the browser were to use the same certificate
for multiple origins, then it would create a massive privacy problem
that enables linkability (aka user tracking).  I couldn't find that
written down, but I thought it was.  If it isn't written down, then we
should correct that.

As currently implemented you can’t move a cert from one origin to another.
I just had a discussion with Bernard about the language here - since it also
means that certs can not be backed up. - lose your phone, lose your certs.


You can't export/import them (at least from js), but you can move it between origins (or to a web worker) via postMessage within the same browser.

Best regards

Sergio

--------------B8CDC5188073FE956E94211F-- From nobody Mon Mar 19 08:47:30 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC61127871 for ; Mon, 19 Mar 2018 08:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 u9M8QB22fL2Z for ; Mon, 19 Mar 2018 08:47:27 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.201]) (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 EDB46129C6B for ; Mon, 19 Mar 2018 08:47:26 -0700 (PDT) Received: from [216.82.242.46] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-9.bemta-8.messagelabs.com id 7E/18-15733-E8BDFAA5; Mon, 19 Mar 2018 15:47:26 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSa0gUURTH987M7k62E3fXVY+iURtBWZpBj43 K6kNh7yKjMMFma9rd2ofsrGIFZVJWLvbCR9ljC03NEu0BFhWVJD3RMtE0Sy0rH4SKUWnu0oyz Wn0ZfszvnPM/d+bSpKZNEUJzKU7OYWMtOoUfVROZHxuR+a4sLurpFUpf/9KL9KXew0r9Z28Fu ZiMuZP3XhlTUDBArCPi5GabwZ6yVW4qeN1DJB6OTXH9yFekosw1GciPpnAPATVpA8oMNIbW4B wCPC+VotDgVgTf3jcTolDgKKi//2SYtdgI7sJCUmQST4TvRW6FyP44GqoPlCilmkXwrq6aFAd pcQ6C30dvUqKg8GR4cP2CwDTN4Hio9iyRwr4qoaUuZ3jQGLweTtzvGQ5DOBB+Pr9GSGFB0NTu HmbAWmh7/UIhcQB0fvLKpfp4ON9f6Xuvg2+fs+QSh0Gt24XEMMC3CLh8Z5CSRAT0ZmeTEq+Gj qIDhFRUi6DXVezrDgfXoQZf8i74efuVryEeXH2lvoYCEuoqziFJhMLpm8flkjilgKLeQiR94e 2QVSLuJ4rfBHw5+wWdQOF5/5wvT3AkdiNIa3+hFAWD1fDsTDslFYVDdmmXj6dB4aVuUuL5cHr wkSLP91eyXG1KiWdDd1UfuojoEjSF5xzJnCNi1qxIg8NsNDmtrNkSMTNKH2nleJ41chbWwEdu s1tvIOGK7ZfJ0G009HhLJQqmCV0AYz9ZFqcZZ7Bv321ieVOCI8nC8ZUolKZ1wGQ0CU7t4Ixcy g6zRbinIxpolU7L5DQKmuETWStvNkrqOZpH38r9mk7SQ22dwvNtR3c6qaFsdhsXEsQsF+dhsc GUZBsdN3Lza1FYiD+DZDKZRpXIOaxm5/++CwXRSOfP7BGnqMw252hql7AQISy06vI1cSEn+1e FpKLggbWb1he/rYo9uPGeeo430C9z6bK6CfkttiNXq96otT3l3Q0xesNgWNRmT3lWMeP8MP7Y jBWrYnPJ/lNOz/jVCeqdrUMV9TVj947zqDY82DBRxbkDniXsu/vm8XL34sZca1z5uk2pyc2Tz lwMHLuwsmHBx6lzf0X3lWXMa77wcPpK/XUdxZvYmeGkg2f/AA5fOq/0AwAA X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-8.tower-96.messagelabs.com!1521474444!100365932!1 X-Originating-IP: [207.46.163.84] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3835 invoked from network); 19 Mar 2018 15:47:24 -0000 Received: from mail-bl2nam02lp0084.outbound.protection.outlook.com (HELO NAM02-BL2-obe.outbound.protection.outlook.com) (207.46.163.84) by server-8.tower-96.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 19 Mar 2018 15:47:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6FrRkjC+PV4ONHpvfyJVKM1aP8RWU/kuTaRd4j2KNX8=; b=JS0kkNKuPPHOXR1GnZ9UD7YHUaGyE5Wuz+pv9Dpf4Anvv3iRlWRxI+NVkwbicsvDgF6QKi5mTI8W9W1bVsoP687XlHMmnfF5x8i4RM5Mce/8zwRPE/NLen9sdF3zWnMgpApYYnhNcChoiMMiRutE+54fSwBvYJzM+Kfd65RvYZE= Received: from MWHPR14MB1376.namprd14.prod.outlook.com (10.173.232.139) by MWHPR14MB1517.namprd14.prod.outlook.com (10.173.233.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Mon, 19 Mar 2018 15:47:23 +0000 Received: from MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::7929:3f48:4a4f:1e32]) by MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::7929:3f48:4a4f:1e32%18]) with mapi id 15.20.0588.016; Mon, 19 Mar 2018 15:47:22 +0000 From: Tim Hollebeek To: Martin Thomson , Sergio Garcia Murillo CC: RTCWeb IETF Thread-Topic: [rtcweb] Possible identity security vulnerability Thread-Index: AQHTv2Fbf2/O/UlBVk2jAz9KxqI00qPXTSyAgAAEY4CAAAAskIAAB1QAgAAKAQCAAAPsAIAAA8oAgAAB44CAAAGxAIAABPiAgAAJ4gCAABPCgIAAAX0AgAADVQCAAAycAIAADo0w Date: Mon, 19 Mar 2018 15:47:22 +0000 Message-ID: References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> <5d59eec9-62d6-94e4-517e-da6d0b9e3c41@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [31.133.148.144] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR14MB1517; 7:1Y9z7kgdVif2AUAJ4FaU4Cl4GovCmBqwgM6v3Pn/ysmjZEgXh/GSJwNecCzjXPN+LZJwFRoXegu97QMG6/Uq1y51PAXuMsA2b0nd6GFh8yiT0zQ9r4H0ntpK2O/DRYpEvAG1bBnTOftc9gbOYvyH8XsnD8jN9Agyiq82gML4uPi3EKQBn7w+ZtSjWtcyhVcPUjKyQ4MYYotGSFMnCQJOgAp3xAj1zBtnlkGzF60SmKr3iUsKXZoGBhRBuWRIAvTX x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: cf6e54ed-ca07-4389-15e9-08d58db0b4b7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:MWHPR14MB1517; x-ms-traffictypediagnostic: MWHPR14MB1517: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231221)(944501244)(52105095)(3002001)(6041310)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MWHPR14MB1517; BCL:0; PCL:0; RULEID:; SRVR:MWHPR14MB1517; x-forefront-prvs: 06167FAD59 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39380400002)(376002)(39860400002)(396003)(366004)(189003)(199004)(13464003)(52314003)(305945005)(97736004)(33656002)(7696005)(99936001)(59450400001)(5660300001)(6306002)(316002)(55016002)(7736002)(6436002)(229853002)(9686003)(2900100001)(76176011)(74316002)(2950100002)(105586002)(14454004)(26005)(66066001)(68736007)(8936002)(186003)(53936002)(478600001)(5250100002)(93886005)(2906002)(99286004)(53546011)(6506007)(4326008)(3846002)(102836004)(15650500001)(8676002)(86362001)(81156014)(3660700001)(6246003)(39060400002)(81166006)(966005)(110136005)(6116002)(106356001)(3280700002)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR14MB1517; H:MWHPR14MB1376.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ZJzsuA0X3PIW8FKQtKZF/Brbyj6npQZHrGco54QHOADsQN8TtscYsRdEPX0CuVanlRi3HL3pVROU3Yua5e1tpX9McHIh639bOhPOV5fLUXb0nomZpNpHqsh2s8xKdZDu+zah+fkBsSY2d5KxeH5FHzO8WtORqP/HCmqfE+qB4f61rGN3wEOT/57Ir5Unn4L1n5tdmTcIjNUZAlJ4DUNco9JcI+k/G6dJ2hrvSNpaT6lhCoYW0IcHKnHSKSNMKSBvcxUO3yyg0avydmD8IZ6S8aeXo8q3i1mE3Hy4Jl+plxr9EbR7R1qVUGZgYU4VTENhe17s2BPTrRTM0Tm2fACojA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0451_01D3BF99.8F1C89B0" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: cf6e54ed-ca07-4389-15e9-08d58db0b4b7 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2018 15:47:22.6263 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1517 Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 15:47:29 -0000 ------=_NextPart_000_0451_01D3BF99.8F1C89B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I was told over the weekend that the current spec required no validation = other than the expiration date. Is that right? It certainly appeared so from = the section I was shown. It made sense at the time, since it was argued these were = ephemeral certificates that were only used to encapsulate a (public key, = expiration date) pair, along with TLS security parameters. After hearing more discussion = (including Sergio's point that the certificate may be long lived), I'm not so sure that's = wise. I agree that if the lifetime of the certificates isn't truly ephemeral, = the requirements around certificate validation should probably be tightened up. If name = validation=20 were being done on the DTLS connection (my understanding was it wasn't), = that would=20 certainly help reduce the number of silly things you could do, perhaps = to the point=20 where the risk is low. Though I think it still would be wise simply to enforce the no-reuse = policy. It's simpler and easier to evaluate, instead of trying to rely on other = properties of the algorithm to guarantee the risk is low. I'm afraid that approach will = be fragile, and other vulnerabilities may be introduced in the future when those = properties of the algorithm change. Anyway, just some things to think about. -Tim > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Martin > Thomson > Sent: Monday, March 19, 2018 2:43 PM > To: Sergio Garcia Murillo > Cc: RTCWeb IETF > Subject: Re: [rtcweb] Possible identity security vulnerability >=20 > As a practical matter, if the browser were to use the same certificate = for > multiple origins, then it would create a massive privacy problem that = enables > linkability (aka user tracking). I couldn't find that written down, = but I thought > it was. If it isn't written down, then we should correct that. >=20 > On Mon, Mar 19, 2018 at 1:57 PM, Sergio Garcia Murillo > wrote: > > On 19/03/2018 14:45, westhawk wrote: > > > > On 19 Mar 2018, at 13:40, Martin Thomson > wrote: > > > > It's anything that *the site* initiates (not so much the browser). > > Certificates are origin-scoped. > > > > Are they? is the private key needed in the re-use of the assertion? > > (I haven=E2=80=99t looked at this for ages) > > If not the you could push the ASN1 of the public cert somewhere not > > scoped to the origin and have another site re-use it. (e.g. transfer > > it to an advert iframe with postmessage) > > > > > > After checking if further, that may not be clearly explicit on the > > webrtc w3c spec: > > > > For the purposes of this API, the [[Certificate]] slot contains > > unstructured binary data. No mechanism is provided for applications = to > > access the [[KeyingMaterial]] internal slot. Implementations MUST > > support applications storing and retrieving RTCCertificate objects > > from persistent storage. In implementations where an RTCCertificate > > might not directly hold private keying material (it might be stored = in > > a secure module), a reference to the private key can be held in the > > [[KeyingMaterial]] internal slot, allowing the private key to be = stored and > used. > > > > So it is not clear to me if certificates are origin-scoped or if the > > key materials could be exported outside of the browser. Worst case, > > certificate could be exported and identity assertion reused even by = a > different service. > > > > Best regards > > Sergio > > >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb ------=_NextPart_000_0451_01D3BF99.8F1C89B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgwMzE5MTU0NzE3WjAvBgkqhkiG9w0BCQQxIgQgn3KMwI7dC0Rb+QhT1daZPLgbt75u y8L+c+CSXAFxeMgwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBADtDMhxxaJjFkW0UONC7mZoG1DYXZ5k7wZX89aAj/ePJRn6J2lInDCVG634a1sjN9DWTFlYE ZZrY/sv9U37BEvHcawUoxAzcRkfzowYw63tRbX0PccM5SatzQPvI5ICCTf9RcmWfwBUHbLf0Y1i1 0z8JsPRYppE7SEj20cxgb/awiBfTLb+7xvGUoOIbOwcLw8edMjhfMeM9EaC07YA3mgHbsD1eyNXE Wcoyi6iOzLN7wAKiF9SK9weSTc0mqT6KNQEOW2la0nVNjG7NmJN/gzuM9X9tXkzpZhO3KcvpcbDn phjBlPQSgyXZboxvWXIjj6Os1V0sfiq1eJ8SoqHzC/YAAAAAAAA= ------=_NextPart_000_0451_01D3BF99.8F1C89B0-- From nobody Mon Mar 19 10:23:42 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3ED129BBF for ; Mon, 19 Mar 2018 10:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 rNCpm1ZHz2Re for ; Mon, 19 Mar 2018 10:23:38 -0700 (PDT) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (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 B38BE127333 for ; Mon, 19 Mar 2018 10:23:38 -0700 (PDT) Received: by mail-ot0-x22d.google.com with SMTP id l12-v6so18188675otj.7 for ; Mon, 19 Mar 2018 10:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/Tl7HLyudA4iAEv5/0QQUkE1keVuGCA9fT3MybYRz+M=; b=culj5FnSNOduPaE8/4e4OGSYAf5UhjF5YEQIEXjueCjL36cWMvS1X7MtzQZCAMHTl3 +rqjNA3SCx1X3leYYUK8pARyUAPnx5ln+0p4e70vnTZB+PaVeDBsdMNJh4vdrlIaewzR NdmdXylL3exaKjA0MEVsPMd4t2eRws5dmjP+nX65NXgxkl2eAJSsnwzhUnU066LVDOfQ oX1g+8Q61qYpE/7mubv5t22CUroMX+ZvcSyKYtz8cS7iLjv49KGSF3NrF01DWtfFDEm2 QCl6FXg+LlCNA7uClA4pO7nnuIvPBupjFeJZxnuliJI2zLaAt7w86RhdYzEPcyAFSqor ld7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/Tl7HLyudA4iAEv5/0QQUkE1keVuGCA9fT3MybYRz+M=; b=f/CqlME7B5LWx6WWo7p5CfkmXgVY9MDsLIplu0m4T7TQU2YhqtqI1iqypOY15kZm+i jeYnyKcxQvVIaxw/WWYAL1Mj3dHRArYvYzQii4R/+mjESawIN/kYCN0zry+dFj8aCpm+ 7af+JUYa3oLFONh5ibZAZzAVtQZkepe4wVAVBp2A2/Knr/ORsEGHC0YOyJMVCecAdeAm UGRM/dAxq8sNUzgUqkkqCigoHeNJ502vTJYaegcvHfz/Ycjjnhn4kMeNijlRJR5maHtT C83q3CcVAT0cjkcSCbG9N63WSK04qW990W8mgfo7/wrFtbJJY0Fn52ZdiN8GJ7YU3WkL 7lYQ== X-Gm-Message-State: AElRT7EaX8MgnRTKtdHPNQxCvK0gzQXpur9vuYTAay8iiZ7rz+lAMrsx o2aOWp8Hna5mNFLNBgl2+fRnQcZluiMS3CrMDlY= X-Google-Smtp-Source: AG47ELslL2kLIKeJgxcrIbYVQp6t/dZfquzb+N3gPA52fEuKL987fw6fwCxvHlI1EIRu/nM2mMHeIic+WlMGWNYPZIU= X-Received: by 2002:a9d:2963:: with SMTP id d90-v6mr7680729otb.396.1521480217810; Mon, 19 Mar 2018 10:23:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Mon, 19 Mar 2018 10:23:37 -0700 (PDT) In-Reply-To: <74c8e7ba-13f7-b92b-29b5-f4d43a6c9978@gmail.com> References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> <5d59eec9-62d6-94e4-517e-da6d0b9e3c41@gmail.com> <74c8e7ba-13f7-b92b-29b5-f4d43a6c9978@gmail.com> From: Martin Thomson Date: Mon, 19 Mar 2018 17:23:37 +0000 Message-ID: To: Sergio Garcia Murillo Cc: westhawk , RTCWeb IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 17:23:41 -0000 That was never the intent. The reason for marking this cloneable is to enable storage in indexedDB. We should close that option. There is no good reason to allow this usage. On Mon, Mar 19, 2018 at 3:03 PM, Sergio Garcia Murillo wrote: > Found it, they are not origin bounded: > > The RTCCertificate object can be stored and retrieved from persistent > storage by an application. When a user agent is required to obtain a > structured clone [HTML51] of an RTCCertificate object, it performs the > following steps > > And on HTML5 spec: > > Cloneable objects support being cloned across event loops. That is, they > support being cloned across Documentand Worker boundaries, including acro= ss > Documents of different origins. Not all objects are cloneable objectsand = not > all aspects of objects that are cloneable objects are necessarily preserv= ed > when cloned. > > So you can perfectly do the following: > > RTCPeerConnection.generateCertificate({ > name: 'RSASSA-PKCS1-v1_5', > hash: 'SHA-256', > modulusLength: 2048, > publicExponent: new Uint8Array([1, 0, 1]) > }).then(function(cert) { > windowInOderDomain.postMessage(cert,"*") > }); > > And the other window will able to reuse it. However, the certificate won'= t > be serialized in anyway that could be extracted from the browser. > > Best regards > Sergio > > > > On 19/03/2018 15:43, Martin Thomson wrote: > > As a practical matter, if the browser were to use the same certificate > for multiple origins, then it would create a massive privacy problem > that enables linkability (aka user tracking). I couldn't find that > written down, but I thought it was. If it isn't written down, then we > should correct that. > > On Mon, Mar 19, 2018 at 1:57 PM, Sergio Garcia Murillo > wrote: > > On 19/03/2018 14:45, westhawk wrote: > > On 19 Mar 2018, at 13:40, Martin Thomson wrote= : > > It's anything that *the site* initiates (not so much the browser). > Certificates are origin-scoped. > > Are they? is the private key needed in the re-use of the assertion? > (I haven=E2=80=99t looked at this for ages) > If not the you could push the ASN1 of the public cert somewhere not scope= d > to the > origin and have another site re-use it. (e.g. transfer it to an advert > iframe with postmessage) > > > After checking if further, that may not be clearly explicit on the webrtc > w3c spec: > > For the purposes of this API, the [[Certificate]] slot contains unstructu= red > binary data. No mechanism is provided for applications to access the > [[KeyingMaterial]] internal slot. Implementations MUST support applicatio= ns > storing and retrieving RTCCertificate objects from persistent storage. In > implementations where an RTCCertificate might not directly hold private > keying material (it might be stored in a secure module), a reference to t= he > private key can be held in the [[KeyingMaterial]] internal slot, allowing > the private key to be stored and used. > > So it is not clear to me if certificates are origin-scoped or if the key > materials could be exported outside of the browser. Worst case, certifica= te > could be exported and identity assertion reused even by a different servi= ce. > > Best regards > Sergio > > From nobody Mon Mar 19 10:32:00 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC20C127333 for ; Mon, 19 Mar 2018 10:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 ZXleAJ_IZfua for ; Mon, 19 Mar 2018 10:31:55 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.8]) (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 A1CE2126C25 for ; Mon, 19 Mar 2018 10:31:55 -0700 (PDT) Received: from [216.82.249.212] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-8.bemta-12.messagelabs.com id B1/99-19234-B04FFAA5; Mon, 19 Mar 2018 17:31:55 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTcRTH97t3j6t44zZfx6WBo6hmrhaFkpB BSC8jQzIwqa5120Z7yO4qpUAN8bU/tJhki1jiC03LUsoIK63oSY9lamXUSLM0MR9Rpkm7+02r f358fud7vuece3+HIuV9UgXFZVo5i4k1KKX+4mfqyqRo/4lLqStzmoNiu57MoNjGmQJZbP/MN XI9uem6451sU1XVJJFEpEr0pnRz5j6Jbqx9fcbVlMzegTxJDvq0vRj5UWJmhID2guPFyJ+SM2 UEXLvRg/DlA4Irp5pIIUvKrISutvuEwEGMFpw1Nd44yUTCRK1TKnAgsw6e5tbLcE48vO18SmK uQfB8dDnuthheD5QigWkmDeq6J6S42XsKpqa/ew1+zA44XdkkERgxIfDjUQOBm4XCmz6nl4EJ AveLx1LMwfDl44wvPw3OjXf44koY7rdLMEeAy2lDmFsIKG3wxaPhW1kZiXkb9Ew+kQgDAeNCk Fvd72umgq8PzvqKHoKJE4UyzGlgG20ksKGKhLzKOjEWwqG8ucRXqVAKzfc+eN1y5gDY62fHmy JgxBFbilSOf77O4fGQjBOBLb9d7PD+p/nw8EyfGCepoKxx0MdRUFMxRGKOg/Jf7VKH703sNrc M8xoYujeKziOqHi3lOcsRzhK9WqNOt+i1OquR1RuiNZpVaiPH86yWM7DpvHq/2XgFefYrWyRC rejrrd0dKIwilMG0+eSlVPm8dPOBLB3L6/ZaDhs4vgOFU5QS6HdjHm2+hdNymQf1Bs+SzspAB SiD6ARBpvkM1sjrtVh6hOKpltMD+SQ17f7iOXs+D3nOVnutjZSLTWYTpwilbwo2RrDpDpvmis 4uvwtFKAJpJBKJ5AEZnMWot/6vD6JQCikDabdQJUBvss71HvSMRXjGSqxuEMaysn8lRQ5KiSv qHA5f1JJ67M7OsYidU3mRtbt0op7hou4wxe+KsDXKXrfz89afK17GGLektGUpNLLxlIUiOtk6 fJm+6LpbktzX27Ai8cHaY3VtCvUpVRyX4LLvIpyvlowmhI25tS0LJDG3k0KClz2nkwODu0PIP UezmzZ+jOr0b9ywWX1h30+lmNexGhVp4dk/FkwnPvcDAAA= X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-8.tower-219.messagelabs.com!1521480713!184667438!1 X-Originating-IP: [207.46.163.80] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15616 invoked from network); 19 Mar 2018 17:31:54 -0000 Received: from mail-bl2nam02lp0080.outbound.protection.outlook.com (HELO NAM02-BL2-obe.outbound.protection.outlook.com) (207.46.163.80) by server-8.tower-219.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 19 Mar 2018 17:31:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4MR0/UJiHk2PbpSLC7ILF4H/8HNWotvznKN+YwBIm3I=; b=n5XA9h08KUKZMAsZEeYq3gb69XexWroN58cFodHG15oKKZ9y3XY0WcJS/tw6tIY/k/Upi13ev4NsaTrvr4U1+YnhxsQrW8HAIW7kdVfkAgN1RpZK9WX2jZyrK1EdH3yqgokvO0bKSwqeBeZ2cMdaJVk19a1+i7EI/SfFq+Wk+Kc= Received: from MWHPR14MB1376.namprd14.prod.outlook.com (10.173.232.139) by MWHPR14MB1454.namprd14.prod.outlook.com (10.173.233.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Mon, 19 Mar 2018 17:31:52 +0000 Received: from MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::7929:3f48:4a4f:1e32]) by MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::7929:3f48:4a4f:1e32%18]) with mapi id 15.20.0588.016; Mon, 19 Mar 2018 17:31:51 +0000 From: Tim Hollebeek To: Martin Thomson , Sergio Garcia Murillo CC: RTCWeb IETF Thread-Topic: [rtcweb] Possible identity security vulnerability Thread-Index: AQHTv2Fbf2/O/UlBVk2jAz9KxqI00qPXTSyAgAAEY4CAAAAskIAAB1QAgAAKAQCAAAPsAIAAA8oAgAAB44CAAAGxAIAABPiAgAAJ4gCAABPCgIAAAX0AgAADVQCAAAycAIAABdiAgAAnCYCAAAIy4A== Date: Mon, 19 Mar 2018 17:31:51 +0000 Message-ID: References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> <5d59eec9-62d6-94e4-517e-da6d0b9e3c41@gmail.com> <74c8e7ba-13f7-b92b-29b5-f4d43a6c9978@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [31.133.148.144] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR14MB1454; 7:xAcW06AYqFHaGuZOHgr7RP+6Ur5qjPlcejNdRwYRyHsuE59K3HlO1rToK9Ues9HBEK7veqLUCUz6PD3uUZv5S0NCShQC6Syb8NyIz5ofSKfvYh6xWe3K4ABp91Ef3ayqOoLbi/wt5gpk1LlaGTsp+mpKoWHpisiTXS1u3GF3e85u9yZ6amWAL18i6IPVdIo5SM4bDz8eu3sq577mphfHRKDjZ5JRWBSvm8IBmjpVacjj4p4xrPzGQdAYO7DMVeyW x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 9ead9813-13ca-4cd0-b9fd-08d58dbf4d65 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:MWHPR14MB1454; x-ms-traffictypediagnostic: MWHPR14MB1454: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231221)(944501300)(52105095)(3002001)(93006095)(93001095)(6041310)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:MWHPR14MB1454; BCL:0; PCL:0; RULEID:; SRVR:MWHPR14MB1454; x-forefront-prvs: 06167FAD59 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(39850400004)(366004)(39380400002)(199004)(13464003)(189003)(9686003)(2950100002)(25786009)(3846002)(76176011)(59450400001)(99286004)(86362001)(966005)(99936001)(7696005)(3660700001)(6306002)(110136005)(8676002)(2906002)(14454004)(106356001)(6436002)(81166006)(6246003)(2900100001)(81156014)(4326008)(105586002)(55016002)(6116002)(53936002)(305945005)(229853002)(8936002)(3280700002)(66066001)(5660300001)(68736007)(97736004)(33656002)(6506007)(478600001)(102836004)(53546011)(316002)(74316002)(26005)(93886005)(5250100002)(7736002)(15650500001)(39060400002)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR14MB1454; H:MWHPR14MB1376.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: TTH/+BCXm6xjhQEWKhAzG3iUgf4uLIH5HqxoqmWA7DgcA7AV5Z10phOJVVBB7Y6AD1E9Zae76L9zLohKfyLjTwoJ6JyLJoyL2nS4uNkRHJRnZG4JQMEOfwmHhcC+o+StaMC/Ga2pTT1urW/NfTVuFLQOib8/zChP9rBcDBK4XAlTrbqop5KqPzjHeuiNs1GW0VhIpLOl0NnxQTR6Dqo40f3JWPRcNOEcW8Cn+9lysw0r09uE/pAkgzm/B69yltKBXB/4Kk3JbTywNwTGd1uSQbNgeSTq+cAqHhQvSCBZ3tGmWbmmNXT69gIaBTT52MttdBJYXQBWeYZ3VPZ92A4iuA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_04B9_01D3BFA8.299BE590" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9ead9813-13ca-4cd0-b9fd-08d58dbf4d65 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2018 17:31:51.8169 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1454 Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 17:31:59 -0000 ------=_NextPart_000_04B9_01D3BFA8.299BE590 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I would agree, that would solve several of my concerns. -Tim > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Martin > Thomson > Sent: Monday, March 19, 2018 5:24 PM > To: Sergio Garcia Murillo > Cc: RTCWeb IETF > Subject: Re: [rtcweb] Possible identity security vulnerability >=20 > That was never the intent. The reason for marking this cloneable is = to enable > storage in indexedDB. We should close that option. There is no good = reason > to allow this usage. >=20 > On Mon, Mar 19, 2018 at 3:03 PM, Sergio Garcia Murillo > wrote: > > Found it, they are not origin bounded: > > > > The RTCCertificate object can be stored and retrieved from = persistent > > storage by an application. When a user agent is required to obtain a > > structured clone [HTML51] of an RTCCertificate object, it performs = the > > following steps > > > > And on HTML5 spec: > > > > Cloneable objects support being cloned across event loops. That is, > > they support being cloned across Documentand Worker boundaries, > > including across Documents of different origins. Not all objects are > > cloneable objectsand not all aspects of objects that are cloneable > > objects are necessarily preserved when cloned. > > > > So you can perfectly do the following: > > > > RTCPeerConnection.generateCertificate({ > > name: 'RSASSA-PKCS1-v1_5', > > hash: 'SHA-256', > > modulusLength: 2048, > > publicExponent: new Uint8Array([1, 0, 1]) > > }).then(function(cert) { > > windowInOderDomain.postMessage(cert,"*") > > }); > > > > And the other window will able to reuse it. However, the certificate > > won't be serialized in anyway that could be extracted from the = browser. > > > > Best regards > > Sergio > > > > > > > > On 19/03/2018 15:43, Martin Thomson wrote: > > > > As a practical matter, if the browser were to use the same = certificate > > for multiple origins, then it would create a massive privacy problem > > that enables linkability (aka user tracking). I couldn't find that > > written down, but I thought it was. If it isn't written down, then = we > > should correct that. > > > > On Mon, Mar 19, 2018 at 1:57 PM, Sergio Garcia Murillo > > wrote: > > > > On 19/03/2018 14:45, westhawk wrote: > > > > On 19 Mar 2018, at 13:40, Martin Thomson > wrote: > > > > It's anything that *the site* initiates (not so much the browser). > > Certificates are origin-scoped. > > > > Are they? is the private key needed in the re-use of the assertion? > > (I haven=E2=80=99t looked at this for ages) > > If not the you could push the ASN1 of the public cert somewhere not > > scoped to the origin and have another site re-use it. (e.g. transfer > > it to an advert iframe with postmessage) > > > > > > After checking if further, that may not be clearly explicit on the > > webrtc w3c spec: > > > > For the purposes of this API, the [[Certificate]] slot contains > > unstructured binary data. No mechanism is provided for applications = to > > access the [[KeyingMaterial]] internal slot. Implementations MUST > > support applications storing and retrieving RTCCertificate objects > > from persistent storage. In implementations where an RTCCertificate > > might not directly hold private keying material (it might be stored = in > > a secure module), a reference to the private key can be held in the > > [[KeyingMaterial]] internal slot, allowing the private key to be = stored and > used. > > > > So it is not clear to me if certificates are origin-scoped or if the > > key materials could be exported outside of the browser. Worst case, > > certificate could be exported and identity assertion reused even by = a > different service. > > > > Best regards > > Sergio > > > > >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb ------=_NextPart_000_04B9_01D3BFA8.299BE590 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgwMzE5MTczMTQ5WjAvBgkqhkiG9w0BCQQxIgQgNeYQD6gLGKwgbrKfHROIVkhFF8Ls JQuq+CDBRxqn8G4wgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAFp1l4H5V1wpTzhQusBN21hexBN8lvd0db+UGXB1BC++CxfvSCTvJh5aiYdPlpmmIyQtDA4B +E8basBhkFmTEf0uOPylXaaKFNJqQN5NkTPClD7HIIX1Mxg+mDcVaYiZHSR+/5Qw4zyfxYv4QrZz v5nZf3c7iVRpjDa4NxsS/p9+qpSo7reLSWScEYTLKOTnV9wTyP2D78I3dQdHSRUeBOg8pMGsaZUr JtTdOb1BSITK858TT34Gu1N5Gz38cONFqHpFQ9orsJuHowXkwOAAr0+CHFFaikL3sHH/b/BLu/bX 0I5fFB6SgKetA4WNYeHeaJaHkBeHwGACyMB72lq75nUAAAAAAAA= ------=_NextPart_000_04B9_01D3BFA8.299BE590-- From nobody Mon Mar 19 11:23:51 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FC112D87C for ; Mon, 19 Mar 2018 11:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 0QzXYH2yJ2_4 for ; Mon, 19 Mar 2018 11:23:47 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 B083E12D87A for ; Mon, 19 Mar 2018 11:23:46 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id h21so16922574wmd.1 for ; Mon, 19 Mar 2018 11:23:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=PcAAogLu5OOjDm2wmY+AfPNODS0uYvfGpFihQrShm90=; b=lcES7FXvMEZJLR3GOH4qe4KXNTAa2wrtiItLCUN1rO8wQFB1nPfWaaNGTOlCR5YTkM 1THt1+qhMCQemsu0v/gepkHR5cKjUz/AR3uGZ+vjyDHa0kgtk/ni7LsWSKrwNPi6Ejhs RzSDWqMZBfUhs8rz4jMAZn7GKfADbU1HXs+j+zkKozp95g+kDKjOEM2pHoBeyJ+Cm+EH 43zW+SA/7JBKw+2/q0Cwa7vx0Yt3CdQcNOHUxQ3aecpOlhOuFDtv8bzHbDM1PXP0+sc6 VgtGuC6kkGnrURNmIi+LOiL934XnO+L32O1Y+J6xzeDlFJktAHJlwYnkL+9naOSLNr1P 0uZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=PcAAogLu5OOjDm2wmY+AfPNODS0uYvfGpFihQrShm90=; b=Mm0/4wSiEeNXrbNudCfXC2oeDIkAj5udFfi3DmogcmR2HrfCNZLa0SfNXyNkGfxhYo lQHT1Iu8cV68lUXrpamSQ8O3K7lJ2Ehe3GSKUsVyDwpFIs1dZnIwLp44QRpMRlIEW5wX SwcyWu1yrIQgodXojuYVNYYgCqpmLU3RZyPCcF5mWOc+WqP+RIOoA1F2DcCXUnsJw6Zn YfIz0NVUUhWm0+l0Rmypw3oFRAES3AG3JZRUfSql/T7Hlxhoqbn3AwaMR7SAEHf74nRi xH+cS1P9VE2UFcKeCluDL/+G80zA1Q3+0h32ECZJUXdsvVdypv6x2VX4vEz3dc/ZT6/W +x4g== X-Gm-Message-State: AElRT7EoYw7Ejunc1f73539Jx6w4vcsSSe2tk+yt4XUojaRUHmOSFzeO F2JwPBsW9qwEIYIVi6z+/fu7svhx X-Google-Smtp-Source: AG47ELtTdX5abB+2sZ9D6MI1CA39Jk6u/YsKPyvmIfxVMQsO4UOwBT/eFMMxkCZkKuLKavMN5ub5Qw== X-Received: by 10.28.126.198 with SMTP id z189mr8708361wmc.135.1521483824866; Mon, 19 Mar 2018 11:23:44 -0700 (PDT) Received: from [192.168.0.11] (213.37.16.193.dyn.user.ono.com. [213.37.16.193]) by smtp.googlemail.com with ESMTPSA id k14sm780834wrc.62.2018.03.19.11.23.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 11:23:43 -0700 (PDT) To: Martin Thomson Cc: westhawk , RTCWeb IETF References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> <5d59eec9-62d6-94e4-517e-da6d0b9e3c41@gmail.com> <74c8e7ba-13f7-b92b-29b5-f4d43a6c9978@gmail.com> From: Sergio Garcia Murillo Message-ID: <7761eeec-4ae7-85bc-8d30-6889448807e4@gmail.com> Date: Mon, 19 Mar 2018 19:23:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 18:23:49 -0000 I can confirm that it works in firefox, you can check it with the following html:     Note that data: urls creates their own domain, so we are sending the generated certificate back and forth between domain without issues. Best regards Sergio On 19/03/2018 18:23, Martin Thomson wrote: > That was never the intent. The reason for marking this cloneable is > to enable storage in indexedDB. We should close that option. There > is no good reason to allow this usage. > > On Mon, Mar 19, 2018 at 3:03 PM, Sergio Garcia Murillo > wrote: >> Found it, they are not origin bounded: >> >> The RTCCertificate object can be stored and retrieved from persistent >> storage by an application. When a user agent is required to obtain a >> structured clone [HTML51] of an RTCCertificate object, it performs the >> following steps >> >> And on HTML5 spec: >> >> Cloneable objects support being cloned across event loops. That is, they >> support being cloned across Documentand Worker boundaries, including across >> Documents of different origins. Not all objects are cloneable objectsand not >> all aspects of objects that are cloneable objects are necessarily preserved >> when cloned. >> >> So you can perfectly do the following: >> >> RTCPeerConnection.generateCertificate({ >> name: 'RSASSA-PKCS1-v1_5', >> hash: 'SHA-256', >> modulusLength: 2048, >> publicExponent: new Uint8Array([1, 0, 1]) >> }).then(function(cert) { >> windowInOderDomain.postMessage(cert,"*") >> }); >> >> And the other window will able to reuse it. However, the certificate won't >> be serialized in anyway that could be extracted from the browser. >> >> Best regards >> Sergio >> >> >> >> On 19/03/2018 15:43, Martin Thomson wrote: >> >> As a practical matter, if the browser were to use the same certificate >> for multiple origins, then it would create a massive privacy problem >> that enables linkability (aka user tracking). I couldn't find that >> written down, but I thought it was. If it isn't written down, then we >> should correct that. >> >> On Mon, Mar 19, 2018 at 1:57 PM, Sergio Garcia Murillo >> wrote: >> >> On 19/03/2018 14:45, westhawk wrote: >> >> On 19 Mar 2018, at 13:40, Martin Thomson wrote: >> >> It's anything that *the site* initiates (not so much the browser). >> Certificates are origin-scoped. >> >> Are they? is the private key needed in the re-use of the assertion? >> (I haven’t looked at this for ages) >> If not the you could push the ASN1 of the public cert somewhere not scoped >> to the >> origin and have another site re-use it. (e.g. transfer it to an advert >> iframe with postmessage) >> >> >> After checking if further, that may not be clearly explicit on the webrtc >> w3c spec: >> >> For the purposes of this API, the [[Certificate]] slot contains unstructured >> binary data. No mechanism is provided for applications to access the >> [[KeyingMaterial]] internal slot. Implementations MUST support applications >> storing and retrieving RTCCertificate objects from persistent storage. In >> implementations where an RTCCertificate might not directly hold private >> keying material (it might be stored in a secure module), a reference to the >> private key can be held in the [[KeyingMaterial]] internal slot, allowing >> the private key to be stored and used. >> >> So it is not clear to me if certificates are origin-scoped or if the key >> materials could be exported outside of the browser. Worst case, certificate >> could be exported and identity assertion reused even by a different service. >> >> Best regards >> Sergio >> >> From nobody Mon Mar 19 13:13:14 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91CA312D93F for ; Mon, 19 Mar 2018 13:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 JlHDFxdS1-SE for ; Mon, 19 Mar 2018 13:13:10 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) (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 9F2391273E2 for ; Mon, 19 Mar 2018 13:13:08 -0700 (PDT) Received: (qmail 17135 invoked from network); 19 Mar 2018 20:13:07 -0000 X-APM-Authkey: 255286/0(159927/0) 1878 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 19 Mar 2018 20:13:07 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id EEA1F18A053B; Mon, 19 Mar 2018 20:13:06 +0000 (GMT) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0r93rfcBBkF3; Mon, 19 Mar 2018 20:13:06 +0000 (GMT) Received: from [192.67.4.84] (unknown [192.67.4.84]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id C117918A0401; Mon, 19 Mar 2018 20:13:06 +0000 (GMT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: westhawk In-Reply-To: Date: Mon, 19 Mar 2018 20:13:06 +0000 Cc: Sergio Garcia Murillo , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <48F10399-28DF-4998-9B40-3F341947F63C@westhawk.co.uk> References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> <5d59eec9-62d6-94e4-517e-da6d0b9e3c41@gmail.com> <74c8e7ba-13f7-b92b-29b5-f4d43a6c9978@gmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 20:13:12 -0000 Storage or cloning ? > On 19 Mar 2018, at 17:23, Martin Thomson = wrote: >=20 > That was never the intent. The reason for marking this cloneable is > to enable storage in indexedDB. We should close that option. There > is no good reason to allow this usage. >=20 > On Mon, Mar 19, 2018 at 3:03 PM, Sergio Garcia Murillo > wrote: >> Found it, they are not origin bounded: >>=20 >> The RTCCertificate object can be stored and retrieved from persistent >> storage by an application. When a user agent is required to obtain a >> structured clone [HTML51] of an RTCCertificate object, it performs = the >> following steps >>=20 >> And on HTML5 spec: >>=20 >> Cloneable objects support being cloned across event loops. That is, = they >> support being cloned across Documentand Worker boundaries, including = across >> Documents of different origins. Not all objects are cloneable = objectsand not >> all aspects of objects that are cloneable objects are necessarily = preserved >> when cloned. >>=20 >> So you can perfectly do the following: >>=20 >> RTCPeerConnection.generateCertificate({ >> name: 'RSASSA-PKCS1-v1_5', >> hash: 'SHA-256', >> modulusLength: 2048, >> publicExponent: new Uint8Array([1, 0, 1]) >> }).then(function(cert) { >> windowInOderDomain.postMessage(cert,"*") >> }); >>=20 >> And the other window will able to reuse it. However, the certificate = won't >> be serialized in anyway that could be extracted from the browser. >>=20 >> Best regards >> Sergio >>=20 >>=20 >>=20 >> On 19/03/2018 15:43, Martin Thomson wrote: >>=20 >> As a practical matter, if the browser were to use the same = certificate >> for multiple origins, then it would create a massive privacy problem >> that enables linkability (aka user tracking). I couldn't find that >> written down, but I thought it was. If it isn't written down, then = we >> should correct that. >>=20 >> On Mon, Mar 19, 2018 at 1:57 PM, Sergio Garcia Murillo >> wrote: >>=20 >> On 19/03/2018 14:45, westhawk wrote: >>=20 >> On 19 Mar 2018, at 13:40, Martin Thomson = wrote: >>=20 >> It's anything that *the site* initiates (not so much the browser). >> Certificates are origin-scoped. >>=20 >> Are they? is the private key needed in the re-use of the assertion? >> (I haven=E2=80=99t looked at this for ages) >> If not the you could push the ASN1 of the public cert somewhere not = scoped >> to the >> origin and have another site re-use it. (e.g. transfer it to an = advert >> iframe with postmessage) >>=20 >>=20 >> After checking if further, that may not be clearly explicit on the = webrtc >> w3c spec: >>=20 >> For the purposes of this API, the [[Certificate]] slot contains = unstructured >> binary data. No mechanism is provided for applications to access the >> [[KeyingMaterial]] internal slot. Implementations MUST support = applications >> storing and retrieving RTCCertificate objects from persistent = storage. In >> implementations where an RTCCertificate might not directly hold = private >> keying material (it might be stored in a secure module), a reference = to the >> private key can be held in the [[KeyingMaterial]] internal slot, = allowing >> the private key to be stored and used. >>=20 >> So it is not clear to me if certificates are origin-scoped or if the = key >> materials could be exported outside of the browser. Worst case, = certificate >> could be exported and identity assertion reused even by a different = service. >>=20 >> Best regards >> Sergio >>=20 >>=20 From nobody Mon Mar 19 15:43:48 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16BA9124BAC for ; Mon, 19 Mar 2018 15:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 xt1ozeXKJtvX for ; Mon, 19 Mar 2018 15:43:45 -0700 (PDT) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (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 B05981205F0 for ; Mon, 19 Mar 2018 15:43:44 -0700 (PDT) Received: (qmail 29266 invoked from network); 19 Mar 2018 22:43:42 -0000 X-APM-Authkey: 255286/0(159927/0) 1924 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 19 Mar 2018 22:43:42 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id C082E18A048A; Mon, 19 Mar 2018 22:43:42 +0000 (GMT) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qjY1VuPF3wLf; Mon, 19 Mar 2018 22:43:42 +0000 (GMT) Received: from [192.67.4.84] (unknown [192.67.4.84]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 96CA918A020A; Mon, 19 Mar 2018 22:43:42 +0000 (GMT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: westhawk In-Reply-To: <48F10399-28DF-4998-9B40-3F341947F63C@westhawk.co.uk> Date: Mon, 19 Mar 2018 22:43:41 +0000 Cc: RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <8E24CC04-0009-4789-8E10-EE3B66C077A5@westhawk.co.uk> References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> <5d59eec9-62d6-94e4-517e-da6d0b9e3c41@gmail.com> <74c8e7ba-13f7-b92b-29b5-f4d43a6c9978@gmail.com> <48F10399-28DF-4998-9B40-3F341947F63C@westhawk.co.uk> To: Martin Thomson X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 22:43:47 -0000 > On 19 Mar 2018, at 20:13, westhawk wrote: >=20 > Storage or cloning ? Because I have a _very_ good use for storage and re-use of certs. I have no desire to post message them around though. T. >=20 >> On 19 Mar 2018, at 17:23, Martin Thomson = wrote: >>=20 >> That was never the intent. The reason for marking this cloneable is >> to enable storage in indexedDB. We should close that option. There >> is no good reason to allow this usage. >>=20 >> On Mon, Mar 19, 2018 at 3:03 PM, Sergio Garcia Murillo >> wrote: >>> Found it, they are not origin bounded: >>>=20 >>> The RTCCertificate object can be stored and retrieved from = persistent >>> storage by an application. When a user agent is required to obtain a >>> structured clone [HTML51] of an RTCCertificate object, it performs = the >>> following steps >>>=20 >>> And on HTML5 spec: >>>=20 >>> Cloneable objects support being cloned across event loops. That is, = they >>> support being cloned across Documentand Worker boundaries, including = across >>> Documents of different origins. Not all objects are cloneable = objectsand not >>> all aspects of objects that are cloneable objects are necessarily = preserved >>> when cloned. >>>=20 >>> So you can perfectly do the following: >>>=20 >>> RTCPeerConnection.generateCertificate({ >>> name: 'RSASSA-PKCS1-v1_5', >>> hash: 'SHA-256', >>> modulusLength: 2048, >>> publicExponent: new Uint8Array([1, 0, 1]) >>> }).then(function(cert) { >>> windowInOderDomain.postMessage(cert,"*") >>> }); >>>=20 >>> And the other window will able to reuse it. However, the certificate = won't >>> be serialized in anyway that could be extracted from the browser. >>>=20 >>> Best regards >>> Sergio >>>=20 >>>=20 >>>=20 >>> On 19/03/2018 15:43, Martin Thomson wrote: >>>=20 >>> As a practical matter, if the browser were to use the same = certificate >>> for multiple origins, then it would create a massive privacy problem >>> that enables linkability (aka user tracking). I couldn't find that >>> written down, but I thought it was. If it isn't written down, then = we >>> should correct that. >>>=20 >>> On Mon, Mar 19, 2018 at 1:57 PM, Sergio Garcia Murillo >>> wrote: >>>=20 >>> On 19/03/2018 14:45, westhawk wrote: >>>=20 >>> On 19 Mar 2018, at 13:40, Martin Thomson = wrote: >>>=20 >>> It's anything that *the site* initiates (not so much the browser). >>> Certificates are origin-scoped. >>>=20 >>> Are they? is the private key needed in the re-use of the assertion? >>> (I haven=E2=80=99t looked at this for ages) >>> If not the you could push the ASN1 of the public cert somewhere not = scoped >>> to the >>> origin and have another site re-use it. (e.g. transfer it to an = advert >>> iframe with postmessage) >>>=20 >>>=20 >>> After checking if further, that may not be clearly explicit on the = webrtc >>> w3c spec: >>>=20 >>> For the purposes of this API, the [[Certificate]] slot contains = unstructured >>> binary data. No mechanism is provided for applications to access the >>> [[KeyingMaterial]] internal slot. Implementations MUST support = applications >>> storing and retrieving RTCCertificate objects from persistent = storage. In >>> implementations where an RTCCertificate might not directly hold = private >>> keying material (it might be stored in a secure module), a reference = to the >>> private key can be held in the [[KeyingMaterial]] internal slot, = allowing >>> the private key to be stored and used. >>>=20 >>> So it is not clear to me if certificates are origin-scoped or if the = key >>> materials could be exported outside of the browser. Worst case, = certificate >>> could be exported and identity assertion reused even by a different = service. >>>=20 >>> Best regards >>> Sergio >>>=20 >>>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Mar 20 01:14:09 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9F9124207 for ; Tue, 20 Mar 2018 01:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 3MuBHn9kBt-f for ; Tue, 20 Mar 2018 01:14:05 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 267F41201F2 for ; Tue, 20 Mar 2018 01:14:05 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id y27-v6so588974oix.10 for ; Tue, 20 Mar 2018 01:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mLz9us4rk3/xGiHOrv223gyNyF7F0Valw2gEhEWeG9I=; b=THh74JtoSWlfRNbGjLJeZOk9MQgivHdY4cKSrfkmS0JtHV8fwkS6riD+g2WU9dwaar dm/NMOHhNltFSW/b3aOI1xBNQU88wZjlJVSLBwNyFVvU3ksKnEo7tloZfNsRKZXr8VRd ECLq7hWKaEW6sPpwwnSUS/uS9/JKQu0XHEFpSvEGlFBjaLx0pcMjNUCQWhbZIUiROE4v Zgz9sPpQEIihI2UVgO23oZjyLgWkuavB/EQcf7SYpjXP5jpfB+g5yI1CG97Zwqd2r7Au 0za15ko+DjmzprIWv5BBcOV2jl63dFv/EjDqdRqfQt0VEw8P8CR9EUCAc6TcswR3qpEh 4k6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mLz9us4rk3/xGiHOrv223gyNyF7F0Valw2gEhEWeG9I=; b=OmPBR7vyRwOmits42d1EUcRNtPlFHJFNV0pax6+r7hqPNvrjFPiuFfQwc5CEwiNZ9m +wBa7Aadb2JxIAOgIgvmDR3z16FwHK4hWSz4co1tkRK6YKT7kdWznNKfAMwRQSalzLA2 Ypt1lol1Wn2kL8fK99KkwlcaN2lCCrWhZQNqQ6hE4gvkiC6IGmoYUtM3a0Eo2a4Z6jOt WvTifVA6c+Lszrtg7+KTWypaYWMWEzy7v8eXbLGe0ZL9pUhoP85KGn7DDqSiS4LuKWSP fH509jGD2letkaTw4OFqLmcmzjfgQmuI8UDt/pqwD8A+MDdbDp4hkrVKSL+mOWIbGmQz n1/Q== X-Gm-Message-State: AElRT7E17JNEmNRK29JigpE08WxZBFetGwwl1NtBNwieObe1LlmiHGaF mJ2kJjAK69bM2+OUNr06l+3JVFLhsWYWTz0eLNu3Wg== X-Google-Smtp-Source: AG47ELuZReIS+IXGlBcXqpiwX0329YT24V2BHAn5TW+jTn6gRM4OuITWC3OMKwyfcOvCOSU11FYJeU5KmuV/rWTJYYE= X-Received: by 10.202.198.141 with SMTP id w135mr9106614oif.215.1521533644192; Tue, 20 Mar 2018 01:14:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Tue, 20 Mar 2018 01:14:03 -0700 (PDT) In-Reply-To: <8E24CC04-0009-4789-8E10-EE3B66C077A5@westhawk.co.uk> References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> <5d59eec9-62d6-94e4-517e-da6d0b9e3c41@gmail.com> <74c8e7ba-13f7-b92b-29b5-f4d43a6c9978@gmail.com> <48F10399-28DF-4998-9B40-3F341947F63C@westhawk.co.uk> <8E24CC04-0009-4789-8E10-EE3B66C077A5@westhawk.co.uk> From: Martin Thomson Date: Tue, 20 Mar 2018 08:14:03 +0000 Message-ID: To: westhawk Cc: RTCWeb IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 08:14:07 -0000 I want to enable storage (that's the point of the feature), but not cross-origin transfers. On Mon, Mar 19, 2018 at 10:43 PM, westhawk wrote: > > >> On 19 Mar 2018, at 20:13, westhawk wrote: >> >> Storage or cloning ? > > Because I have a _very_ good use for storage and re-use of certs. > I have no desire to post message them around though. > > T. > >> >>> On 19 Mar 2018, at 17:23, Martin Thomson wro= te: >>> >>> That was never the intent. The reason for marking this cloneable is >>> to enable storage in indexedDB. We should close that option. There >>> is no good reason to allow this usage. >>> >>> On Mon, Mar 19, 2018 at 3:03 PM, Sergio Garcia Murillo >>> wrote: >>>> Found it, they are not origin bounded: >>>> >>>> The RTCCertificate object can be stored and retrieved from persistent >>>> storage by an application. When a user agent is required to obtain a >>>> structured clone [HTML51] of an RTCCertificate object, it performs the >>>> following steps >>>> >>>> And on HTML5 spec: >>>> >>>> Cloneable objects support being cloned across event loops. That is, th= ey >>>> support being cloned across Documentand Worker boundaries, including a= cross >>>> Documents of different origins. Not all objects are cloneable objectsa= nd not >>>> all aspects of objects that are cloneable objects are necessarily pres= erved >>>> when cloned. >>>> >>>> So you can perfectly do the following: >>>> >>>> RTCPeerConnection.generateCertificate({ >>>> name: 'RSASSA-PKCS1-v1_5', >>>> hash: 'SHA-256', >>>> modulusLength: 2048, >>>> publicExponent: new Uint8Array([1, 0, 1]) >>>> }).then(function(cert) { >>>> windowInOderDomain.postMessage(cert,"*") >>>> }); >>>> >>>> And the other window will able to reuse it. However, the certificate w= on't >>>> be serialized in anyway that could be extracted from the browser. >>>> >>>> Best regards >>>> Sergio >>>> >>>> >>>> >>>> On 19/03/2018 15:43, Martin Thomson wrote: >>>> >>>> As a practical matter, if the browser were to use the same certificate >>>> for multiple origins, then it would create a massive privacy problem >>>> that enables linkability (aka user tracking). I couldn't find that >>>> written down, but I thought it was. If it isn't written down, then we >>>> should correct that. >>>> >>>> On Mon, Mar 19, 2018 at 1:57 PM, Sergio Garcia Murillo >>>> wrote: >>>> >>>> On 19/03/2018 14:45, westhawk wrote: >>>> >>>> On 19 Mar 2018, at 13:40, Martin Thomson wr= ote: >>>> >>>> It's anything that *the site* initiates (not so much the browser). >>>> Certificates are origin-scoped. >>>> >>>> Are they? is the private key needed in the re-use of the assertion? >>>> (I haven=E2=80=99t looked at this for ages) >>>> If not the you could push the ASN1 of the public cert somewhere not sc= oped >>>> to the >>>> origin and have another site re-use it. (e.g. transfer it to an advert >>>> iframe with postmessage) >>>> >>>> >>>> After checking if further, that may not be clearly explicit on the web= rtc >>>> w3c spec: >>>> >>>> For the purposes of this API, the [[Certificate]] slot contains unstru= ctured >>>> binary data. No mechanism is provided for applications to access the >>>> [[KeyingMaterial]] internal slot. Implementations MUST support applica= tions >>>> storing and retrieving RTCCertificate objects from persistent storage.= In >>>> implementations where an RTCCertificate might not directly hold privat= e >>>> keying material (it might be stored in a secure module), a reference t= o the >>>> private key can be held in the [[KeyingMaterial]] internal slot, allow= ing >>>> the private key to be stored and used. >>>> >>>> So it is not clear to me if certificates are origin-scoped or if the k= ey >>>> materials could be exported outside of the browser. Worst case, certif= icate >>>> could be exported and identity assertion reused even by a different se= rvice. >>>> >>>> Best regards >>>> Sergio >>>> >>>> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Tue Mar 20 01:39:44 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148551205D3 for ; Tue, 20 Mar 2018 01:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 zvDSmpmxghoJ for ; Tue, 20 Mar 2018 01:39:39 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (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 AFD151200C5 for ; Tue, 20 Mar 2018 01:39:38 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id d10so751369wrf.3 for ; Tue, 20 Mar 2018 01:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=J513nDXK3rRMyZJ3nKC84y0OHJZUnmJRtPnA0fAn4yU=; b=uh2M6gKhRNhsHin1rXs4dlyzzPKs3M3N3dqSlDZKdASOOqZZy7o37ayzAEDkFjOmvi qMPtWFdRlOz3ZfR1cd4B9Etkrv87JW1FiPvo8GKFjXwOHmh08O/aY5QLXqEIHUTjg4v4 mUC/CpDBQ1KDMD/CwfsNPL2b/Fhc53bPocBUR74GwIISHq6VJMfK2jy3V3Ww09hbtSLc FKbcxWUcdH71CUfPzYA96e8hhdSMf5FR/ZOjgi5DZUF7NQRVVAtBU9NYkRE1wR5Dlvrz p64aD5V92PoKOnNQgoI3j8IkfVHUL2Po/2jE8fLEmQ7JJPj1xjf0PTfCfYpe2W25OSWP d5XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=J513nDXK3rRMyZJ3nKC84y0OHJZUnmJRtPnA0fAn4yU=; b=WYKk9RP5xkYsRSbNvjmyATVDW0dJJMMVwg9v3k7aHuCNNe2spXxNZDII/vP2PoXF7+ KntusKcy2Tf4E+0yEqkXLEsFVonIiEfi6yNY6RyE0F7A9JzF6kV+ctEJk7+u6tesIdYX 8utHKAWQpQP+aMWlIOOPWNllL39Z2j0xgU0Ej/O7l98LAyVMtrVmyDcOXEThmzcgvrSi OIiXcaotZHKdq3TFJlbf8+R8mgd0fsRujSvEKx6BpzQYLiR3CYYbI93dxbvDC+HljbmZ zmpwNkgh7iktwzlQJR/Xwb3Yz1DFsEHqnha1oDKFbvf060dkkUx8xlVMl0gyOZq/vqI+ yljQ== X-Gm-Message-State: AElRT7E0UqUDsfNMlmlmvmrOBgHsyKrzqPuxgpZ1fyKoSikuK4WctTTO I9DJtm5vIOXxvM5bRjLzPzF5Zakj X-Google-Smtp-Source: AG47ELumXxwwCAaM6VA9dCuY9Au0Vv1JhkMj0WWT/Ci1loFcMgB3Do/6SP4Md2xVxLZpquYZsfeVdA== X-Received: by 10.223.150.117 with SMTP id c50mr12181590wra.196.1521535176651; Tue, 20 Mar 2018 01:39:36 -0700 (PDT) Received: from [192.168.0.101] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id o88sm1089761wrb.44.2018.03.20.01.39.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Mar 2018 01:39:35 -0700 (PDT) To: rtcweb@ietf.org References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> <5d59eec9-62d6-94e4-517e-da6d0b9e3c41@gmail.com> <74c8e7ba-13f7-b92b-29b5-f4d43a6c9978@gmail.com> <48F10399-28DF-4998-9B40-3F341947F63C@westhawk.co.uk> <8E24CC04-0009-4789-8E10-EE3B66C077A5@westhawk.co.uk> From: Sergio Garcia Murillo Message-ID: <99324c1d-25a4-7506-6dab-1bb99ec27038@gmail.com> Date: Tue, 20 Mar 2018 09:39:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 08:39:41 -0000 Leaving the identity assertion implications, what would be the risks of sharing a certificate between different origins. I think you mentioned user tracking already, how that would be done? Best regards Sergio On 20/03/2018 9:14, Martin Thomson wrote: > I want to enable storage (that's the point of the feature), but not > cross-origin transfers. > > On Mon, Mar 19, 2018 at 10:43 PM, westhawk wrote: >> >>> On 19 Mar 2018, at 20:13, westhawk wrote: >>> >>> Storage or cloning ? >> Because I have a _very_ good use for storage and re-use of certs. >> I have no desire to post message them around though. >> >> T. >> >>>> On 19 Mar 2018, at 17:23, Martin Thomson wrote: >>>> >>>> That was never the intent. The reason for marking this cloneable is >>>> to enable storage in indexedDB. We should close that option. There >>>> is no good reason to allow this usage. >>>> >>>> On Mon, Mar 19, 2018 at 3:03 PM, Sergio Garcia Murillo >>>> wrote: >>>>> Found it, they are not origin bounded: >>>>> >>>>> The RTCCertificate object can be stored and retrieved from persistent >>>>> storage by an application. When a user agent is required to obtain a >>>>> structured clone [HTML51] of an RTCCertificate object, it performs the >>>>> following steps >>>>> >>>>> And on HTML5 spec: >>>>> >>>>> Cloneable objects support being cloned across event loops. That is, they >>>>> support being cloned across Documentand Worker boundaries, including across >>>>> Documents of different origins. Not all objects are cloneable objectsand not >>>>> all aspects of objects that are cloneable objects are necessarily preserved >>>>> when cloned. >>>>> >>>>> So you can perfectly do the following: >>>>> >>>>> RTCPeerConnection.generateCertificate({ >>>>> name: 'RSASSA-PKCS1-v1_5', >>>>> hash: 'SHA-256', >>>>> modulusLength: 2048, >>>>> publicExponent: new Uint8Array([1, 0, 1]) >>>>> }).then(function(cert) { >>>>> windowInOderDomain.postMessage(cert,"*") >>>>> }); >>>>> >>>>> And the other window will able to reuse it. However, the certificate won't >>>>> be serialized in anyway that could be extracted from the browser. >>>>> >>>>> Best regards >>>>> Sergio >>>>> >>>>> >>>>> >>>>> On 19/03/2018 15:43, Martin Thomson wrote: >>>>> >>>>> As a practical matter, if the browser were to use the same certificate >>>>> for multiple origins, then it would create a massive privacy problem >>>>> that enables linkability (aka user tracking). I couldn't find that >>>>> written down, but I thought it was. If it isn't written down, then we >>>>> should correct that. >>>>> >>>>> On Mon, Mar 19, 2018 at 1:57 PM, Sergio Garcia Murillo >>>>> wrote: >>>>> >>>>> On 19/03/2018 14:45, westhawk wrote: >>>>> >>>>> On 19 Mar 2018, at 13:40, Martin Thomson wrote: >>>>> >>>>> It's anything that *the site* initiates (not so much the browser). >>>>> Certificates are origin-scoped. >>>>> >>>>> Are they? is the private key needed in the re-use of the assertion? >>>>> (I haven’t looked at this for ages) >>>>> If not the you could push the ASN1 of the public cert somewhere not scoped >>>>> to the >>>>> origin and have another site re-use it. (e.g. transfer it to an advert >>>>> iframe with postmessage) >>>>> >>>>> >>>>> After checking if further, that may not be clearly explicit on the webrtc >>>>> w3c spec: >>>>> >>>>> For the purposes of this API, the [[Certificate]] slot contains unstructured >>>>> binary data. No mechanism is provided for applications to access the >>>>> [[KeyingMaterial]] internal slot. Implementations MUST support applications >>>>> storing and retrieving RTCCertificate objects from persistent storage. In >>>>> implementations where an RTCCertificate might not directly hold private >>>>> keying material (it might be stored in a secure module), a reference to the >>>>> private key can be held in the [[KeyingMaterial]] internal slot, allowing >>>>> the private key to be stored and used. >>>>> >>>>> So it is not clear to me if certificates are origin-scoped or if the key >>>>> materials could be exported outside of the browser. Worst case, certificate >>>>> could be exported and identity assertion reused even by a different service. >>>>> >>>>> Best regards >>>>> Sergio >>>>> >>>>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Mar 20 04:41:47 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3EDA12751F for ; Tue, 20 Mar 2018 04:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 c7gN2bze2v1b for ; Tue, 20 Mar 2018 04:41:40 -0700 (PDT) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (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 6B77812EAF9 for ; Tue, 20 Mar 2018 04:41:32 -0700 (PDT) Received: by mail-ot0-x22d.google.com with SMTP id 108-v6so1325042otv.3 for ; Tue, 20 Mar 2018 04:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FxOGZj2aniIfQdeVZ/WdeoiWpf5llAl04M6KFp05TpM=; b=Rk4eh79htwftDOBpt+XgTTY/aZ7V7aeBKjDDyaCNtQfEZJXHoFIYyvJJDYT1I+N1zE NN6QE9oFWSzkE+SLB8IeUqjwNIrFRROpO++scKTLURgZU4ywCLop4iORJSx2zmMw1Rju yB87u/SeGv7iio12+h1/Ka1tAeqWMUxHfgkw354nbwys3sLZEiio2T283EfLdK+Xpzvm MJ5zEGhr9Qk2YwVNALoGFS+IRyWOXE93LT8cmKALoy2T2+bM3peDe2sYS1bgguxl6ozM YV2XzeJaTvfk9aedx5pNGi1lu7dtvCJAwN+Czd2htTXr6k5Noqix8unoSJvHSDuzi5bE UkHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FxOGZj2aniIfQdeVZ/WdeoiWpf5llAl04M6KFp05TpM=; b=DyH6Riq/KOhEAg1xwmzQTUfVZXOkvRpo5OeAEAKq26jYJORAujrKbkh65bwWArqrya 83oWiJJf+kj7uP1g70A6Sd8aFAYY/2bduJ0Jdug9ZIQ9ZIxriR2YTw91UURAr32FII7s ozWQEO5FFQ/V6zfctM4bizU8UOqumHWlD9nXNTiZNcP5MLobnaKxaiDZccVXCq5fZJJ3 ZpB/Vey9mnUkc5Qa0OXD++jOB0+ox0eKc7D+Yi7SNB+TskKRpV7xM/mLz4EeAH3Kl2vM HOak71fo+k1E0WPOlzTFL6teLhGsS1COmjQyvCsfRbO/KHo2ntBORA38oOjQO+V+Sttk 4r/Q== X-Gm-Message-State: AElRT7H7wNf7ofTaOyTgDoZ/SLYdg3FFL9iPTCdad7dC7Am///Pyk13N imSQiGxCoe/nRDmR44Rbq+glTyCPR2oP3SdnxsUbNA== X-Google-Smtp-Source: AG47ELtYXfckzO117SH0Zy86FNjl0wrCfH4FxwJMNsClfR+PXPRVnqdNWOuwse9GSLvsbtOSPPOJ9/KCQaUFmE+ooM0= X-Received: by 2002:a9d:4e10:: with SMTP id p16-v6mr10638193otf.15.1521546091675; Tue, 20 Mar 2018 04:41:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Tue, 20 Mar 2018 04:41:31 -0700 (PDT) In-Reply-To: <99324c1d-25a4-7506-6dab-1bb99ec27038@gmail.com> References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> <5d59eec9-62d6-94e4-517e-da6d0b9e3c41@gmail.com> <74c8e7ba-13f7-b92b-29b5-f4d43a6c9978@gmail.com> <48F10399-28DF-4998-9B40-3F341947F63C@westhawk.co.uk> <8E24CC04-0009-4789-8E10-EE3B66C077A5@westhawk.co.uk> <99324c1d-25a4-7506-6dab-1bb99ec27038@gmail.com> From: Martin Thomson Date: Tue, 20 Mar 2018 11:41:31 +0000 Message-ID: To: Sergio Garcia Murillo Cc: RTCWeb IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 11:41:43 -0000 Cooperating origins can always ensure linkability, so it's not a real risk. The exposure here is that it enables portability of the identity assertion. On Tue, Mar 20, 2018 at 8:39 AM, Sergio Garcia Murillo wrote: > Leaving the identity assertion implications, what would be the risks of > sharing a certificate between different origins. > > I think you mentioned user tracking already, how that would be done? > > Best regards > Sergio > > > On 20/03/2018 9:14, Martin Thomson wrote: >> >> I want to enable storage (that's the point of the feature), but not >> cross-origin transfers. >> >> On Mon, Mar 19, 2018 at 10:43 PM, westhawk wrote: >>> >>> >>>> On 19 Mar 2018, at 20:13, westhawk wrote: >>>> >>>> Storage or cloning ? >>> >>> Because I have a _very_ good use for storage and re-use of certs. >>> I have no desire to post message them around though. >>> >>> T. >>> >>>>> On 19 Mar 2018, at 17:23, Martin Thomson >>>>> wrote: >>>>> >>>>> That was never the intent. The reason for marking this cloneable is >>>>> to enable storage in indexedDB. We should close that option. There >>>>> is no good reason to allow this usage. >>>>> >>>>> On Mon, Mar 19, 2018 at 3:03 PM, Sergio Garcia Murillo >>>>> wrote: >>>>>> >>>>>> Found it, they are not origin bounded: >>>>>> >>>>>> The RTCCertificate object can be stored and retrieved from persisten= t >>>>>> storage by an application. When a user agent is required to obtain a >>>>>> structured clone [HTML51] of an RTCCertificate object, it performs t= he >>>>>> following steps >>>>>> >>>>>> And on HTML5 spec: >>>>>> >>>>>> Cloneable objects support being cloned across event loops. That is, >>>>>> they >>>>>> support being cloned across Documentand Worker boundaries, including >>>>>> across >>>>>> Documents of different origins. Not all objects are cloneable >>>>>> objectsand not >>>>>> all aspects of objects that are cloneable objects are necessarily >>>>>> preserved >>>>>> when cloned. >>>>>> >>>>>> So you can perfectly do the following: >>>>>> >>>>>> RTCPeerConnection.generateCertificate({ >>>>>> name: 'RSASSA-PKCS1-v1_5', >>>>>> hash: 'SHA-256', >>>>>> modulusLength: 2048, >>>>>> publicExponent: new Uint8Array([1, 0, 1]) >>>>>> }).then(function(cert) { >>>>>> windowInOderDomain.postMessage(cert,"*") >>>>>> }); >>>>>> >>>>>> And the other window will able to reuse it. However, the certificate >>>>>> won't >>>>>> be serialized in anyway that could be extracted from the browser. >>>>>> >>>>>> Best regards >>>>>> Sergio >>>>>> >>>>>> >>>>>> >>>>>> On 19/03/2018 15:43, Martin Thomson wrote: >>>>>> >>>>>> As a practical matter, if the browser were to use the same certifica= te >>>>>> for multiple origins, then it would create a massive privacy problem >>>>>> that enables linkability (aka user tracking). I couldn't find that >>>>>> written down, but I thought it was. If it isn't written down, then = we >>>>>> should correct that. >>>>>> >>>>>> On Mon, Mar 19, 2018 at 1:57 PM, Sergio Garcia Murillo >>>>>> wrote: >>>>>> >>>>>> On 19/03/2018 14:45, westhawk wrote: >>>>>> >>>>>> On 19 Mar 2018, at 13:40, Martin Thomson >>>>>> wrote: >>>>>> >>>>>> It's anything that *the site* initiates (not so much the browser). >>>>>> Certificates are origin-scoped. >>>>>> >>>>>> Are they? is the private key needed in the re-use of the assertion? >>>>>> (I haven=E2=80=99t looked at this for ages) >>>>>> If not the you could push the ASN1 of the public cert somewhere not >>>>>> scoped >>>>>> to the >>>>>> origin and have another site re-use it. (e.g. transfer it to an adve= rt >>>>>> iframe with postmessage) >>>>>> >>>>>> >>>>>> After checking if further, that may not be clearly explicit on the >>>>>> webrtc >>>>>> w3c spec: >>>>>> >>>>>> For the purposes of this API, the [[Certificate]] slot contains >>>>>> unstructured >>>>>> binary data. No mechanism is provided for applications to access the >>>>>> [[KeyingMaterial]] internal slot. Implementations MUST support >>>>>> applications >>>>>> storing and retrieving RTCCertificate objects from persistent storag= e. >>>>>> In >>>>>> implementations where an RTCCertificate might not directly hold >>>>>> private >>>>>> keying material (it might be stored in a secure module), a reference >>>>>> to the >>>>>> private key can be held in the [[KeyingMaterial]] internal slot, >>>>>> allowing >>>>>> the private key to be stored and used. >>>>>> >>>>>> So it is not clear to me if certificates are origin-scoped or if the >>>>>> key >>>>>> materials could be exported outside of the browser. Worst case, >>>>>> certificate >>>>>> could be exported and identity assertion reused even by a different >>>>>> service. >>>>>> >>>>>> Best regards >>>>>> Sergio >>>>>> >>>>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Mar 20 04:45:43 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF9412EB08 for ; Tue, 20 Mar 2018 04:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 cpBCObTn9ywc for ; Tue, 20 Mar 2018 04:45:36 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 E1D9812EAE7 for ; Tue, 20 Mar 2018 04:45:30 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id h76so2792461wme.4 for ; Tue, 20 Mar 2018 04:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=7AFRFrg54S2X1IT9tGiWHVAd1dgh5XqL+azAQHuX4R4=; b=G2/PoNWvDsHS1Td17XeIb75zAPNNnGFM319BRq98tzufRgYZMIh5lU1v7rrQ5knEav WuG2V0hrI0N/st2EvVqPgScaSPoDC7iebUNJW4f43d5QtuYYTgrjg4k//ucgHAv1pEo1 nkdFW1nx3TJ0I12y4UCkODONGY82uZWIP6AcfCyqZUCs0KpRxIexisRb39k3dammjOBn yK8vt2JrbKDSrKu+3a3DKdxIQfFXrCnOX7NcyhqQ3Yv5+vaJfS3DUEH86+3JRBSrmxIf vaMwZGHB9NhqFhgHxSLAsOn1fFLvRpORhNdT7kTQieIGNsqPS+8fz2ITSx0g/vzUzkJc gSsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=7AFRFrg54S2X1IT9tGiWHVAd1dgh5XqL+azAQHuX4R4=; b=OmAVIVPeHxheSKQuEGXZ5j5OLAqnuErFZuOKL+lygh8PC2Q7KFFd/3ee2/QaONH/kj ogib2crEqtS9BLMatY2pQL4Bwrpa8fcTs2/x0HLpuIICbtt8bRaL7KlWrOiT7Lk+R6bc /dNThftSLBg+RrNwMPOKFdSwSas+E8EO5fxlO8a1zRcP3zKbaq+es4bXqjRJNwClLhcN Zc+wYSdxj1W0sCIiRUJ673NPA7S3UC4uwRFGh8iZbCwrMXWST8gjtrIKxyhs/qwYyVa2 81NPJJnIgDjr+tJzmXSqmYOPMWa3sgSfX+m5hy/7SV+7tFwCSX7IanMSFgt+iHhVRSuJ STUA== X-Gm-Message-State: AElRT7GSQJRcEk0NyrrAt7U9ViniLvfBIRG8jgL7i8k40hZXa32H4kEb SIn9XLzI1YrY6kvVA1s04fjW3Hhz X-Google-Smtp-Source: AG47ELsgm7VKwyau7Fbi/PQNldIeyvAU/JvK734v5jBRVtmGhKAPryswNOPlLDcZT1nxIJsOP+AgnQ== X-Received: by 10.80.195.66 with SMTP id q2mr9246395edb.254.1521546329154; Tue, 20 Mar 2018 04:45:29 -0700 (PDT) Received: from [192.168.0.101] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id b10sm1637940edj.73.2018.03.20.04.45.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Mar 2018 04:45:28 -0700 (PDT) To: Martin Thomson Cc: RTCWeb IETF References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> <5d59eec9-62d6-94e4-517e-da6d0b9e3c41@gmail.com> <74c8e7ba-13f7-b92b-29b5-f4d43a6c9978@gmail.com> <48F10399-28DF-4998-9B40-3F341947F63C@westhawk.co.uk> <8E24CC04-0009-4789-8E10-EE3B66C077A5@westhawk.co.uk> <99324c1d-25a4-7506-6dab-1bb99ec27038@gmail.com> From: Sergio Garcia Murillo Message-ID: Date: Tue, 20 Mar 2018 12:45:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 11:45:42 -0000 That was also my understanding. So, we could solve the the identity assertion identity by supporting the dtls external session id so it is unique per peerconnection and add it as nonce to the assertion generation (which seems like a nice to have anyway) and leave the postMessage support for certificates as it is (there could even be a valid usage for porting certificates across origins)? Would that work? Best regards Sergio On 20/03/2018 12:41, Martin Thomson wrote: > Cooperating origins can always ensure linkability, so it's not a real risk. > > The exposure here is that it enables portability of the identity assertion. > > On Tue, Mar 20, 2018 at 8:39 AM, Sergio Garcia Murillo > wrote: >> Leaving the identity assertion implications, what would be the risks of >> sharing a certificate between different origins. >> >> I think you mentioned user tracking already, how that would be done? >> >> Best regards >> Sergio >> >> >> On 20/03/2018 9:14, Martin Thomson wrote: >>> I want to enable storage (that's the point of the feature), but not >>> cross-origin transfers. >>> >>> On Mon, Mar 19, 2018 at 10:43 PM, westhawk wrote: >>>> >>>>> On 19 Mar 2018, at 20:13, westhawk wrote: >>>>> >>>>> Storage or cloning ? >>>> Because I have a _very_ good use for storage and re-use of certs. >>>> I have no desire to post message them around though. >>>> >>>> T. >>>> >>>>>> On 19 Mar 2018, at 17:23, Martin Thomson >>>>>> wrote: >>>>>> >>>>>> That was never the intent. The reason for marking this cloneable is >>>>>> to enable storage in indexedDB. We should close that option. There >>>>>> is no good reason to allow this usage. >>>>>> >>>>>> On Mon, Mar 19, 2018 at 3:03 PM, Sergio Garcia Murillo >>>>>> wrote: >>>>>>> Found it, they are not origin bounded: >>>>>>> >>>>>>> The RTCCertificate object can be stored and retrieved from persistent >>>>>>> storage by an application. When a user agent is required to obtain a >>>>>>> structured clone [HTML51] of an RTCCertificate object, it performs the >>>>>>> following steps >>>>>>> >>>>>>> And on HTML5 spec: >>>>>>> >>>>>>> Cloneable objects support being cloned across event loops. That is, >>>>>>> they >>>>>>> support being cloned across Documentand Worker boundaries, including >>>>>>> across >>>>>>> Documents of different origins. Not all objects are cloneable >>>>>>> objectsand not >>>>>>> all aspects of objects that are cloneable objects are necessarily >>>>>>> preserved >>>>>>> when cloned. >>>>>>> >>>>>>> So you can perfectly do the following: >>>>>>> >>>>>>> RTCPeerConnection.generateCertificate({ >>>>>>> name: 'RSASSA-PKCS1-v1_5', >>>>>>> hash: 'SHA-256', >>>>>>> modulusLength: 2048, >>>>>>> publicExponent: new Uint8Array([1, 0, 1]) >>>>>>> }).then(function(cert) { >>>>>>> windowInOderDomain.postMessage(cert,"*") >>>>>>> }); >>>>>>> >>>>>>> And the other window will able to reuse it. However, the certificate >>>>>>> won't >>>>>>> be serialized in anyway that could be extracted from the browser. >>>>>>> >>>>>>> Best regards >>>>>>> Sergio >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 19/03/2018 15:43, Martin Thomson wrote: >>>>>>> >>>>>>> As a practical matter, if the browser were to use the same certificate >>>>>>> for multiple origins, then it would create a massive privacy problem >>>>>>> that enables linkability (aka user tracking). I couldn't find that >>>>>>> written down, but I thought it was. If it isn't written down, then we >>>>>>> should correct that. >>>>>>> >>>>>>> On Mon, Mar 19, 2018 at 1:57 PM, Sergio Garcia Murillo >>>>>>> wrote: >>>>>>> >>>>>>> On 19/03/2018 14:45, westhawk wrote: >>>>>>> >>>>>>> On 19 Mar 2018, at 13:40, Martin Thomson >>>>>>> wrote: >>>>>>> >>>>>>> It's anything that *the site* initiates (not so much the browser). >>>>>>> Certificates are origin-scoped. >>>>>>> >>>>>>> Are they? is the private key needed in the re-use of the assertion? >>>>>>> (I haven’t looked at this for ages) >>>>>>> If not the you could push the ASN1 of the public cert somewhere not >>>>>>> scoped >>>>>>> to the >>>>>>> origin and have another site re-use it. (e.g. transfer it to an advert >>>>>>> iframe with postmessage) >>>>>>> >>>>>>> >>>>>>> After checking if further, that may not be clearly explicit on the >>>>>>> webrtc >>>>>>> w3c spec: >>>>>>> >>>>>>> For the purposes of this API, the [[Certificate]] slot contains >>>>>>> unstructured >>>>>>> binary data. No mechanism is provided for applications to access the >>>>>>> [[KeyingMaterial]] internal slot. Implementations MUST support >>>>>>> applications >>>>>>> storing and retrieving RTCCertificate objects from persistent storage. >>>>>>> In >>>>>>> implementations where an RTCCertificate might not directly hold >>>>>>> private >>>>>>> keying material (it might be stored in a secure module), a reference >>>>>>> to the >>>>>>> private key can be held in the [[KeyingMaterial]] internal slot, >>>>>>> allowing >>>>>>> the private key to be stored and used. >>>>>>> >>>>>>> So it is not clear to me if certificates are origin-scoped or if the >>>>>>> key >>>>>>> materials could be exported outside of the browser. Worst case, >>>>>>> certificate >>>>>>> could be exported and identity assertion reused even by a different >>>>>>> service. >>>>>>> >>>>>>> Best regards >>>>>>> Sergio >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Mar 20 04:46:37 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A64126DED for ; Tue, 20 Mar 2018 04:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 3PBAD2Ew6Dg1 for ; Tue, 20 Mar 2018 04:46:34 -0700 (PDT) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (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 80E92126DC2 for ; Tue, 20 Mar 2018 04:46:34 -0700 (PDT) Received: by mail-ot0-x236.google.com with SMTP id y11-v6so1342975otg.0 for ; Tue, 20 Mar 2018 04:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=n9586TTwsZlbSuq3lCV/LpWfDCGtA9KNJKgQC+20tHs=; b=i1I91rFOFge2mp+/kMt5Be9j8yvWpywhqqKyIiCq2q89QlBjAWXjpK5H74mn9BpEIo 8cS6HQ/bxIMz9aW4b+l+FDhnwcxl5n5zb7l1rU6WCYaFKvupooN27Fxk08H0g28Jrt+S VY3dsLPlWYJ2dfpG78E4o4gX0r1acFuECbHaZ53s7Ep1ZvVMCp23NC2Tv7nfwqCpV9v5 GtGwmQ9aLYo1hCj2/mBIXHneVbD2UyV/jDC89TFmaINu9PVgZqWkuw5Uz6Io92oF8Xig lE6Q0SpvKA9eWOnqoutBTiIp/EKUWdttIW2a711wa9E88Fe3t4aiIQnq7ErMzVVZXp9K wfeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=n9586TTwsZlbSuq3lCV/LpWfDCGtA9KNJKgQC+20tHs=; b=KGvz4/aLhZ0s4tVK0F+R+Epq1ctDpofW29i8Ias87PrphEeVhObLbz5/NuEGOGLMj0 j63iqKAga23wgKWJJVADL9ZOEkZqrev7b/ORfMIS0i3s/KFFe2OblBlWJRAIidoCy8bK n3DKEaSudcIDx3NnhO+gaV69+URslEwTaVFwMoKvQyothS5x6uh9iwIYtIb7XCGGkBzK cj5pn9XB66SKyl4DFmv5oxxmqUXQdSBhVI2SL4N0MxM0cwN0ZGSKW6aNyAiO8tToNqJb S3RJQoHk1X0VeDeqLDP1Senm9hxSiexf3LOoM94lU2vtMHF5Be4MOluZH5yyA81hZxuv LEaw== X-Gm-Message-State: AElRT7GUB9+uHoI6AAFciAsGbEaNuzPeBF9kdlSLyivkbMEBpZhUY9S7 Zg5vlWbJo/5ZYQVpNRElZDRIVd+vdoUmNKYkQNc= X-Google-Smtp-Source: AG47ELuVw7vHJgOhBbHIoODYcRrzcWzPRW/C3acUX9Z0LyOy65jeTZUdRilRJuhPi56dRvA21IRE1NChP5qctN8T+eg= X-Received: by 2002:a9d:4e10:: with SMTP id p16-v6mr10649323otf.15.1521546393805; Tue, 20 Mar 2018 04:46:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Tue, 20 Mar 2018 04:46:33 -0700 (PDT) In-Reply-To: References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> <5d59eec9-62d6-94e4-517e-da6d0b9e3c41@gmail.com> <74c8e7ba-13f7-b92b-29b5-f4d43a6c9978@gmail.com> <48F10399-28DF-4998-9B40-3F341947F63C@westhawk.co.uk> <8E24CC04-0009-4789-8E10-EE3B66C077A5@westhawk.co.uk> <99324c1d-25a4-7506-6dab-1bb99ec27038@gmail.com> From: Martin Thomson Date: Tue, 20 Mar 2018 11:46:33 +0000 Message-ID: To: Sergio Garcia Murillo Cc: RTCWeb IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 11:46:37 -0000 Others have expressed the fact that this portability - within an origin - is a feature, not a bug. We should discuss more. On Tue, Mar 20, 2018 at 11:45 AM, Sergio Garcia Murillo wrote: > That was also my understanding. > > So, we could solve the the identity assertion identity by supporting the > dtls external session id so it is unique per peerconnection and add it as > nonce to the assertion generation (which seems like a nice to have anyway= ) > and leave the postMessage support for certificates as it is (there could > even be a valid usage for porting certificates across origins)? > > Would that work? > > Best regards > Sergio > > > On 20/03/2018 12:41, Martin Thomson wrote: >> >> Cooperating origins can always ensure linkability, so it's not a real >> risk. >> >> The exposure here is that it enables portability of the identity >> assertion. >> >> On Tue, Mar 20, 2018 at 8:39 AM, Sergio Garcia Murillo >> wrote: >>> >>> Leaving the identity assertion implications, what would be the risks of >>> sharing a certificate between different origins. >>> >>> I think you mentioned user tracking already, how that would be done? >>> >>> Best regards >>> Sergio >>> >>> >>> On 20/03/2018 9:14, Martin Thomson wrote: >>>> >>>> I want to enable storage (that's the point of the feature), but not >>>> cross-origin transfers. >>>> >>>> On Mon, Mar 19, 2018 at 10:43 PM, westhawk wrote: >>>>> >>>>> >>>>>> On 19 Mar 2018, at 20:13, westhawk wrote: >>>>>> >>>>>> Storage or cloning ? >>>>> >>>>> Because I have a _very_ good use for storage and re-use of certs. >>>>> I have no desire to post message them around though. >>>>> >>>>> T. >>>>> >>>>>>> On 19 Mar 2018, at 17:23, Martin Thomson >>>>>>> wrote: >>>>>>> >>>>>>> That was never the intent. The reason for marking this cloneable i= s >>>>>>> to enable storage in indexedDB. We should close that option. Ther= e >>>>>>> is no good reason to allow this usage. >>>>>>> >>>>>>> On Mon, Mar 19, 2018 at 3:03 PM, Sergio Garcia Murillo >>>>>>> wrote: >>>>>>>> >>>>>>>> Found it, they are not origin bounded: >>>>>>>> >>>>>>>> The RTCCertificate object can be stored and retrieved from >>>>>>>> persistent >>>>>>>> storage by an application. When a user agent is required to obtain= a >>>>>>>> structured clone [HTML51] of an RTCCertificate object, it performs >>>>>>>> the >>>>>>>> following steps >>>>>>>> >>>>>>>> And on HTML5 spec: >>>>>>>> >>>>>>>> Cloneable objects support being cloned across event loops. That is= , >>>>>>>> they >>>>>>>> support being cloned across Documentand Worker boundaries, includi= ng >>>>>>>> across >>>>>>>> Documents of different origins. Not all objects are cloneable >>>>>>>> objectsand not >>>>>>>> all aspects of objects that are cloneable objects are necessarily >>>>>>>> preserved >>>>>>>> when cloned. >>>>>>>> >>>>>>>> So you can perfectly do the following: >>>>>>>> >>>>>>>> RTCPeerConnection.generateCertificate({ >>>>>>>> name: 'RSASSA-PKCS1-v1_5', >>>>>>>> hash: 'SHA-256', >>>>>>>> modulusLength: 2048, >>>>>>>> publicExponent: new Uint8Array([1, 0, 1]) >>>>>>>> }).then(function(cert) { >>>>>>>> windowInOderDomain.postMessage(cert,"*") >>>>>>>> }); >>>>>>>> >>>>>>>> And the other window will able to reuse it. However, the certifica= te >>>>>>>> won't >>>>>>>> be serialized in anyway that could be extracted from the browser. >>>>>>>> >>>>>>>> Best regards >>>>>>>> Sergio >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 19/03/2018 15:43, Martin Thomson wrote: >>>>>>>> >>>>>>>> As a practical matter, if the browser were to use the same >>>>>>>> certificate >>>>>>>> for multiple origins, then it would create a massive privacy probl= em >>>>>>>> that enables linkability (aka user tracking). I couldn't find tha= t >>>>>>>> written down, but I thought it was. If it isn't written down, the= n >>>>>>>> we >>>>>>>> should correct that. >>>>>>>> >>>>>>>> On Mon, Mar 19, 2018 at 1:57 PM, Sergio Garcia Murillo >>>>>>>> wrote: >>>>>>>> >>>>>>>> On 19/03/2018 14:45, westhawk wrote: >>>>>>>> >>>>>>>> On 19 Mar 2018, at 13:40, Martin Thomson >>>>>>>> wrote: >>>>>>>> >>>>>>>> It's anything that *the site* initiates (not so much the browser). >>>>>>>> Certificates are origin-scoped. >>>>>>>> >>>>>>>> Are they? is the private key needed in the re-use of the assertion= ? >>>>>>>> (I haven=E2=80=99t looked at this for ages) >>>>>>>> If not the you could push the ASN1 of the public cert somewhere no= t >>>>>>>> scoped >>>>>>>> to the >>>>>>>> origin and have another site re-use it. (e.g. transfer it to an >>>>>>>> advert >>>>>>>> iframe with postmessage) >>>>>>>> >>>>>>>> >>>>>>>> After checking if further, that may not be clearly explicit on the >>>>>>>> webrtc >>>>>>>> w3c spec: >>>>>>>> >>>>>>>> For the purposes of this API, the [[Certificate]] slot contains >>>>>>>> unstructured >>>>>>>> binary data. No mechanism is provided for applications to access t= he >>>>>>>> [[KeyingMaterial]] internal slot. Implementations MUST support >>>>>>>> applications >>>>>>>> storing and retrieving RTCCertificate objects from persistent >>>>>>>> storage. >>>>>>>> In >>>>>>>> implementations where an RTCCertificate might not directly hold >>>>>>>> private >>>>>>>> keying material (it might be stored in a secure module), a referen= ce >>>>>>>> to the >>>>>>>> private key can be held in the [[KeyingMaterial]] internal slot, >>>>>>>> allowing >>>>>>>> the private key to be stored and used. >>>>>>>> >>>>>>>> So it is not clear to me if certificates are origin-scoped or if t= he >>>>>>>> key >>>>>>>> materials could be exported outside of the browser. Worst case, >>>>>>>> certificate >>>>>>>> could be exported and identity assertion reused even by a differen= t >>>>>>>> service. >>>>>>>> >>>>>>>> Best regards >>>>>>>> Sergio >>>>>>>> >>>>>>>> >>>>>> _______________________________________________ >>>>>> rtcweb mailing list >>>>>> rtcweb@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb > > > From nobody Tue Mar 20 07:16:26 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E907D12704A for ; Tue, 20 Mar 2018 07:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 jr8p4PVIWikk for ; Tue, 20 Mar 2018 07:16:21 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 556521200FC for ; Tue, 20 Mar 2018 07:16:21 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id f19so3808370wmc.0 for ; Tue, 20 Mar 2018 07:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=FYymypwmAG77UDYdD/lxPDv5QSgeZFioWpMlIcOUquA=; b=KuKAz/GnwvmYml6pQTvD6IZg4f/Q9xEHWy62IvcfVciS3dRHwcEvrVJ1wZAXxmVxmt lMnsmJxk8OKrm1K2x80VZUZeudD6W8yhl9JtAhJyykBXQCPpK2tgQuaMHcg2dgRqtR4/ YDmgJXjZmab+2e93gCxuXy/dkhVKIe6xABdIEQNH+NG1QoOd08kDMDQ05Qrw2GhwC1Xl cwOgtPvtr7gkyta8ec7LNf8i5fFE0CxfMhZuYCmZGWFuCN6/RBH8A0RVMqYC9kA3058R eO1gJiTno1+wym4pesgnx2MisGWtC5LqL3XnivW+jWpGAMaAao+6nGSsavcAwWTVC7oq 0S4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=FYymypwmAG77UDYdD/lxPDv5QSgeZFioWpMlIcOUquA=; b=NWfMHtfIUpqqbFnyxLmkUNTann2+uB/nSzADCAAf7tTW7VZ3HHOQIJqu15IYkcgV8m 80zybD67O/OGHJWatQxR/A/iC4oZ8qIaePNCzkbwlIWsqzVMuZvCRHKnvQhNwK4SgMxR ETO4vAHDgeeV3xBqgTza72idh31BBlWX9qt1K/siRdfxTSrQpvfHSvH99HseNSGB4O+c sWpbjRk07feoRl24cfLoYy0FLTmwfwX9Y0BwbbH+PHNcWbzDQWVm9XodM4UIT0AzQHcM VtcGfSmVx9YinS9puOfn6TmSc66K2oZqdJTaR81cfkn9O9Sm08nM0QNH7Qrh63CZUumG WsCA== X-Gm-Message-State: AElRT7HZb//9tp5Zb47CaIcwL2yJ+lxNFxWszPWv/ErXD2AaLFGA83zb 6ohomlGWLproaw/4x7qoiqswFnuI X-Google-Smtp-Source: AG47ELshjJxBvEFTU/GfvWCg6F1Sibn/cYoMAVE+uxXpNozJhy/2asZeAhMqsjn4mG2URJNhroF9wg== X-Received: by 10.80.136.89 with SMTP id c25mr5120222edc.211.1521555379448; Tue, 20 Mar 2018 07:16:19 -0700 (PDT) Received: from [192.168.0.101] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id j42sm578780eda.67.2018.03.20.07.16.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Mar 2018 07:16:18 -0700 (PDT) To: Martin Thomson Cc: RTCWeb IETF References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> <5d59eec9-62d6-94e4-517e-da6d0b9e3c41@gmail.com> <74c8e7ba-13f7-b92b-29b5-f4d43a6c9978@gmail.com> <48F10399-28DF-4998-9B40-3F341947F63C@westhawk.co.uk> <8E24CC04-0009-4789-8E10-EE3B66C077A5@westhawk.co.uk> <99324c1d-25a4-7506-6dab-1bb99ec27038@gmail.com> From: Sergio Garcia Murillo Message-ID: Date: Tue, 20 Mar 2018 15:16:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 14:16:24 -0000 Sure. Would be interesting to know what are the arguments in favor of identity assertion reusability and portability (even within the same domain) vs requesting a new assertion each time. Best regards Sergio On 20/03/2018 12:46, Martin Thomson wrote: > Others have expressed the fact that this portability - within an > origin - is a feature, not a bug. We should discuss more. > > On Tue, Mar 20, 2018 at 11:45 AM, Sergio Garcia Murillo > wrote: >> That was also my understanding. >> >> So, we could solve the the identity assertion identity by supporting the >> dtls external session id so it is unique per peerconnection and add it as >> nonce to the assertion generation (which seems like a nice to have anyway) >> and leave the postMessage support for certificates as it is (there could >> even be a valid usage for porting certificates across origins)? >> >> Would that work? >> >> Best regards >> Sergio >> >> >> On 20/03/2018 12:41, Martin Thomson wrote: >>> Cooperating origins can always ensure linkability, so it's not a real >>> risk. >>> >>> The exposure here is that it enables portability of the identity >>> assertion. >>> >>> On Tue, Mar 20, 2018 at 8:39 AM, Sergio Garcia Murillo >>> wrote: >>>> Leaving the identity assertion implications, what would be the risks of >>>> sharing a certificate between different origins. >>>> >>>> I think you mentioned user tracking already, how that would be done? >>>> >>>> Best regards >>>> Sergio >>>> >>>> >>>> On 20/03/2018 9:14, Martin Thomson wrote: >>>>> I want to enable storage (that's the point of the feature), but not >>>>> cross-origin transfers. >>>>> >>>>> On Mon, Mar 19, 2018 at 10:43 PM, westhawk wrote: >>>>>> >>>>>>> On 19 Mar 2018, at 20:13, westhawk wrote: >>>>>>> >>>>>>> Storage or cloning ? >>>>>> Because I have a _very_ good use for storage and re-use of certs. >>>>>> I have no desire to post message them around though. >>>>>> >>>>>> T. >>>>>> >>>>>>>> On 19 Mar 2018, at 17:23, Martin Thomson >>>>>>>> wrote: >>>>>>>> >>>>>>>> That was never the intent. The reason for marking this cloneable is >>>>>>>> to enable storage in indexedDB. We should close that option. There >>>>>>>> is no good reason to allow this usage. >>>>>>>> >>>>>>>> On Mon, Mar 19, 2018 at 3:03 PM, Sergio Garcia Murillo >>>>>>>> wrote: >>>>>>>>> Found it, they are not origin bounded: >>>>>>>>> >>>>>>>>> The RTCCertificate object can be stored and retrieved from >>>>>>>>> persistent >>>>>>>>> storage by an application. When a user agent is required to obtain a >>>>>>>>> structured clone [HTML51] of an RTCCertificate object, it performs >>>>>>>>> the >>>>>>>>> following steps >>>>>>>>> >>>>>>>>> And on HTML5 spec: >>>>>>>>> >>>>>>>>> Cloneable objects support being cloned across event loops. That is, >>>>>>>>> they >>>>>>>>> support being cloned across Documentand Worker boundaries, including >>>>>>>>> across >>>>>>>>> Documents of different origins. Not all objects are cloneable >>>>>>>>> objectsand not >>>>>>>>> all aspects of objects that are cloneable objects are necessarily >>>>>>>>> preserved >>>>>>>>> when cloned. >>>>>>>>> >>>>>>>>> So you can perfectly do the following: >>>>>>>>> >>>>>>>>> RTCPeerConnection.generateCertificate({ >>>>>>>>> name: 'RSASSA-PKCS1-v1_5', >>>>>>>>> hash: 'SHA-256', >>>>>>>>> modulusLength: 2048, >>>>>>>>> publicExponent: new Uint8Array([1, 0, 1]) >>>>>>>>> }).then(function(cert) { >>>>>>>>> windowInOderDomain.postMessage(cert,"*") >>>>>>>>> }); >>>>>>>>> >>>>>>>>> And the other window will able to reuse it. However, the certificate >>>>>>>>> won't >>>>>>>>> be serialized in anyway that could be extracted from the browser. >>>>>>>>> >>>>>>>>> Best regards >>>>>>>>> Sergio >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 19/03/2018 15:43, Martin Thomson wrote: >>>>>>>>> >>>>>>>>> As a practical matter, if the browser were to use the same >>>>>>>>> certificate >>>>>>>>> for multiple origins, then it would create a massive privacy problem >>>>>>>>> that enables linkability (aka user tracking). I couldn't find that >>>>>>>>> written down, but I thought it was. If it isn't written down, then >>>>>>>>> we >>>>>>>>> should correct that. >>>>>>>>> >>>>>>>>> On Mon, Mar 19, 2018 at 1:57 PM, Sergio Garcia Murillo >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On 19/03/2018 14:45, westhawk wrote: >>>>>>>>> >>>>>>>>> On 19 Mar 2018, at 13:40, Martin Thomson >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> It's anything that *the site* initiates (not so much the browser). >>>>>>>>> Certificates are origin-scoped. >>>>>>>>> >>>>>>>>> Are they? is the private key needed in the re-use of the assertion? >>>>>>>>> (I haven’t looked at this for ages) >>>>>>>>> If not the you could push the ASN1 of the public cert somewhere not >>>>>>>>> scoped >>>>>>>>> to the >>>>>>>>> origin and have another site re-use it. (e.g. transfer it to an >>>>>>>>> advert >>>>>>>>> iframe with postmessage) >>>>>>>>> >>>>>>>>> >>>>>>>>> After checking if further, that may not be clearly explicit on the >>>>>>>>> webrtc >>>>>>>>> w3c spec: >>>>>>>>> >>>>>>>>> For the purposes of this API, the [[Certificate]] slot contains >>>>>>>>> unstructured >>>>>>>>> binary data. No mechanism is provided for applications to access the >>>>>>>>> [[KeyingMaterial]] internal slot. Implementations MUST support >>>>>>>>> applications >>>>>>>>> storing and retrieving RTCCertificate objects from persistent >>>>>>>>> storage. >>>>>>>>> In >>>>>>>>> implementations where an RTCCertificate might not directly hold >>>>>>>>> private >>>>>>>>> keying material (it might be stored in a secure module), a reference >>>>>>>>> to the >>>>>>>>> private key can be held in the [[KeyingMaterial]] internal slot, >>>>>>>>> allowing >>>>>>>>> the private key to be stored and used. >>>>>>>>> >>>>>>>>> So it is not clear to me if certificates are origin-scoped or if the >>>>>>>>> key >>>>>>>>> materials could be exported outside of the browser. Worst case, >>>>>>>>> certificate >>>>>>>>> could be exported and identity assertion reused even by a different >>>>>>>>> service. >>>>>>>>> >>>>>>>>> Best regards >>>>>>>>> Sergio >>>>>>>>> >>>>>>>>> >>>>>>> _______________________________________________ >>>>>>> rtcweb mailing list >>>>>>> rtcweb@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> From nobody Tue Mar 20 07:55:27 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EDD12EAE1 for ; Tue, 20 Mar 2018 07:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 yEB3cBmvdI5y for ; Tue, 20 Mar 2018 07:55:11 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.9]) (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 9F8E612D872 for ; Tue, 20 Mar 2018 07:55:11 -0700 (PDT) Received: from [216.82.251.38] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-9.bemta-12.messagelabs.com id 64/38-32635-FC021BA5; Tue, 20 Mar 2018 14:55:11 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTURzHO/febVdxdZyav0zL1ttSMqyMMgM h7I/oQUGIUNe8bcu7TXZXGvTQFC0fEaSpK1uCPViNXJRZJKE9TZMUEdEcStpDG6Vpltno3t31 un8cPr/z/f4e59xDk6q38hCazTSzJgPDqeW+VFf4HRzZGu5IWtFrVcd2trhRrN2dr4gddN8lN 5KJ9yy9isTq6u/ENiJJpjOkGDP3yrQO1zdZek9G5omRHEUWusAVIF+awp8IcDWMkmKgwucIcJ 4cQFLQh6Dy3ZSiAPnQcrwCOuufESIHYg0Uf3R69kk8D8auWuUiB+AN0JptU0ieeOjpaPVUDcT dCF62tHmSKbwQrr/JQSIrcTLYX32USd0mFGCfqBcCmvbBceB0rhU9CM+EiRc3CKlZMHQPWD0M OBD625rlEgfBhzdumeRPhsovjd59NbgGS2QSh0G7tdBzMsC3CchtzvcKkfC5tJSUeAtMut1eU zuCpq63XlME1Ix2KyROg4LRC15OhsIROyElVJNw/WKfVwiFsqIySuKTcuiZmi+yCqdCiU0cT0 z4QUDn5U75GRRh+ed4FkEjsRVB8bMcwuK5J39oqhigJFMElNqHvLwMrlQNkxKvg/LJBrnF+1N KCvsVEq+C4Scj6BKibWgxz5oOsabImKgUk06jNesZHRcZHb0ySs/yPKNhOSaFj9pn1N9Cwgub Jnx1yFaV0Ihm0YQ6SHlqsiZJNT3FmHpYy/DaPaaDHMs3olCaVoPy0VxHksrfxGrYzP06Tnimv 2Wg/dSBykpRVvLpjJ7XaSTpBYqnO8re5ZH0VP8HYe16PyysdSVXC0kVZTAa2JBgZaOYhsU07U HDn6K/n387CgsJUCJhTJVfOmvS68z/60MomEbqAGWRWMVPZzD/6T0kjEUIY6VV1IhjmZm/Ukg Wyqu/63M5t3ykaIfTv21B/7XjtT9impbv335iV8KpJQ+qjsaE3c/ZfOT05k3d+eFRtiB+NTNj N6LOOyt9nz+fxz2e+Jnx9FhddhmXMDS2qWfnnKU7x2uJvOqn3MPxs8ZFcVsPuDpe1S9zrGVvN tQOrs+zdN0mMhqOpq75lNubSr2e+jpbTfFaJjqCNPHMLzeolDb5AwAA X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-2.tower-163.messagelabs.com!1521557710!154746924!1 X-Originating-IP: [216.32.181.16] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 90164 invoked from network); 20 Mar 2018 14:55:10 -0000 Received: from mail-co1nam03lp0016.outbound.protection.outlook.com (HELO NAM03-CO1-obe.outbound.protection.outlook.com) (216.32.181.16) by server-2.tower-163.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 20 Mar 2018 14:55:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3DG8eQqCeFyMeVxH+y5k6PZJSXSbkYGUAWJI0YmdyoI=; b=h0CbM9q0NFAgkbqeztBL4TFgh+WxwVk6+ALRu7NYqZv5ZwpbrhepUhLM2DfOGDKUpy1I4kkz9/0eaqJt1XXtbv/r9I3iIFMrhi7529mucFJaiMQfQI4m+5yaFMm2pCReHZQeWXn/6aaPxZ7HCTHEGAruCrCS0oV0BSZeE0dOemw= Received: from MWHPR14MB1376.namprd14.prod.outlook.com (10.173.232.139) by MWHPR14MB1789.namprd14.prod.outlook.com (10.171.147.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Tue, 20 Mar 2018 14:55:08 +0000 Received: from MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::7929:3f48:4a4f:1e32]) by MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::7929:3f48:4a4f:1e32%18]) with mapi id 15.20.0588.017; Tue, 20 Mar 2018 14:55:08 +0000 From: Tim Hollebeek To: Sergio Garcia Murillo , Martin Thomson CC: RTCWeb IETF Thread-Topic: [rtcweb] Possible identity security vulnerability Thread-Index: AQHTv2Fbf2/O/UlBVk2jAz9KxqI00qPXTSyAgAAEY4CAAAAskIAAB1QAgAAKAQCAAAPsAIAAA8oAgAAB44CAAAGxAIAABPiAgAAJ4gCAABPCgIAAAX0AgAADVQCAAAycAIAABdiAgAAnCYCAAC9aAIAAKhOAgACfW4CAAAclgIAAMtOAgAABGYCAAABPgIAAKdWAgAAJblA= Date: Tue, 20 Mar 2018 14:55:08 +0000 Message-ID: References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> <5d59eec9-62d6-94e4-517e-da6d0b9e3c41@gmail.com> <74c8e7ba-13f7-b92b-29b5-f4d43a6c9978@gmail.com> <48F10399-28DF-4998-9B40-3F341947F63C@westhawk.co.uk> <8E24CC04-0009-4789-8E10-EE3B66C077A5@westhawk.co.uk> <99324c1d-25a4-7506-6dab-1bb99ec27038@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [31.133.148.144] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR14MB1789; 7:iZQ1lNHVln3pf1nn4w2M4Pi3+sBpr+35GBbEuRzNoet/f+y7cR1uV/LLApeySq9zQ7bNFzsn9TPef3d0oBlMUFQztiTEWo+lHrauoFUyO2DVpz/8eGhfwTFCJpBihUk6EMCyc92MhluiqZUKxLglemtf5en38+p17UjCtoRH7bklXlLUpNCrEfNCKKEE8c59zhgyQo0N344Btibbpw5XqLOwZ7kw8cS9La/ZIL6ZNmT12qVtJ7hOC4d8xBnwJBsC x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: d0c2179f-1960-416e-ae33-08d58e7292c8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:MWHPR14MB1789; x-ms-traffictypediagnostic: MWHPR14MB1789: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231221)(944501312)(52105095)(6041310)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:MWHPR14MB1789; BCL:0; PCL:0; RULEID:; SRVR:MWHPR14MB1789; x-forefront-prvs: 061725F016 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(396003)(376002)(346002)(366004)(189003)(13464003)(199004)(7696005)(966005)(59450400001)(39060400002)(106356001)(4326008)(26005)(76176011)(2900100001)(105586002)(14454004)(5660300001)(99286004)(2906002)(86362001)(316002)(3280700002)(66066001)(478600001)(25786009)(110136005)(7736002)(6116002)(3846002)(33656002)(5250100002)(305945005)(74316002)(8936002)(2950100002)(229853002)(15650500001)(53546011)(68736007)(6306002)(53936002)(6436002)(102836004)(97736004)(186003)(3660700001)(81166006)(93886005)(55016002)(9686003)(6506007)(81156014)(99936001)(6246003)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR14MB1789; H:MWHPR14MB1376.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: CxCj1KiWJsTdJYOiCrePkjHhkOuju2WapW8H7+ahhse1nIBFVMEqLKEsG11R0ioKri1Ho4n8SlyTqaVr8dakYlzc4mop5qUI1+LobfcyO4Cybr2wxc6ZAmHyozD1j1DwFZzTIYbbGwgSmNL+ly8TtrorJCRuWgP8drTE7wTiy0AiGVC2xGr9/PTauwRKMLtQW75HnF49GZwG02IPkYxWX00D18hwjR9/bLAsIu5Rg7ehi1Wt4vUpylkBl0Xp8HRDW1d8YcM6p8K6gJwD3BP4i0nPP2YSmnNGlJuJGFF3UVW07MzXrTVBmVWMYIexFu1aYCmoN1hC3mcM/lB569WF8w== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_05CA_01D3C05B.6EB26BA0" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: d0c2179f-1960-416e-ae33-08d58e7292c8 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2018 14:55:08.2053 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1789 Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 14:55:25 -0000 ------=_NextPart_000_05CA_01D3C05B.6EB26BA0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yeah, I'm not getting why people are so strongly in favor of maintaining = the ability to re-use identity assertions, given that there doesn't seem to = be a=20 practical use case and it adds complexity and risk. Generate/Verify = should come in 1-1 pairs. It's simpler to analyze that way. If the original design assumption was no identity assertion re-use (it = seems=20 it wasn't even contemplated before the replay attack was suggested), = enforce=20 it technically. It isn't that hard to do. Also, if a small hackathon surfaces an previously unknown replay = scenario like this one, it's worth doing a bit of extra analysis to try to find any = other gremlins that might be lurking in the identity mechanism. -Tim > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sergio = Garcia > Murillo > Sent: Tuesday, March 20, 2018 2:16 PM > To: Martin Thomson > Cc: RTCWeb IETF > Subject: Re: [rtcweb] Possible identity security vulnerability >=20 > Sure. >=20 > Would be interesting to know what are the arguments in favor of = identity > assertion reusability and portability (even within the same domain) vs > requesting a new assertion each time. >=20 > Best regards > Sergio >=20 > On 20/03/2018 12:46, Martin Thomson wrote: > > Others have expressed the fact that this portability - within an > > origin - is a feature, not a bug. We should discuss more. > > > > On Tue, Mar 20, 2018 at 11:45 AM, Sergio Garcia Murillo > > wrote: > >> That was also my understanding. > >> > >> So, we could solve the the identity assertion identity by = supporting > >> the dtls external session id so it is unique per peerconnection and > >> add it as nonce to the assertion generation (which seems like a = nice > >> to have anyway) and leave the postMessage support for certificates = as > >> it is (there could even be a valid usage for porting certificates = across > origins)? > >> > >> Would that work? > >> > >> Best regards > >> Sergio > >> > >> > >> On 20/03/2018 12:41, Martin Thomson wrote: > >>> Cooperating origins can always ensure linkability, so it's not a > >>> real risk. > >>> > >>> The exposure here is that it enables portability of the identity > >>> assertion. > >>> > >>> On Tue, Mar 20, 2018 at 8:39 AM, Sergio Garcia Murillo > >>> wrote: > >>>> Leaving the identity assertion implications, what would be the > >>>> risks of sharing a certificate between different origins. > >>>> > >>>> I think you mentioned user tracking already, how that would be = done? > >>>> > >>>> Best regards > >>>> Sergio > >>>> > >>>> > >>>> On 20/03/2018 9:14, Martin Thomson wrote: > >>>>> I want to enable storage (that's the point of the feature), but > >>>>> not cross-origin transfers. > >>>>> > >>>>> On Mon, Mar 19, 2018 at 10:43 PM, westhawk > wrote: > >>>>>> > >>>>>>> On 19 Mar 2018, at 20:13, westhawk wrote: > >>>>>>> > >>>>>>> Storage or cloning ? > >>>>>> Because I have a _very_ good use for storage and re-use of = certs. > >>>>>> I have no desire to post message them around though. > >>>>>> > >>>>>> T. > >>>>>> > >>>>>>>> On 19 Mar 2018, at 17:23, Martin Thomson > >>>>>>>> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>> That was never the intent. The reason for marking this > >>>>>>>> cloneable is to enable storage in indexedDB. We should close > >>>>>>>> that option. There is no good reason to allow this usage. > >>>>>>>> > >>>>>>>> On Mon, Mar 19, 2018 at 3:03 PM, Sergio Garcia Murillo > >>>>>>>> wrote: > >>>>>>>>> Found it, they are not origin bounded: > >>>>>>>>> > >>>>>>>>> The RTCCertificate object can be stored and retrieved from > >>>>>>>>> persistent storage by an application. When a user agent is > >>>>>>>>> required to obtain a structured clone [HTML51] of an > >>>>>>>>> RTCCertificate object, it performs the following steps > >>>>>>>>> > >>>>>>>>> And on HTML5 spec: > >>>>>>>>> > >>>>>>>>> Cloneable objects support being cloned across event loops. > >>>>>>>>> That is, they support being cloned across Documentand Worker > >>>>>>>>> boundaries, including across Documents of different origins. > >>>>>>>>> Not all objects are cloneable objectsand not all aspects of > >>>>>>>>> objects that are cloneable objects are necessarily preserved > >>>>>>>>> when cloned. > >>>>>>>>> > >>>>>>>>> So you can perfectly do the following: > >>>>>>>>> > >>>>>>>>> RTCPeerConnection.generateCertificate({ > >>>>>>>>> name: 'RSASSA-PKCS1-v1_5', > >>>>>>>>> hash: 'SHA-256', > >>>>>>>>> modulusLength: 2048, > >>>>>>>>> publicExponent: new Uint8Array([1, 0, 1]) > >>>>>>>>> }).then(function(cert) { > >>>>>>>>> windowInOderDomain.postMessage(cert,"*") > >>>>>>>>> }); > >>>>>>>>> > >>>>>>>>> And the other window will able to reuse it. However, the > >>>>>>>>> certificate won't be serialized in anyway that could be > >>>>>>>>> extracted from the browser. > >>>>>>>>> > >>>>>>>>> Best regards > >>>>>>>>> Sergio > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 19/03/2018 15:43, Martin Thomson wrote: > >>>>>>>>> > >>>>>>>>> As a practical matter, if the browser were to use the same > >>>>>>>>> certificate for multiple origins, then it would create a > >>>>>>>>> massive privacy problem that enables linkability (aka user > >>>>>>>>> tracking). I couldn't find that written down, but I thought > >>>>>>>>> it was. If it isn't written down, then we should correct > >>>>>>>>> that. > >>>>>>>>> > >>>>>>>>> On Mon, Mar 19, 2018 at 1:57 PM, Sergio Garcia Murillo > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> On 19/03/2018 14:45, westhawk wrote: > >>>>>>>>> > >>>>>>>>> On 19 Mar 2018, at 13:40, Martin Thomson > >>>>>>>>> > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> It's anything that *the site* initiates (not so much the = browser). > >>>>>>>>> Certificates are origin-scoped. > >>>>>>>>> > >>>>>>>>> Are they? is the private key needed in the re-use of the = assertion? > >>>>>>>>> (I haven=E2=80=99t looked at this for ages) If not the you = could push > >>>>>>>>> the ASN1 of the public cert somewhere not scoped to the = origin > >>>>>>>>> and have another site re-use it. (e.g. transfer it to an > >>>>>>>>> advert iframe with postmessage) > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> After checking if further, that may not be clearly explicit = on > >>>>>>>>> the webrtc w3c spec: > >>>>>>>>> > >>>>>>>>> For the purposes of this API, the [[Certificate]] slot > >>>>>>>>> contains unstructured binary data. No mechanism is provided > >>>>>>>>> for applications to access the [[KeyingMaterial]] internal > >>>>>>>>> slot. Implementations MUST support applications storing and > >>>>>>>>> retrieving RTCCertificate objects from persistent storage. > >>>>>>>>> In > >>>>>>>>> implementations where an RTCCertificate might not directly > >>>>>>>>> hold private keying material (it might be stored in a secure > >>>>>>>>> module), a reference to the private key can be held in the > >>>>>>>>> [[KeyingMaterial]] internal slot, allowing the private key = to > >>>>>>>>> be stored and used. > >>>>>>>>> > >>>>>>>>> So it is not clear to me if certificates are origin-scoped = or > >>>>>>>>> if the key materials could be exported outside of the = browser. > >>>>>>>>> Worst case, certificate could be exported and identity > >>>>>>>>> assertion reused even by a different service. > >>>>>>>>> > >>>>>>>>> Best regards > >>>>>>>>> Sergio > >>>>>>>>> > >>>>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> rtcweb mailing list > >>>>>>> rtcweb@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb > >>>>> _______________________________________________ > >>>>> rtcweb mailing list > >>>>> rtcweb@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/rtcweb > >>>> > >>>> > >>>> _______________________________________________ > >>>> rtcweb mailing list > >>>> rtcweb@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/rtcweb > >> > >> >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb ------=_NextPart_000_05CA_01D3C05B.6EB26BA0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgwMzIwMTQ1NTA1WjAvBgkqhkiG9w0BCQQxIgQgK4qUcXMrNdvvusiC9HmyThUPiojk /Bm/nxC9v/ZapBYwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAL3B4KNDCjHTUASJcZoMxt2LSP0HtetU1N2cUSVcAakFdy99OEC8JzgGJLSt1OTRaaWXv9DC HMPw8YUEasFUYFljSR+qQbmztJ9zPXdTe6TnQvFxK4qkk5zo9SVrOzGurFWWAh+0DtUFpG6dWSXJ 3rhwFJ+32UEQJLECxLWLdQTD8HuVlpM0B7C7Q2puzcSHgJESs0N5JaCJawEz6Z/UQ7GIoYGL6c6P 58RmeJdllGUmGN8mB5OWw8x/Wd928SLUlt5C0SAf/FGwj/a7m8lK93zydctBjeaoQDYwoPFSs5yP E1LPIY10oql6eEFAZqhTAHl2BeOY3W80XGLQcg4dBVcAAAAAAAA= ------=_NextPart_000_05CA_01D3C05B.6EB26BA0-- From nobody Tue Mar 20 08:02:59 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0238126D74 for ; Tue, 20 Mar 2018 08:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 I0PvrdGSjIkA for ; Tue, 20 Mar 2018 08:02:55 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.13]) (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 70DBE1200B9 for ; Tue, 20 Mar 2018 08:02:55 -0700 (PDT) Received: from [216.82.251.38] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-13.bemta-12.messagelabs.com id C5/55-26056-F9221BA5; Tue, 20 Mar 2018 15:02:55 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTe0hTURzHd+69227ljevU9msYtQuRVDMXPYT oDSFRUVEQS8qr3tytbdruqkVBg2yVRvXHcm2V07TQ0NBaLx9lo4iUXiJl0kPNzFxW9iB7EO3u 3l7/HD7nfL/ne37nxzkkrvmu0pGc08HZbayFUQ0n2scFg4ZiptaUUl8yOrX65171PJRWXv4VW 45MSt6WmevMUJpvdw5geYO8s2yoRO1C/qwCNJwk6HcYVIYfY+JEQxdhcOzHR0KadCKo6KhRF6 BhpIpOgYeNtzCR42k99JSWI5Hj6Enw40tnhMnIegoUv02XLMnQ5i2L2gl6PPg81SqRKToder+ 6opGIHgVfmquiHpzWQkdPIMpAx0PXgxaVxAnw+sVPpcQMDLz0yDwGWgOFSKwT6CAGvuYiQhIM 8P7IEVzipXCqt142tSIIlRXJwkT40HtI5k0QbryglngtnBu6gSQux+HaFTk0EbwHvIQUdFoJw brBqElDZ4PnTEglXScdTnwUWTR9x6DveKHcIh08bdsvcyL0PWlUiiacDiA42TWoPIwm+P/pgf 9fzR9tWizc9vUQkskEny6eVUtsgLqrTbjEY+HSwHGZJ4P7eYvMk+B0aVjmWXD023WVxHrwFHb JOdMhfHMQlaARZ1CSwNm3cnaDcWZypp3PMTusLG8xGI1Tk62cILA5nIXNFJKzcq3nUOTZ7VIo 0GW027s4hEaTGJNArdDXmjQjM3Ozt5tZwbzevsXCCSGUSJIMUN2iFmvncjjnBt4Sebu/ZSBjm HiqQZQpIY+1CnyOJDWjuWSb95UbJ4PdryNjU3Rs7wu7cQ1hy7VxOi11VdxGi9vMW2x/Qn//iV Y0RhdHIYVCoYnJ4+xW3vG/3o+0JGLiqEoxJYa3Of6c3R8pC4uUtclXI5blYP9KOheak6VYNrt /XPzmRzfuud0f1kRajH3uLnj2PLBkZdKbaQ33mV2rQxX339bOT2vqXscMpdalejYedG2bG9uS X7FvCbU3X7+wMnum3+atrurYaXR6eVfpvJ0PZge017f50u4k3l1k6phxjdNPWT++c4e2Wt2QP +q8ZeSesaZVpRkLkqYtYwjBzBon4naB/QWk+Jp4DgQAAA== X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-8.tower-163.messagelabs.com!1521558173!151169565!1 X-Originating-IP: [216.32.180.180] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 64966 invoked from network); 20 Mar 2018 15:02:54 -0000 Received: from mail-bn3nam01lp0180.outbound.protection.outlook.com (HELO NAM01-BN3-obe.outbound.protection.outlook.com) (216.32.180.180) by server-8.tower-163.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 20 Mar 2018 15:02:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TTAvJoBeQuH8m8MBj9w6Ct08VssfR/qTzjNd6Azz7P4=; b=Z3dpaO2UK5PvCaB3ESYUOKezEvQIHaJ9Ue1WTiHHB/E7Urqd4e9RSI5COa6n/V3s43wmE/1IiN8pwNm76XtXdtyI3Ca4Ge+tdpl6kGJVWfHmE7g/v69zDwKLG86zGa50oHQR+xPcbcNcKmjJC159dd09HYCy8otKfdocBGSqfgE= Received: from MWHPR14MB1376.namprd14.prod.outlook.com (10.173.232.139) by MWHPR14MB1549.namprd14.prod.outlook.com (10.173.233.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Tue, 20 Mar 2018 15:02:52 +0000 Received: from MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::7929:3f48:4a4f:1e32]) by MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::7929:3f48:4a4f:1e32%18]) with mapi id 15.20.0588.017; Tue, 20 Mar 2018 15:02:52 +0000 From: Tim Hollebeek To: RTCWeb IETF Thread-Topic: RTCWeb Identity and Crypto Agility Thread-Index: AdPAW3d8OIEwsiOHSU2AwOPzZ+qMbQ== Date: Tue, 20 Mar 2018 15:02:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [31.133.148.144] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR14MB1549; 7:nxnRbuMOsR3n1DJ6N3w5Wm19a7Re8Z3/KVXQJWLYM9UC2Ls4bV7NmuVTeJsfdml3eBOdgRvrd2ItikE7PQipvyTf0D6jjGxhJyxcDwldy6u0kCgR00PcoH4MwmvTew9JsZXJ1SYxHIpzFFBY06JTHxDjKEeV1ZWZhbmWOkRfu/MIPJIWeYbD/FesW3ODk/mk9ujeuTHxgW17N758vXjvwbUDe25ptB495BwXVnjjKRvR7v5x/lUPSr89DT2iFxbl x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: a16f6e8f-c116-4485-0781-08d58e73a75b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:MWHPR14MB1549; x-ms-traffictypediagnostic: MWHPR14MB1549: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231221)(944501312)(52105095)(93006095)(93001095)(3002001)(6041310)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MWHPR14MB1549; BCL:0; PCL:0; RULEID:; SRVR:MWHPR14MB1549; x-forefront-prvs: 061725F016 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(376002)(366004)(396003)(39380400002)(189003)(199004)(54896002)(3660700001)(2906002)(9686003)(68736007)(53936002)(7736002)(6436002)(6306002)(33656002)(74316002)(55016002)(3280700002)(14454004)(5660300001)(105586002)(25786009)(86362001)(97736004)(186003)(478600001)(106356001)(6916009)(6116002)(3846002)(99936001)(790700001)(316002)(6506007)(26005)(8676002)(102836004)(81166006)(81156014)(6346003)(8936002)(59450400001)(2900100001)(99286004)(7696005)(66066001)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR14MB1549; H:MWHPR14MB1376.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: jemAKK4+OrRgTirWPH2chBYzOMMZgTMNRu7U7y2ewJ7HdmA+jJ/Fslrkl8PY12P4Z1NOpzsgKXm6OCaM2N/WPgXCAB6nkRVZInpQarNCzHsZMlHbEgIuQVIzQNhvO90EgKg2XGtVTJvyxBTrPMClI8YwS2wzMw3n+GEXHpi17xzeP4xRdDtcRhJvuVfltnGKH5B2TCSSvIw9QKP5gQ2WZNdat6Gi7x75L4knREQ7LJh/spuGpyBViDMjRKA1uMSi9pCLEe8+ChINBorjJ2w0tay9aJydMNN9OUdGqcmMWcqRjJwa5orKm5bRs5DmXtbW8Et/5Jbrku7YRbG6OjA2Qg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_05CE_01D3C05C.8372A810" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: a16f6e8f-c116-4485-0781-08d58e73a75b X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2018 15:02:52.2155 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1549 Archived-At: Subject: [rtcweb] RTCWeb Identity and Crypto Agility X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 15:02:58 -0000 ------=_NextPart_000_05CE_01D3C05C.8372A810 Content-Type: multipart/alternative; boundary="----=_NextPart_001_05CF_01D3C05C.8372A810" ------=_NextPart_001_05CF_01D3C05C.8372A810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I promised to write this up a few days ago. One of the IETF security guys stopped by during the hackathon and we had an interesting discussion about whether RTCWeb Identity was unnecessarily complex. After looking at it for a while, my personal opinion is that it actually has some useful security properties that make the complexity worthwhile. Specifically, the splitting of the transport certificate and the identity assertion allows for some interesting use cases involving multiple identities and crypto agility. One can imagine one identity that can be asserted over two possible transport certificates, for example, one traditional one, and one hybrid (post-quantum) certificate. Some endpoints would only understand the first one, some would understand both. This would allow such an RTC system to be able to transition easily between "crypto eras". Similarly, one can have two identities linked to a particular fingerprint. I could generate assertions for a particular fingerprint from Giggle's OAUTH and another from Faceplant's certificate service, and let the other end decide which IDP it wants to use to verify the identity. And of course you can mix both of those, where you have various independent transport possibilities, and various independent identity assertion possibilities, without having a N^2 explosion of your configuration space. Overall, I think the RTCWeb identity architecture is actually kind of elegant, and worth continuing to think about more. There are probably lessons that can be learned and applied elsewhere. -Tim ------=_NextPart_001_05CF_01D3C05C.8372A810 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I promised = to write this up a few days ago.

 

One of the = IETF security guys stopped by during the hackathon and we = had

an interesting discussion about = whether RTCWeb Identity was unnecessarily

complex.

 

After = looking at it for a while, my personal opinion is that it actually = has

some useful security properties = that make the complexity worthwhile.

Specifically, the splitting of the transport = certificate and the identity

assertion allows for some interesting use cases = involving multiple identities

and = crypto agility.

 

One can = imagine one identity that can be asserted over two = possible

transport certificates, for = example, one traditional one, and one hybrid

(post-quantum) certificate.  Some endpoints would = only understand the

first one, some = would understand both.  This would allow such an = RTC

system to be able to transition = easily between “crypto eras”.

 

Similarly, = one can have two identities linked to a particular = fingerprint.

I could generate = assertions for a particular fingerprint from Giggle’s = OAUTH

and another from = Faceplant’s certificate service, and let the other = end

decide which IDP it wants to use = to verify the identity.

 

And of = course you can mix both of those, where you have = various

independent transport = possibilities, and various independent identity

assertion possibilities, without having a N^2 = explosion of your configuration

space.

 

Overall, I = think the RTCWeb identity architecture is actually kind of elegant, =

and worth continuing to think about = more.  There are probably lessons

that can be learned and applied = elsewhere.

 

-Tim

 

------=_NextPart_001_05CF_01D3C05C.8372A810-- ------=_NextPart_000_05CE_01D3C05C.8372A810 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgwMzIwMTUwMjQ5WjAvBgkqhkiG9w0BCQQxIgQgF9OdL2K+EdbEBMx4W8JhX1sJlbhz ttVvfGN98TXgIMEwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBABLEDNZhgDRMnt5f2sD8pu0NBMCNl8atCL40C89glm4q7vqX5FmQ5AFD9tI3dKLEMUpElcoJ H3jZODtkNgjWdO3Ux52ffTnZUfvMro3EbhplVp4G0hUDYy79KLZhFohxUNHfASbBarxh1Vx18FTg Nt67H+5+xYm00D12whOBCYJ+qLi1OWh744942Lgny3A3Fc3QQaaxzVBm1M0ulGj6aU+odBcQN0ea zZARAIj7+QjYKCvHaYuSWSilG3RFWYIdoaUwI4xFJzulpkcPDPJd2SkUFGuQ0dv51jXqaeNzMjX3 7GSF9NMyNpJegqyo8PRDpsunX+ew33nSuuQLf+j0fLMAAAAAAAA= ------=_NextPart_000_05CE_01D3C05C.8372A810-- From nobody Tue Mar 20 09:50:32 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC00812D876 for ; Tue, 20 Mar 2018 09:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 c7vSzLf-W4uP for ; Tue, 20 Mar 2018 09:50:25 -0700 (PDT) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (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 B417712EB35 for ; Tue, 20 Mar 2018 09:50:15 -0700 (PDT) Received: by mail-ot0-x22a.google.com with SMTP id x6-v6so1006792otg.11 for ; Tue, 20 Mar 2018 09:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wmBi26Rr6KUD8Yr1PnQTkbCZsVUCirB9M+3AJGbAFDA=; b=jAhQEvaHMEhwRyeTBnH2s6T9g5Wt2DDYfPYfzwOvSZKcX3RTutH2pEF5mDSF5AcTm0 Ltb4NEj6NaKOjv+iKNbmTBInkZtORM5zSFBozmvM1LcBXzlcL8YFt7qEc3LqRFSM7DjB DQghVdR20JFOjb4s7QgG5J2pCWv27Z/wgh/ZKx7zBa9iN2zom5Mv9Y7sPwBFsUvi1+Km r0ZVQ0bnbz8YEdXKBeRCX1KXpa8jernrB3Qb1zpfiYQJtq8XAmEYHPL3WaZHbJlBUMlS qfX+2nEw5yqXCkp8mV0YR9l65eyL/FSL0AmMzY4LV4HatOF8y+BNZnG/9ZGBsrPMzt6b zbjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wmBi26Rr6KUD8Yr1PnQTkbCZsVUCirB9M+3AJGbAFDA=; b=QSNFtWwYOxpT8Izk4rQVlAubSl0wV9iYe53o08TJ5DUzcjrOvDdiv8FO2w8mq1RWTD fUcg9ABi07iAq6r9SR67uoBJHhNCHqMtxMtS1uXb42mF6ZOqOTYe3c1JEDJEzaVHprz/ uAKmAfyvGaCB7+5hPvzyq1NZXU94uUXaooqc22RqhcmnM9QsGmjiQv5fsOqWyEpg8056 zLH7bt9+Mf/fESCfWqBaGNhL0zWOIW23wKZq6DzgKly337d2kd9fMl5WxEIWdL7bzKGO LJl+5M5lRsn8T1nQTd5HbGKb+Q89ErmzZTcsbUNltWHG9+XMVA+JtiUOclwSyDD4k8h9 Pykg== X-Gm-Message-State: AElRT7EmMwjrPVAnP+Cejo5QNzb5pPnZ63pe15g5PAsK/UZFD2mImhOR ruwlgDmtnPpzkB9F9JBkaj82tJq6WL5GSAeCs+Q= X-Google-Smtp-Source: AG47ELvfTWjFeXlfVwf49UNUeRQBiBqGPxAmofx6wC3aufbBS9rhlFa/y/dtaCYpqMnn50KlyiGiaMBHZBV/R+P0WPc= X-Received: by 2002:a9d:4e10:: with SMTP id p16-v6mr11487213otf.15.1521564614977; Tue, 20 Mar 2018 09:50:14 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Tue, 20 Mar 2018 09:50:14 -0700 (PDT) In-Reply-To: References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> <5d59eec9-62d6-94e4-517e-da6d0b9e3c41@gmail.com> <74c8e7ba-13f7-b92b-29b5-f4d43a6c9978@gmail.com> <48F10399-28DF-4998-9B40-3F341947F63C@westhawk.co.uk> <8E24CC04-0009-4789-8E10-EE3B66C077A5@westhawk.co.uk> <99324c1d-25a4-7506-6dab-1bb99ec27038@gmail.com> From: Martin Thomson Date: Tue, 20 Mar 2018 16:50:14 +0000 Message-ID: To: Sergio Garcia Murillo Cc: RTCWeb IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 16:50:31 -0000 So here's the view, as I understand it. More complex sites frequently generate multiple RTCPeerConnection instances for their communications, especially for group conversations. If the browser requests an assertion once and they use that value for every RTCPeerConnection, then that's OK. From my perspective, I would be happy modifying the protocol to include an identifier and prevent that; for this the IdP can use caching or its local storage. On Tue, Mar 20, 2018 at 2:16 PM, Sergio Garcia Murillo wrote: > Sure. > > Would be interesting to know what are the arguments in favor of identity > assertion reusability and portability (even within the same domain) vs > requesting a new assertion each time. > > Best regards > Sergio > > > On 20/03/2018 12:46, Martin Thomson wrote: >> >> Others have expressed the fact that this portability - within an >> origin - is a feature, not a bug. We should discuss more. >> >> On Tue, Mar 20, 2018 at 11:45 AM, Sergio Garcia Murillo >> wrote: >>> >>> That was also my understanding. >>> >>> So, we could solve the the identity assertion identity by supporting th= e >>> dtls external session id so it is unique per peerconnection and add it = as >>> nonce to the assertion generation (which seems like a nice to have >>> anyway) >>> and leave the postMessage support for certificates as it is (there coul= d >>> even be a valid usage for porting certificates across origins)? >>> >>> Would that work? >>> >>> Best regards >>> Sergio >>> >>> >>> On 20/03/2018 12:41, Martin Thomson wrote: >>>> >>>> Cooperating origins can always ensure linkability, so it's not a real >>>> risk. >>>> >>>> The exposure here is that it enables portability of the identity >>>> assertion. >>>> >>>> On Tue, Mar 20, 2018 at 8:39 AM, Sergio Garcia Murillo >>>> wrote: >>>>> >>>>> Leaving the identity assertion implications, what would be the risks = of >>>>> sharing a certificate between different origins. >>>>> >>>>> I think you mentioned user tracking already, how that would be done? >>>>> >>>>> Best regards >>>>> Sergio >>>>> >>>>> >>>>> On 20/03/2018 9:14, Martin Thomson wrote: >>>>>> >>>>>> I want to enable storage (that's the point of the feature), but not >>>>>> cross-origin transfers. >>>>>> >>>>>> On Mon, Mar 19, 2018 at 10:43 PM, westhawk wrot= e: >>>>>>> >>>>>>> >>>>>>>> On 19 Mar 2018, at 20:13, westhawk wrote: >>>>>>>> >>>>>>>> Storage or cloning ? >>>>>>> >>>>>>> Because I have a _very_ good use for storage and re-use of certs. >>>>>>> I have no desire to post message them around though. >>>>>>> >>>>>>> T. >>>>>>> >>>>>>>>> On 19 Mar 2018, at 17:23, Martin Thomson >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> That was never the intent. The reason for marking this cloneable >>>>>>>>> is >>>>>>>>> to enable storage in indexedDB. We should close that option. >>>>>>>>> There >>>>>>>>> is no good reason to allow this usage. >>>>>>>>> >>>>>>>>> On Mon, Mar 19, 2018 at 3:03 PM, Sergio Garcia Murillo >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Found it, they are not origin bounded: >>>>>>>>>> >>>>>>>>>> The RTCCertificate object can be stored and retrieved from >>>>>>>>>> persistent >>>>>>>>>> storage by an application. When a user agent is required to obta= in >>>>>>>>>> a >>>>>>>>>> structured clone [HTML51] of an RTCCertificate object, it perfor= ms >>>>>>>>>> the >>>>>>>>>> following steps >>>>>>>>>> >>>>>>>>>> And on HTML5 spec: >>>>>>>>>> >>>>>>>>>> Cloneable objects support being cloned across event loops. That >>>>>>>>>> is, >>>>>>>>>> they >>>>>>>>>> support being cloned across Documentand Worker boundaries, >>>>>>>>>> including >>>>>>>>>> across >>>>>>>>>> Documents of different origins. Not all objects are cloneable >>>>>>>>>> objectsand not >>>>>>>>>> all aspects of objects that are cloneable objects are necessaril= y >>>>>>>>>> preserved >>>>>>>>>> when cloned. >>>>>>>>>> >>>>>>>>>> So you can perfectly do the following: >>>>>>>>>> >>>>>>>>>> RTCPeerConnection.generateCertificate({ >>>>>>>>>> name: 'RSASSA-PKCS1-v1_5', >>>>>>>>>> hash: 'SHA-256', >>>>>>>>>> modulusLength: 2048, >>>>>>>>>> publicExponent: new Uint8Array([1, 0, 1]) >>>>>>>>>> }).then(function(cert) { >>>>>>>>>> windowInOderDomain.postMessage(cert,"*") >>>>>>>>>> }); >>>>>>>>>> >>>>>>>>>> And the other window will able to reuse it. However, the >>>>>>>>>> certificate >>>>>>>>>> won't >>>>>>>>>> be serialized in anyway that could be extracted from the browser= . >>>>>>>>>> >>>>>>>>>> Best regards >>>>>>>>>> Sergio >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 19/03/2018 15:43, Martin Thomson wrote: >>>>>>>>>> >>>>>>>>>> As a practical matter, if the browser were to use the same >>>>>>>>>> certificate >>>>>>>>>> for multiple origins, then it would create a massive privacy >>>>>>>>>> problem >>>>>>>>>> that enables linkability (aka user tracking). I couldn't find >>>>>>>>>> that >>>>>>>>>> written down, but I thought it was. If it isn't written down, >>>>>>>>>> then >>>>>>>>>> we >>>>>>>>>> should correct that. >>>>>>>>>> >>>>>>>>>> On Mon, Mar 19, 2018 at 1:57 PM, Sergio Garcia Murillo >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> On 19/03/2018 14:45, westhawk wrote: >>>>>>>>>> >>>>>>>>>> On 19 Mar 2018, at 13:40, Martin Thomson >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> It's anything that *the site* initiates (not so much the browser= ). >>>>>>>>>> Certificates are origin-scoped. >>>>>>>>>> >>>>>>>>>> Are they? is the private key needed in the re-use of the >>>>>>>>>> assertion? >>>>>>>>>> (I haven=E2=80=99t looked at this for ages) >>>>>>>>>> If not the you could push the ASN1 of the public cert somewhere >>>>>>>>>> not >>>>>>>>>> scoped >>>>>>>>>> to the >>>>>>>>>> origin and have another site re-use it. (e.g. transfer it to an >>>>>>>>>> advert >>>>>>>>>> iframe with postmessage) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> After checking if further, that may not be clearly explicit on t= he >>>>>>>>>> webrtc >>>>>>>>>> w3c spec: >>>>>>>>>> >>>>>>>>>> For the purposes of this API, the [[Certificate]] slot contains >>>>>>>>>> unstructured >>>>>>>>>> binary data. No mechanism is provided for applications to access >>>>>>>>>> the >>>>>>>>>> [[KeyingMaterial]] internal slot. Implementations MUST support >>>>>>>>>> applications >>>>>>>>>> storing and retrieving RTCCertificate objects from persistent >>>>>>>>>> storage. >>>>>>>>>> In >>>>>>>>>> implementations where an RTCCertificate might not directly hold >>>>>>>>>> private >>>>>>>>>> keying material (it might be stored in a secure module), a >>>>>>>>>> reference >>>>>>>>>> to the >>>>>>>>>> private key can be held in the [[KeyingMaterial]] internal slot, >>>>>>>>>> allowing >>>>>>>>>> the private key to be stored and used. >>>>>>>>>> >>>>>>>>>> So it is not clear to me if certificates are origin-scoped or if >>>>>>>>>> the >>>>>>>>>> key >>>>>>>>>> materials could be exported outside of the browser. Worst case, >>>>>>>>>> certificate >>>>>>>>>> could be exported and identity assertion reused even by a >>>>>>>>>> different >>>>>>>>>> service. >>>>>>>>>> >>>>>>>>>> Best regards >>>>>>>>>> Sergio >>>>>>>>>> >>>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> rtcweb mailing list >>>>>>>> rtcweb@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>> >>>>>> _______________________________________________ >>>>>> rtcweb mailing list >>>>>> rtcweb@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >>> > From nobody Thu Mar 22 09:41:22 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49536127010; Thu, 22 Mar 2018 09:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 DHLox_G5WRSW; Thu, 22 Mar 2018 09:41:18 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 98B74124B17; Thu, 22 Mar 2018 09:41:18 -0700 (PDT) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 0481E9E12100D; Thu, 22 Mar 2018 16:41:15 +0000 (GMT) Received: from DGGEMM424-HUB.china.huawei.com (10.1.198.41) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 22 Mar 2018 16:41:16 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by dggemm424-hub.china.huawei.com ([10.1.198.41]) with mapi id 14.03.0361.001; Fri, 23 Mar 2018 00:41:12 +0800 From: "Roni Even (A)" To: "payload@ietf.org" CC: "rtcweb@ietf.org" Thread-Topic: Second WGLC on draft-ietf-payload-flexible-fec-scheme Thread-Index: AdPB++FNFyNr/SHZTm6JnPXdmrK5pg== Date: Thu, 22 Mar 2018 16:41:11 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD86E663@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.83.153] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD86E663DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [rtcweb] Second WGLC on draft-ietf-payload-flexible-fec-scheme X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2018 16:41:20 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD86E663DGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I would like to start a three week second WGLC on RTP Payload Format for Fl= exible Forward Error Correction in draft-ietf-payload-flexible-fec-scheme-0= 7. The WGLC will end on April 11th , 2018 Note that the first WGLC was on the 05 version and the 06,07 are increment= al updates. The slides from the IETF 101 payload session describe the changes see https= ://datatracker.ietf.org/meeting/101/materials/slides-101-payload-flexible-f= ec-00 . Please send comments to the payload mailing list. The double posting is to notify RTCweb WG that the second WGLC has starte= d since this document is needed for RTCweb Roni Even Payload WG co-chair --_000_6E58094ECC8D8344914996DAD28F1CCD86E663DGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I would like to start a three week second WGLC on RTP Payload Format for Flexible Forward Error Correction in draft-ietf-payload-flexible-fec-scheme-07.

The WGLC will end on April 11th , 2018

 

Note that the first WGLC was on the 05 version  = ;and the 06,07 are incremental updates.

The slides from the IETF 101 payload session describ= e the changes see https://datatracker.ietf.org/meeting/101/materials/slides-101-payload-flexi= ble-fec-00 .

 

Please send comments to the payload mailing list.

The double posting is to  notify RTCweb WG that the second  WGLC has started since this d= ocument is needed for RTCweb

 =

 =

Roni Even

Payload WG co-chair=

 

--_000_6E58094ECC8D8344914996DAD28F1CCD86E663DGGEMM506MBXchina_-- From nobody Fri Mar 23 04:23:41 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB9812D86B for ; Fri, 23 Mar 2018 04:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 MtglBGBWC7pD for ; Fri, 23 Mar 2018 04:23:28 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 DBC7212D7E5 for ; Fri, 23 Mar 2018 04:23:27 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id a11so1232338pff.8 for ; Fri, 23 Mar 2018 04:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=f2ItR6qSPQak3QntW4AS/G8NtBVwRM/yKSmVCs7VXmg=; b=jlHwtb5IIcG6IV1ziOTZu8OXwiB/wh0hGlySzGoAPzTyC4Dy9PwvaZkAbzZ4wVsDsE 0Dq1BFghFR2eGaWZCNbsmMb8tpqVhNoNB57Id+YHxuwrcVQ/ehhdOkJ7XudhcFWiyNL7 tZ5JCMZUgvtBd0LT7qPSKe06GbSBXDWNe3h2Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=f2ItR6qSPQak3QntW4AS/G8NtBVwRM/yKSmVCs7VXmg=; b=Ra1fUO3wCKnJt13xaopABlXtN918JHxTpKfFv6jOvt5Grkt6ZD+0ft8+TdNHDotlj+ UPEPgi4RSZk0c/41ULpPXFPVu7wuK9KmePUU8JXSyPvm/7TUEOUXgQdhsJDbqMRozqb9 spTADjVMFOkSFJhNS9ww7MLI6/9reGgE4dfA4diIVnz74JKApIN+ZFowlmhWx2Pm/Gm9 NAZGymp8czfID8yRA0PAGNjRT1ld3JPyRjIZecS4yEUCQaCtwnqgHxlVygjCvl6ockX0 ZFUd2ApSUt7U3nrirrHcdEXu9sCY5tv5OcY0L9/qMQL+7yyapiF5KP7ksgFI23vxV2qO Z+Lg== X-Gm-Message-State: AElRT7EV78rV4BENznQbd5TOVafcZIwKCHvPB1k4/ThkA62q8WKhq2bS yW2++TO0xleMCFDOYyJt5KsN13rj8uTwuw== X-Google-Smtp-Source: AG47ELtgIREelu+ZknZ7dQSkAYO8tndJ1uLKlvFTLbvVuRXiyq2p2KOhbNNy8/upIYByZm5fEhsIZA== X-Received: by 10.99.101.198 with SMTP id z189mr20645301pgb.97.1521804207121; Fri, 23 Mar 2018 04:23:27 -0700 (PDT) Received: from [5.5.33.229] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id u28sm18565007pfl.19.2018.03.23.04.23.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Mar 2018 04:23:26 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <1DFCBB05-03E3-4DA9-8E3C-A7E399F1185F@sn3rd.com> Date: Fri, 23 Mar 2018 11:23:20 +0000 To: RTCWeb IETF X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [rtcweb] Reminder: two ongoing WGLCs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 11:23:40 -0000 As IETF 101 week comes to a close, I=E2=80=99d like to remind the WG = about two WGLCs that are in progress. Please post to the appropriate threads: draft-ietf-rtcweb-ip-handling - closes @ 2359 on March 30th: https://mailarchive.ietf.org/arch/msg/rtcweb/gERGo7bxmsKp1CPLyIIFlfDU4MU draft-ietf-rtcweb-security-arch - closes @ 2359 on April 6th: https://mailarchive.ietf.org/arch/msg/rtcweb/fhN2g8-iAfWNrtCpUYWH16433XY spt= From nobody Sat Mar 24 01:06:45 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A48126BFD for ; Sat, 24 Mar 2018 01:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 2orXMrsKB7tZ for ; Sat, 24 Mar 2018 01:06:41 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA74D1242F7 for ; Sat, 24 Mar 2018 01:06:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 32F757C3CA0; Sat, 24 Mar 2018 09:06:39 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQQa1G5PcF5b; Sat, 24 Mar 2018 09:06:36 +0100 (CET) Received: from [192.168.3.17] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id B3A8D7C41D8; Sat, 24 Mar 2018 09:06:36 +0100 (CET) To: Martin Thomson , Sergio Garcia Murillo Cc: RTCWeb IETF References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> <5d59eec9-62d6-94e4-517e-da6d0b9e3c41@gmail.com> <74c8e7ba-13f7-b92b-29b5-f4d43a6c9978@gmail.com> <48F10399-28DF-4998-9B40-3F341947F63C@westhawk.co.uk> <8E24CC04-0009-4789-8E10-EE3B66C077A5@westhawk.co.uk> <99324c1d-25a4-7506-6dab-1bb99ec27038@gmail.com> From: Harald Alvestrand Message-ID: Date: Sat, 24 Mar 2018 09:04:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2018 08:06:44 -0000 Den 20. mars 2018 17:50, skrev Martin Thomson: > So here's the view, as I understand it. > > More complex sites frequently generate multiple RTCPeerConnection > instances for their communications, especially for group > conversations. If the browser requests an assertion once and they use > that value for every RTCPeerConnection, then that's OK. From my > perspective, I would be happy modifying the protocol to include an > identifier and prevent that; for this the IdP can use caching or its > local storage. If I were an IdP, and worried about server load, I'd authenticate the user once (via login / cookies) and then use the cookies to generate fresh assertions whenever they're asked for. If I remember the spec correctly, it's unclear whether calling createOffer() twice on the same PC will generate two requests for identity assertions or only one; I don't remember seeing two requests when I was debugging my identity provider and calling createAssertion followed by a createOffer - but debugging IdP is hard in Firefox because console is not available in the IdP context (I think this is a bug), so it might have happened. > > On Tue, Mar 20, 2018 at 2:16 PM, Sergio Garcia Murillo > wrote: >> Sure. >> >> Would be interesting to know what are the arguments in favor of identity >> assertion reusability and portability (even within the same domain) vs >> requesting a new assertion each time. >> >> Best regards >> Sergio >> >> >> On 20/03/2018 12:46, Martin Thomson wrote: >>> >>> Others have expressed the fact that this portability - within an >>> origin - is a feature, not a bug. We should discuss more. >>> >>> On Tue, Mar 20, 2018 at 11:45 AM, Sergio Garcia Murillo >>> wrote: >>>> >>>> That was also my understanding. >>>> >>>> So, we could solve the the identity assertion identity by supporting the >>>> dtls external session id so it is unique per peerconnection and add it as >>>> nonce to the assertion generation (which seems like a nice to have >>>> anyway) >>>> and leave the postMessage support for certificates as it is (there could >>>> even be a valid usage for porting certificates across origins)? >>>> >>>> Would that work? >>>> >>>> Best regards >>>> Sergio >>>> >>>> >>>> On 20/03/2018 12:41, Martin Thomson wrote: >>>>> >>>>> Cooperating origins can always ensure linkability, so it's not a real >>>>> risk. >>>>> >>>>> The exposure here is that it enables portability of the identity >>>>> assertion. >>>>> >>>>> On Tue, Mar 20, 2018 at 8:39 AM, Sergio Garcia Murillo >>>>> wrote: >>>>>> >>>>>> Leaving the identity assertion implications, what would be the risks of >>>>>> sharing a certificate between different origins. >>>>>> >>>>>> I think you mentioned user tracking already, how that would be done? >>>>>> >>>>>> Best regards >>>>>> Sergio >>>>>> >>>>>> >>>>>> On 20/03/2018 9:14, Martin Thomson wrote: >>>>>>> >>>>>>> I want to enable storage (that's the point of the feature), but not >>>>>>> cross-origin transfers. >>>>>>> >>>>>>> On Mon, Mar 19, 2018 at 10:43 PM, westhawk wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On 19 Mar 2018, at 20:13, westhawk wrote: >>>>>>>>> >>>>>>>>> Storage or cloning ? >>>>>>>> >>>>>>>> Because I have a _very_ good use for storage and re-use of certs. >>>>>>>> I have no desire to post message them around though. >>>>>>>> >>>>>>>> T. >>>>>>>> >>>>>>>>>> On 19 Mar 2018, at 17:23, Martin Thomson >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> That was never the intent. The reason for marking this cloneable >>>>>>>>>> is >>>>>>>>>> to enable storage in indexedDB. We should close that option. >>>>>>>>>> There >>>>>>>>>> is no good reason to allow this usage. >>>>>>>>>> >>>>>>>>>> On Mon, Mar 19, 2018 at 3:03 PM, Sergio Garcia Murillo >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Found it, they are not origin bounded: >>>>>>>>>>> >>>>>>>>>>> The RTCCertificate object can be stored and retrieved from >>>>>>>>>>> persistent >>>>>>>>>>> storage by an application. When a user agent is required to obtain >>>>>>>>>>> a >>>>>>>>>>> structured clone [HTML51] of an RTCCertificate object, it performs >>>>>>>>>>> the >>>>>>>>>>> following steps >>>>>>>>>>> >>>>>>>>>>> And on HTML5 spec: >>>>>>>>>>> >>>>>>>>>>> Cloneable objects support being cloned across event loops. That >>>>>>>>>>> is, >>>>>>>>>>> they >>>>>>>>>>> support being cloned across Documentand Worker boundaries, >>>>>>>>>>> including >>>>>>>>>>> across >>>>>>>>>>> Documents of different origins. Not all objects are cloneable >>>>>>>>>>> objectsand not >>>>>>>>>>> all aspects of objects that are cloneable objects are necessarily >>>>>>>>>>> preserved >>>>>>>>>>> when cloned. >>>>>>>>>>> >>>>>>>>>>> So you can perfectly do the following: >>>>>>>>>>> >>>>>>>>>>> RTCPeerConnection.generateCertificate({ >>>>>>>>>>> name: 'RSASSA-PKCS1-v1_5', >>>>>>>>>>> hash: 'SHA-256', >>>>>>>>>>> modulusLength: 2048, >>>>>>>>>>> publicExponent: new Uint8Array([1, 0, 1]) >>>>>>>>>>> }).then(function(cert) { >>>>>>>>>>> windowInOderDomain.postMessage(cert,"*") >>>>>>>>>>> }); >>>>>>>>>>> >>>>>>>>>>> And the other window will able to reuse it. However, the >>>>>>>>>>> certificate >>>>>>>>>>> won't >>>>>>>>>>> be serialized in anyway that could be extracted from the browser. >>>>>>>>>>> >>>>>>>>>>> Best regards >>>>>>>>>>> Sergio >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 19/03/2018 15:43, Martin Thomson wrote: >>>>>>>>>>> >>>>>>>>>>> As a practical matter, if the browser were to use the same >>>>>>>>>>> certificate >>>>>>>>>>> for multiple origins, then it would create a massive privacy >>>>>>>>>>> problem >>>>>>>>>>> that enables linkability (aka user tracking). I couldn't find >>>>>>>>>>> that >>>>>>>>>>> written down, but I thought it was. If it isn't written down, >>>>>>>>>>> then >>>>>>>>>>> we >>>>>>>>>>> should correct that. >>>>>>>>>>> >>>>>>>>>>> On Mon, Mar 19, 2018 at 1:57 PM, Sergio Garcia Murillo >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> On 19/03/2018 14:45, westhawk wrote: >>>>>>>>>>> >>>>>>>>>>> On 19 Mar 2018, at 13:40, Martin Thomson >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> It's anything that *the site* initiates (not so much the browser). >>>>>>>>>>> Certificates are origin-scoped. >>>>>>>>>>> >>>>>>>>>>> Are they? is the private key needed in the re-use of the >>>>>>>>>>> assertion? >>>>>>>>>>> (I haven’t looked at this for ages) >>>>>>>>>>> If not the you could push the ASN1 of the public cert somewhere >>>>>>>>>>> not >>>>>>>>>>> scoped >>>>>>>>>>> to the >>>>>>>>>>> origin and have another site re-use it. (e.g. transfer it to an >>>>>>>>>>> advert >>>>>>>>>>> iframe with postmessage) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> After checking if further, that may not be clearly explicit on the >>>>>>>>>>> webrtc >>>>>>>>>>> w3c spec: >>>>>>>>>>> >>>>>>>>>>> For the purposes of this API, the [[Certificate]] slot contains >>>>>>>>>>> unstructured >>>>>>>>>>> binary data. No mechanism is provided for applications to access >>>>>>>>>>> the >>>>>>>>>>> [[KeyingMaterial]] internal slot. Implementations MUST support >>>>>>>>>>> applications >>>>>>>>>>> storing and retrieving RTCCertificate objects from persistent >>>>>>>>>>> storage. >>>>>>>>>>> In >>>>>>>>>>> implementations where an RTCCertificate might not directly hold >>>>>>>>>>> private >>>>>>>>>>> keying material (it might be stored in a secure module), a >>>>>>>>>>> reference >>>>>>>>>>> to the >>>>>>>>>>> private key can be held in the [[KeyingMaterial]] internal slot, >>>>>>>>>>> allowing >>>>>>>>>>> the private key to be stored and used. >>>>>>>>>>> >>>>>>>>>>> So it is not clear to me if certificates are origin-scoped or if >>>>>>>>>>> the >>>>>>>>>>> key >>>>>>>>>>> materials could be exported outside of the browser. Worst case, >>>>>>>>>>> certificate >>>>>>>>>>> could be exported and identity assertion reused even by a >>>>>>>>>>> different >>>>>>>>>>> service. >>>>>>>>>>> >>>>>>>>>>> Best regards >>>>>>>>>>> Sergio >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> rtcweb mailing list >>>>>>>>> rtcweb@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>>> >>>>>>> _______________________________________________ >>>>>>> rtcweb mailing list >>>>>>> rtcweb@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> rtcweb mailing list >>>>>> rtcweb@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>>> >>>> >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Sat Mar 24 17:04:53 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A621B126BF3 for ; Sat, 24 Mar 2018 17:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 91ZOZwhnBMWk for ; Sat, 24 Mar 2018 17:04:51 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (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 44E2812025C for ; Sat, 24 Mar 2018 17:04:51 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id u11so3156380wri.12 for ; Sat, 24 Mar 2018 17:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=PzxZLhhpFzZTkOLNYgEkfRBikGLrD/LQm1McC/yj8yw=; b=WYqRFG8TrN9g4WhKfijDLppES2Sm3tiaPxlYVFTQ6ZGC6texo8056CpStQHrZgdVu8 +M3WGYgj0r4xUJkQ9Jwi/OrwXOywUxEn7YGD+UL3ixxc7/I9UfizjMfa0O01ZRheAItA DyNU2r80aS53Jaui1G9wjz6Fwtj05KIUMR9pBgvIr6cE8xR+RUy+LdxyTV2LAbYs0mkT BAG9nHTgc5UtzcATQgcZhpvg/Haxv8/PBP5v+kLR3pkvD8j8NdgtgPRKVPGZD9cKe0cH Voph225quvEi7QKHrP1sf3VFYcyUQ7RJeOF7Xdx0Jkmlc5X639RT+D0nzw/XuUlnGRbL dzaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=PzxZLhhpFzZTkOLNYgEkfRBikGLrD/LQm1McC/yj8yw=; b=HAGOH8HKuNCG8bwa351CmscO2nWc9kfRB96WfXv8j2kLlF59vMmFOu5fsbMy+EQ5RR i9rAC365pzMEEZEsfiOn0qpxedu0sP3SGV2kCRAQTQHrA7WGfs/5MUvVo3BhgLfFN3DE OQVHcuRM4xNGA2yIGWyu6nDt7U2QDX8wJpjnX6b7x+Sj4i7/iGbtK/pSbLAKDfSXi6gT chyHBSVo/5nVz4ps3/sXLKYRfBqW3vyZtZbNOBpiXL0BpKHzlBZ+KNs8qwedTgFwcRA9 ji0I8euh5rPVW645/6qO2DtvyF73QKVpOSJ2iN04nyqp5ipaEva5AyZ8EOc7Fu+mgRv9 w4iQ== X-Gm-Message-State: AElRT7HMUMxvSXgFtWGu4alTcMl5kshL+jlgBG8Im5cIPvrmbQEWaC7Q MdDC+26Yu0yniWkYxvMQohjb0VkA X-Google-Smtp-Source: AG47ELsT9qsHSdkjQxQfYE4XVqZNeqn77NwplYrZPF0csXcXj9E6WOEG9hlvlbKXnzNt1Y+B25mdyQ== X-Received: by 10.223.135.155 with SMTP id b27mr13180996wrb.119.1521936289644; Sat, 24 Mar 2018 17:04:49 -0700 (PDT) Received: from [192.168.1.66] ([77.209.251.115]) by smtp.googlemail.com with ESMTPSA id t79sm12350235wmt.46.2018.03.24.17.04.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Mar 2018 17:04:48 -0700 (PDT) To: Harald Alvestrand , Martin Thomson Cc: RTCWeb IETF References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> <5d59eec9-62d6-94e4-517e-da6d0b9e3c41@gmail.com> <74c8e7ba-13f7-b92b-29b5-f4d43a6c9978@gmail.com> <48F10399-28DF-4998-9B40-3F341947F63C@westhawk.co.uk> <8E24CC04-0009-4789-8E10-EE3B66C077A5@westhawk.co.uk> <99324c1d-25a4-7506-6dab-1bb99ec27038@gmail.com> From: Sergio Garcia Murillo Message-ID: Date: Sun, 25 Mar 2018 01:04:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 00:04:52 -0000 On 24/03/2018 9:04, Harald Alvestrand wrote: > Den 20. mars 2018 17:50, skrev Martin Thomson: >> So here's the view, as I understand it. >> >> More complex sites frequently generate multiple RTCPeerConnection >> instances for their communications, especially for group >> conversations. If the browser requests an assertion once and they use >> that value for every RTCPeerConnection, then that's OK. From my >> perspective, I would be happy modifying the protocol to include an >> identifier and prevent that; for this the IdP can use caching or its >> local storage. > If I were an IdP, and worried about server load, I'd authenticate the > user once (via login / cookies) and then use the cookies to generate > fresh assertions whenever they're asked for. > > If I remember the spec correctly, it's unclear whether calling > createOffer() twice on the same PC will generate two requests for > identity assertions or only one; I don't remember seeing two requests > when I was debugging my identity provider and calling createAssertion > followed by a createOffer - but debugging IdP is hard in Firefox because > console is not available in the IdP context (I think this is a bug), so > it might have happened. Also, I don't get where the server load comes from when the hashing can be done client side, so there is no significant extra load for generating new identities. Best regards Sergio From nobody Sat Mar 24 17:08:08 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B887126BF3 for ; Sat, 24 Mar 2018 17:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 47_9yp0QgdHX for ; Sat, 24 Mar 2018 17:08:04 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 78FE212025C for ; Sat, 24 Mar 2018 17:08:04 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id v21so9448500wmc.1 for ; Sat, 24 Mar 2018 17:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=+DP62K0nku7FTDAU7nKfkstjFIZN7MAMrxa99qk7bto=; b=jaAg02bOPYlwA7S7/xwM18noaf9Bkh0eUfeNOGlDcLiBr98xPiFPTdACtH1Up9FCaR 5vNjWGi4wMVdQdcrHNXKw64AJXFOF0MH0bpLaFUC+BrR6pM3OGkMmMtUELimHI+udn8y VrYnXgKABf0KzjOfrTDHVpJdhL2MnWYYj2UsjBp0XAHhz9X/CVxJhtEqEZjR9I3dDs31 0mxDH50txvk/0Jmta05Haxz548DVjs41uLCRE1ZdJOGBCyAnSzLnCetR9ZhQcsLOqFJ2 fpywas11yurn5ggTr8t4I2SBMfb2njFhRFd29BreJ4c9yGhoL9Y6t+6HZvV8u3RkXBmi ivTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=+DP62K0nku7FTDAU7nKfkstjFIZN7MAMrxa99qk7bto=; b=SFkuURRH+09kOHrrS/vtq4g+NpEbW5saBGRl+18hhEJIelJioAi5DHb7ssKZPiUcrl TkMr9U0KMVgz/HPH1jFPcLB4Q4gyq/P469FcjWIIL27AY2DMB2uTBCtuPGFCNSIbay4P z/CDmH0YLOlYV/0rNnj2ItuFouV0N7P4hATf/HhArjpzVGlalCifV8/h7opowuUME/Oj 3p/HvKP+p0G/jaB/0uOEZxABKAHzlzXMQj03Q8lN53nUe//LHC5fGaWoSx21ivxKnvQ6 2f2FSO6f0RY7jOa7EXTtx/6CTjBRPjPYudbhng1Jmef1SExDFqIOTkKEQVNsrLpTfsV2 9oAQ== X-Gm-Message-State: AElRT7H/dLXWLN+KO3cerEX9H22v3KQLF2ez0JLJt+CFMZ7iN+z/UoTi ACueZ6E2B1omkeC/RZ9Bi/3Xb1ck X-Google-Smtp-Source: AG47ELvi0q0XjbZG6lnmRvcBhCAoF810w8VIQD39E34rV4ZHdSbZZsWx3E2yvOq8XFqYS83L1Iz5pA== X-Received: by 10.28.113.216 with SMTP id d85mr11043142wmi.97.1521936482823; Sat, 24 Mar 2018 17:08:02 -0700 (PDT) Received: from [192.168.1.66] ([77.209.251.115]) by smtp.googlemail.com with ESMTPSA id r15sm7190237wrr.79.2018.03.24.17.08.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Mar 2018 17:08:01 -0700 (PDT) From: Sergio Garcia Murillo To: Harald Alvestrand , Martin Thomson Cc: RTCWeb IETF References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> <5d59eec9-62d6-94e4-517e-da6d0b9e3c41@gmail.com> <74c8e7ba-13f7-b92b-29b5-f4d43a6c9978@gmail.com> <48F10399-28DF-4998-9B40-3F341947F63C@westhawk.co.uk> <8E24CC04-0009-4789-8E10-EE3B66C077A5@westhawk.co.uk> <99324c1d-25a4-7506-6dab-1bb99ec27038@gmail.com> Message-ID: <2ff6f5da-3edc-d0a1-80b6-40e1c2cdb2ef@gmail.com> Date: Sun, 25 Mar 2018 01:08:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 00:08:06 -0000 On 25/03/2018 1:04, Sergio Garcia Murillo wrote: > On 24/03/2018 9:04, Harald Alvestrand wrote: >> Den 20. mars 2018 17:50, skrev Martin Thomson: >>> So here's the view, as I understand it. >>> >>> More complex sites frequently generate multiple RTCPeerConnection >>> instances for their communications, especially for group >>> conversations.  If the browser requests an assertion once and they use >>> that value for every RTCPeerConnection, then that's OK.  From my >>> perspective, I would be happy modifying the protocol to include an >>> identifier and prevent that; for this the IdP can use caching or its >>> local storage. >> If I were an IdP, and worried about server load, I'd authenticate the >> user once (via login / cookies) and then use the cookies to generate >> fresh assertions whenever they're asked for. >> >> If I remember the spec correctly, it's unclear whether calling >> createOffer() twice on the same PC will generate two requests for >> identity assertions or only one; I don't remember seeing two requests >> when I was debugging my identity provider and calling createAssertion >> followed by a createOffer - but debugging IdP is hard in Firefox because >> console is not available in the IdP context (I think this is a bug), so >> it might have happened. > > Also, I don't get where the server load comes from when the hashing > can be done client side, so there is no significant extra load for > generating new identities. Moreover, adding the external session id and supporting it by the assertion API doesn't mean that it must be used by the IDP to generate the assertion and validate it afterwards. So it is still possible to cache identities assertions if the idp decides so. Best regards Sergio From nobody Tue Mar 27 09:57:59 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A003B126DED for ; Tue, 27 Mar 2018 09:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 iJcGunG5W6Kz for ; Tue, 27 Mar 2018 09:57:55 -0700 (PDT) Received: from smtp121.iad3a.emailsrvr.com (smtp121.iad3a.emailsrvr.com [173.203.187.121]) (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 714E2126CD8 for ; Tue, 27 Mar 2018 09:57:55 -0700 (PDT) Received: from smtp8.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp8.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 8373F549F; Tue, 27 Mar 2018 12:57:51 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp8.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 398145278; Tue, 27 Mar 2018 12:57:51 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Tue, 27 Mar 2018 12:57:51 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Cullen Jennings In-Reply-To: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> Date: Tue, 27 Mar 2018 10:57:49 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca> References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> To: RTCWeb IETF X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 16:57:58 -0000 Theses comments are sent as an individual contributor.=20 Let me start by saying I think I am in the rough on the consensus of = this draft and I expect the draft to be sent to the IESG with no = changes. For the record, as I have said at the floor microphone in the = past, I don't agree with the draft.=20 This draft results in the situation where implementations decide if they = should reveal the users location to the website by asking a questions of = the form "Will you allow example.com to use your camera?" If the user = says that is OK to use their camera, in many cases they have also = allowed the website to get their location via the IP address. =46rom a = user point of view, I think this is awful, There are many reasons I = might allow a website I do not trust to know my location to access my = camera - for example, I have a black cover over my camera and the = website won't work unless I say yes to this request. Or a webcam worker = where the job involves revealing video but revealing the locations they = work at may put them at risk of serious harm. Or I am in a domestic = abuse shelter and want to have a call but revealing may location puts me = at risk of physical harm. I do not think the IETF should in any way = endorse this extremely misleading form of consent. It is simply not = consent. I realize this would be good for companies that are primary = funded by by web advertising for which location is valuable. There are several people who's opinion I deeply respect that have looked = at this problem in detail. They somewhat agree the above is a problem, = but they argue it is better than any alternative design. I disagree with = this.The root of the problem we are trying to solve with this draft is = that some VPNs are configured to send some packets over the VPN while at = the same time some other packets are not sent over the VPN. If you use a = VPN configured like this to try and hide your location, WebRTC can end = up sending packets not over the VPN and that can reveal your location. I = think the right solution to this problem is to acknowledge this is a VPN = problem, not a WebRTC problem. If you are using a VPN to hide your = location, do not allow that VPN to send packets outside the VPN. I will = note most VPNs support this.=20 John Morris words from [1], more or less sum up about how I feel about = this - just reverse W3C and IETF. "By not actually building privacy into the specification, the W3C = has =20 both missed a significant opportunity to improve user privacy on the = =20 Web, and it has harmed the efforts of another standards body -- the =20= IETF -- to protect location privacy and to improve the privacy =20 paradigm for Internet services." =46rom a process point of view: 1) I have had time to express this = opinion in the rtcweb WG meetings and it has been discussed. My read of = the consensus in the room is that I am in the rough on this topic 2) I = don't think the rtcweb WG is the WG in the IETF with the most expertise = in VPNs Thanks, Cullen As FYI, the actual questions that are asked by today's browsers are = roughly the following: In firefox: "Will you allow webrtc.github.io to use your camera?" In chrome: "webrtc.github.io wants to use your camera" In safari: "Allow webrtc.github.io to use your camera?" In edge: "Let webrtc.github.io use your webcam?=E2=80=9D [1] = https://lists.w3.org/Archives/Public/public-geolocation/2009Jul/0020.html > On Mar 7, 2018, at 7:49 PM, Sean Turner wrote: >=20 > All, >=20 > This is the WGLC for the "WebRTC IP Address Handling Requirements=E2=80=9D= draft available @ = https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/. Please = review the draft and send your comments to this list by 2359UTC on 30 = March 30 2017. >=20 > Thanks, > C/T/S > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Mar 27 10:15:34 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60EB0126DED for ; Tue, 27 Mar 2018 10:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 xAVzQJ9bHQBw for ; Tue, 27 Mar 2018 10:15:31 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0266120725 for ; Tue, 27 Mar 2018 10:15:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4E582BE64; Tue, 27 Mar 2018 18:15:28 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHk7iLZ8beTs; Tue, 27 Mar 2018 18:15:28 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0ABE8BE5F; Tue, 27 Mar 2018 18:15:28 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1522170928; bh=5BfY9biBW3rA/EMYWu7YDVUbn2fVMe5tHx1QNKvo/V0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=WPA+NvrHjD1eC32SnHRA5uN7385xNK1snj0LKFSNuF5qEjoD0SwGgV+iqcpBG5YW6 E9qdTgzibTYYfciDck0/TCfgx0SLMyxf8om2tL34M5h3Z3EzT+YpPArtnxXcHeHFiT 8gnxQSZ12d17I1BZQwX6xdVdB56mGNTE93aX9F5E= To: Cullen Jennings , RTCWeb IETF References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <6bc16ed5-e77b-a08c-b7de-2bc127e35eea@cs.tcd.ie> Date: Tue, 27 Mar 2018 18:15:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Ttjej5l4m4nD1WTs1rRkedsRQKseiKvi8" Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 17:15:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ttjej5l4m4nD1WTs1rRkedsRQKseiKvi8 Content-Type: multipart/mixed; boundary="l900oZup7DHn2XcswVFZZA9vS95VUBsCs"; protected-headers="v1" From: Stephen Farrell To: Cullen Jennings , RTCWeb IETF Message-ID: <6bc16ed5-e77b-a08c-b7de-2bc127e35eea@cs.tcd.ie> Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca> In-Reply-To: <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca> --l900oZup7DHn2XcswVFZZA9vS95VUBsCs Content-Type: multipart/mixed; boundary="------------92EF7C045B47E375DA47DB59" Content-Language: en-GB This is a multi-part message in MIME format. --------------92EF7C045B47E375DA47DB59 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 27/03/18 17:57, Cullen Jennings wrote: > Let me start by saying I think I am in the rough on the consensus of > this draft and I expect the draft to be sent to the IESG with no > changes. For the record, as I have said at the floor microphone in > the past, I don't agree with the draft. As I said also on the list in the past, I fully agree with Cullen but also think we're both in the rough. The only thing I'd add is that I also think having any concept of "consent" in IETF protocol specifications at this layer or below is also a bad precedent. S. --------------92EF7C045B47E375DA47DB59 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------92EF7C045B47E375DA47DB59-- --l900oZup7DHn2XcswVFZZA9vS95VUBsCs-- --Ttjej5l4m4nD1WTs1rRkedsRQKseiKvi8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaunwvAAoJEFqy+vF7FyvqBfMP/2F8AQUWHQSVEtVl+G4KTLHJ Zrr4CHQSdBZI85nY2peWTkIl5UKSG+zxXny1CPevXEpoa9ZVQNXnKhjr4VFMMj/0 MwY0Z0g83FgVjlcrjayim2TZY3V1v5aOrbVCwvBNEPt4jaEyR+XQA8yPwHs68Wwb apK/LVZOpeELlrwWRGwwiUpRJIsoe+lGmnOFqLHZ94bFLy3cXD/xrzP02DWmpKka lge6KZGMa/urEWiJKdKXVBzA22SFcHtLuUQb3JMxH1R63D7N5lxg5L2913PM5GUM dvwLSs3BdWPePw3M3Tt3ubTkQMR0u93P4Ewl8ZDN3Mn0jvtdga7/dBuyfhODn67I YD5UMjYB3UzparKs2WUlQwRMzVq6pIY4T+f3SKxgTnYypdZkaSq+FcgXWGKVj5rq IiMT54ybweIpnr98KOnuTghLXSqJ60r3uhAN8gLthiCE9zSmCCgDbaEap0hngx47 CJC/tkhEBPF16fsGzH1Xl036jZ9rDGLEL2Fh1uGNJZwnJIykNWxdmSLqIXts+fF0 PtYRA7dT9IMQ7SyXqLqtDzcQrcTwZGBDYz9TtvdpSX0ksDb+9vVniW0pdk++hhkj cMSDZ8VzBYP0ho/z8kJZhkxnmFEa+HN4Hydx6OCW+rgSrbVT9BYN+DSi3JkUpvDf WJvYAgktmQVP2RR9Y4A3 =l4RB -----END PGP SIGNATURE----- --Ttjej5l4m4nD1WTs1rRkedsRQKseiKvi8-- From nobody Tue Mar 27 10:35:42 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBFB12D953 for ; Tue, 27 Mar 2018 10:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 pv6IT4cnE9ja for ; Tue, 27 Mar 2018 10:35:39 -0700 (PDT) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (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 33D2812D887 for ; Tue, 27 Mar 2018 10:35:39 -0700 (PDT) Received: by mail-ot0-x231.google.com with SMTP id o9-v6so7389942otj.5 for ; Tue, 27 Mar 2018 10:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Tuj/p4epO2sa8mzdr/CESW5tpI62OODkW5Anb1VjXYU=; b=qAwm3PYxmYvdfFCviddycBg/LLAtHHn2jtdGeG/3XjTo/61jGdj1Z2K1dnFJrLObg7 jkjzovpGEvKcRAVOg9NJE4ERDOZUjC2dhaEJb0TyYhZOQc6+VG/P9nVJDBUVSBgKi5Zg C6gLrq/PAVRPGTCSN9E9PkAzfdC19N1tE4Wwy4iHQQikfRCa50CgxWURVuS6cI8PcPRT jKNWzXLhYYnEazhUi3lLLbvl2lzIQX09g74n6Uv3OXJk9aEj7esR4b/AlhHLhal1LEBG UWIaEbwToc8b2rn9q4vd8EPixt9OsmVkWlLHps03Hz+2KYN4NdlPqYR8K/qnG7dOnWfF SFWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Tuj/p4epO2sa8mzdr/CESW5tpI62OODkW5Anb1VjXYU=; b=SRgvASwK6/B8ecMw4Gr+oo3Q+sKlcX48Xvej3mlqEOV8GT7CkMCUqpjty6+hidPkOy 7PEjQkrvZOA7pneYWKNXhAuSk7kU6hys3skII9oCDKoPVZgSx3BrIglxx6RN/QF/CTjk GKSlvtoWpdnQjVmM+TCjytAlp7jCt5EZPKbrvaBAcYLyhFl0pZGqc7sA2qacEKceWEpD 0Vi+YmFWrFqmyvvRd2ZvGsfBnSxoEt6C9uRznlBcypDi/Onyd/zXkBs/qiI8y091exmh iF2I5lrT3r3bqZ+GSDSkVaUNAk/ONnsQKdcCYQlYUOoW0gRmNLiWxG0K9SQSsjogucM/ Nb5A== X-Gm-Message-State: AElRT7GEXVVPdqjLj6WD5aICezRYBNT/I6sHIXGwkFBqcTcryB64PfkI Yz1XTd8OzAEhgdV5Rb2RyjiHBUPOmws4qkjTTPo= X-Google-Smtp-Source: AIpwx48Vw3/YGfuuuQGkz9v4m2xcTEbcTd/t16VG1fFSbJVHFlwcKfPlWlLTPAIyLJByLnrW0B0Jr1rwoy7BmO5smqQ= X-Received: by 2002:a9d:fa1:: with SMTP id d30-v6mr177200otd.18.1522172138161; Tue, 27 Mar 2018 10:35:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.7.27 with HTTP; Tue, 27 Mar 2018 10:35:07 -0700 (PDT) In-Reply-To: <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca> References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca> From: Ted Hardie Date: Tue, 27 Mar 2018 10:35:07 -0700 Message-ID: To: Cullen Jennings Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000950ca405686851f3" Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 17:35:41 -0000 --000000000000950ca405686851f3 Content-Type: text/plain; charset="UTF-8" Question as chair: On Tue, Mar 27, 2018 at 9:57 AM, Cullen Jennings wrote: > > There are several people who's opinion I deeply respect that have looked > at this problem in detail. They somewhat agree the above is a problem, but > they argue it is better than any alternative design. I disagree with > this.The root of the problem we are trying to solve with this draft is that > some VPNs are configured to send some packets over the VPN while at the > same time some other packets are not sent over the VPN. If you use a VPN > configured like this to try and hide your location, WebRTC can end up > sending packets not over the VPN and that can reveal your location. I think > the right solution to this problem is to acknowledge this is a VPN problem, > not a WebRTC problem. If you are using a VPN to hide your location, do not > allow that VPN to send packets outside the VPN. I will note most VPNs > support this. > > The document's current description of this problem is: If the client is multihomed, additional public IP addresses for the client can be learned. In particular, if the client tries to hide its physical location through a Virtual Private Network (VPN), and the VPN and local OS support routing over multiple interfaces (a "split-tunnel" VPN), WebRTC will discover not only the public address for the VPN, but also the ISP public address over which the VPN is running. Would adding a statement such as "Users desiring maximum privacy should avoid split-tunnel configurations when they are in control of that configuration" help? Ted --000000000000950ca405686851f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Question as chair:

=
On Tue, Mar 27, 2018 at 9:57 AM, Cullen Jennings= <f= luffy@iii.ca> wrote:

There are several people who's opinion I deeply respect that have looke= d at this problem in detail. They somewhat agree the above is a problem, bu= t they argue it is better than any alternative design. I disagree with this= .The root of the problem we are trying to solve with this draft is that som= e VPNs are configured to send some packets over the VPN while at the same t= ime some other packets are not sent over the VPN. If you use a VPN configur= ed like this to try and hide your location, WebRTC can end up sending packe= ts not over the VPN and that can reveal your location. I think the right so= lution to this problem is to acknowledge this is a VPN problem, not a WebRT= C problem. If you are using a VPN to hide your location, do not allow that = VPN to send packets outside the VPN. I will note most VPNs support this.

The document's current descriptio= n of this problem is:

       If the client is multihomed, addit=
ional public IP addresses for
       the client can be learned.  In particular, if the client tries to
       hide its physical location through a Virtual Private Network
       (VPN), and the VPN and local OS support routing over multiple
       interfaces (a "split-tunnel" VPN), WebRTC will discover no=
t only
       the public address for the VPN, but also the ISP public address
       over which the VPN is running.
Would adding a statement such as "Users desiring maximum privacy= should avoid split-tunnel configurations when they are in control of that = configuration" help?=C2=A0

Ted
--000000000000950ca405686851f3-- From nobody Tue Mar 27 10:54:48 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA97127342 for ; Tue, 27 Mar 2018 10:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 SbsWGTLaSswB for ; Tue, 27 Mar 2018 10:54:41 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 75E0A126CBF for ; Tue, 27 Mar 2018 10:54:41 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w2RHsbCn042956 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 27 Mar 2018 12:54:38 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Ted Hardie , Cullen Jennings Cc: RTCWeb IETF References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca> From: Adam Roach Message-ID: <42c65dcc-2238-cbd0-84a7-b0509904b829@nostrum.com> Date: Tue, 27 Mar 2018 12:54:32 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------655E3534473E3D86297DDE8E" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 17:54:43 -0000 This is a multi-part message in MIME format. --------------655E3534473E3D86297DDE8E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit [as an individual] On 3/27/18 12:35 PM, Ted Hardie wrote: > > The document's current description of this problem is: > > If the client is multihomed, additional public IP addresses for > the client can be learned. In particular, if the client tries to > hide its physical location through a Virtual Private Network > (VPN), and the VPN and local OS support routing over multiple > interfaces (a "split-tunnel" VPN), WebRTC will discover not only > the public address for the VPN, but also the ISP public address > over which the VPN is running. > Would adding a statement such as "Users desiring maximum privacy > should avoid split-tunnel configurations when they are in control of > that configuration" help? I think the value of adding *application* *user* guidance to an RFC is of questionable value under pretty much all circumstances, fully analogous to adding "safe driving" tips to ASTM's automotive standards. I wouldn't spend too much time wordsmithing words that will never reach their intended audience. /a --------------655E3534473E3D86297DDE8E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
[as an individual]

On 3/27/18 12:35 PM, Ted Hardie wrote:

The document's current description of this problem is:

       If the client is multihomed, additional public IP addresses for
       the client can be learned.  In particular, if the client tries to
       hide its physical location through a Virtual Private Network
       (VPN), and the VPN and local OS support routing over multiple
       interfaces (a "split-tunnel" VPN), WebRTC will discover not only
       the public address for the VPN, but also the ISP public address
       over which the VPN is running.
Would adding a statement such as "Users desiring maximum privacy should avoid split-tunnel configurations when they are in control of that configuration" help? 

I think the value of adding *application* *user* guidance to an RFC is of questionable value under pretty much all circumstances, fully analogous to adding "safe driving" tips to ASTM's automotive standards. I wouldn't spend too much time wordsmithing words that will never reach their intended audience.

/a
--------------655E3534473E3D86297DDE8E-- From nobody Tue Mar 27 11:18:27 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410E712D77C for ; Tue, 27 Mar 2018 11:18:25 -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, HTML_MESSAGE=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 8-NB0zE-Iqdq for ; Tue, 27 Mar 2018 11:18:22 -0700 (PDT) Received: from smtp65.iad3a.emailsrvr.com (smtp65.iad3a.emailsrvr.com [173.203.187.65]) (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 4083612778E for ; Tue, 27 Mar 2018 11:18:22 -0700 (PDT) Received: from smtp33.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp33.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id AE9DF5819; Tue, 27 Mar 2018 14:18:15 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp33.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 44BA157FF; Tue, 27 Mar 2018 14:18:15 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Tue, 27 Mar 2018 14:18:15 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_B8CE01B8-052A-4E95-A2AB-E99D85818E11" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Cullen Jennings In-Reply-To: Date: Tue, 27 Mar 2018 12:18:13 -0600 Cc: RTCWeb IETF Message-Id: <6595CE27-B2FD-4F3A-B0ED-9992C49E1A4B@iii.ca> References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca> To: Ted Hardie X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 18:18:25 -0000 --Apple-Mail=_B8CE01B8-052A-4E95-A2AB-E99D85818E11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 27, 2018, at 11:35 AM, Ted Hardie wrote: >=20 > Question as chair: >=20 > On Tue, Mar 27, 2018 at 9:57 AM, Cullen Jennings > wrote: >=20 > There are several people who's opinion I deeply respect that have = looked at this problem in detail. They somewhat agree the above is a = problem, but they argue it is better than any alternative design. I = disagree with this.The root of the problem we are trying to solve with = this draft is that some VPNs are configured to send some packets over = the VPN while at the same time some other packets are not sent over the = VPN. If you use a VPN configured like this to try and hide your = location, WebRTC can end up sending packets not over the VPN and that = can reveal your location. I think the right solution to this problem is = to acknowledge this is a VPN problem, not a WebRTC problem. If you are = using a VPN to hide your location, do not allow that VPN to send packets = outside the VPN. I will note most VPNs support this. >=20 >=20 > The document's current description of this problem is: >=20 > If the client is multihomed, additional public IP addresses for > the client can be learned. In particular, if the client tries = to > hide its physical location through a Virtual Private Network > (VPN), and the VPN and local OS support routing over multiple > interfaces (a "split-tunnel" VPN), WebRTC will discover not = only > the public address for the VPN, but also the ISP public address > over which the VPN is running. > Would adding a statement such as "Users desiring maximum privacy = should avoid split-tunnel configurations when they are in control of = that configuration" help? =20 >=20 > Ted I think proposal along those lines had been rejected in the past by WG. = The problem is we get in arguments about if it should say something like = your suggestions or something more like =E2=80=9CUsers desiring location = privacy must not use split-tunnel VPN configurations with WebRTC=E2=80=9D.= As you know, this is not a case of just noticing something new in WGLC, = this problem and argument has been considered by the WG and I think = Stephen and I are in the rough.=20 I do appreciate you trying to find some middle ground here --Apple-Mail=_B8CE01B8-052A-4E95-A2AB-E99D85818E11 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 27, 2018, at 11:35 AM, Ted Hardie <ted.ietf@gmail.com> = wrote:

Question as chair:

On Tue, Mar 27, 2018 at 9:57 AM, Cullen Jennings = <fluffy@iii.ca> wrote:

There are several people who's opinion I deeply respect that have looked = at this problem in detail. They somewhat agree the above is a problem, = but they argue it is better than any alternative design. I disagree with = this.The root of the problem we are trying to solve with this draft is = that some VPNs are configured to send some packets over the VPN while at = the same time some other packets are not sent over the VPN. If you use a = VPN configured like this to try and hide your location, WebRTC can end = up sending packets not over the VPN and that can reveal your location. I = think the right solution to this problem is to acknowledge this is a VPN = problem, not a WebRTC problem. If you are using a VPN to hide your = location, do not allow that VPN to send packets outside the VPN. I will = note most VPNs support this.


The document's current description of this problem is:

       If the client is =
multihomed, additional public IP addresses for
       the client can be learned.  In particular, if the client tries to
       hide its physical location through a Virtual Private Network
       (VPN), and the VPN and local OS support routing over multiple
       interfaces (a "split-tunnel" VPN), WebRTC will discover not only
       the public address for the VPN, but also the ISP public address
       over which the VPN is running.
Would adding a statement such as "Users desiring maximum privacy = should avoid split-tunnel configurations when they are in control of = that configuration" help? 

Ted

I think proposal = along those lines had been rejected in the past by WG. The problem is we = get in arguments about if it should say something like your suggestions = or something more like =E2=80=9CUsers desiring location privacy must not = use split-tunnel VPN configurations with WebRTC=E2=80=9D. As you know, = this is not a case of just noticing something new in WGLC, this problem = and argument has been considered by the WG and I think Stephen and I are = in the rough. 

I do appreciate you trying to find some middle ground = here


= --Apple-Mail=_B8CE01B8-052A-4E95-A2AB-E99D85818E11-- From nobody Tue Mar 27 18:50:09 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEC7126BF7 for ; Tue, 27 Mar 2018 18:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 iRZrP9WXJLgb for ; Tue, 27 Mar 2018 18:50:06 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (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 9AE94120724 for ; Tue, 27 Mar 2018 18:50:06 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id m13so684093wrj.5 for ; Tue, 27 Mar 2018 18:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:openpgp:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=9Jz8qAA8Y4Gx1MR/HcTDVQEikPgQwf/NA1K0d0Nx1mQ=; b=S5AnUXt4y5cCO2SshY2i5PrFv0LTt+V/vUUSusBFnisqshuULJ1gji7erOWq1uyB9z +I+XICH5cJPKAliJ561ilXc74SHseFC3o1kALO+CM07kJvtBvWKf3AOHyRDWE538QomP 1jRNRN8uAFS1KwyKyRmIfMVdeKWcjDZERWxBQWJ6lMjWjE474IRyP1hh+6IHPSYwel6b ICS6hJxPgdDSs4pYU7RkSy6VCcy64+UYAHDAEZOb1Ru0LgD5KxSQSDC7kwvxqaOjeN51 R08LNinaRRtSxORUjNzrP13WMjP2VHtH98inp4S3a0DnvwOBEfvhU2e5OfVcZEpUWKXZ fULw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9Jz8qAA8Y4Gx1MR/HcTDVQEikPgQwf/NA1K0d0Nx1mQ=; b=tkDGcUnkw0MpV7dLPX2zpL6n/HbTrX7nUsYCOHhoi+vKGdYXurE06uANKDh1TwjI7E ZR/q2Qq5jxzAYGoU4toNPBB3gdzWZk9w8K2SJPESRCDNBWwShpwbG2Vvwatd6srh2Sgu 6kubSCuY6XOc489s9robvz+TvfToS/bE3iyemSWj94gGs1lU3cQJaxlcyVzlkk6qxZ2t cu0jnaHeqx/CCwduh9Whw6M6h7EOnZ2gLDMVIgCJLIePkP6ZbFfWanbXfqaas0KajAaA rt59q2uyXI/JEwM7eSDUhB+dhsONmhJ5764eraRFAC6xHyqZ+tNcZMvy6XCPRUpZQFHD L57Q== X-Gm-Message-State: AElRT7EEOh7CRNStdvhdVmSpWvnYZIxxv6nlM8KD/JGIQgAvNffZXfbp E0paBGC1SMedMrV96+C3Gt/MD7wC X-Google-Smtp-Source: AIpwx4+zBBYMS0RaSm6SYe2380/XpiuT4GlvUFeGbYM9ldHg19vU2NdEkVeIhxPYbraJt+GIyOK/XA== X-Received: by 10.223.157.3 with SMTP id k3mr1254872wre.179.1522201805128; Tue, 27 Mar 2018 18:50:05 -0700 (PDT) Received: from ?IPv6:2003:cd:6bc2:9a00:f042:6c27:8554:c13b? (p200300CD6BC29A00F0426C278554C13B.dip0.t-ipconnect.de. [2003:cd:6bc2:9a00:f042:6c27:8554:c13b]) by smtp.gmail.com with ESMTPSA id m62sm3674504wmi.19.2018.03.27.18.49.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Mar 2018 18:50:04 -0700 (PDT) To: rtcweb@ietf.org References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca> From: Lennart Grahl Openpgp: preference=signencrypt Message-ID: Date: Wed, 28 Mar 2018 03:49:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 01:50:08 -0000 T24gMjcuMDMuMjAxOCAxODo1NywgQ3VsbGVuIEplbm5pbmdzIHdyb3RlOg0KPiBUaGlzIGRy YWZ0IHJlc3VsdHMgaW4gdGhlIHNpdHVhdGlvbiB3aGVyZSBpbXBsZW1lbnRhdGlvbnMgZGVj aWRlIGlmIHRoZXkgc2hvdWxkIHJldmVhbCB0aGUgdXNlcnMgbG9jYXRpb24gdG8gdGhlIHdl YnNpdGUgYnkgYXNraW5nIGEgcXVlc3Rpb25zIG9mIHRoZSBmb3JtICJXaWxsIHlvdSBhbGxv dyBleGFtcGxlLmNvbSB0byB1c2UgeW91ciBjYW1lcmE/IiBJZiB0aGUgdXNlciBzYXlzIHRo YXQgaXMgT0sgdG8gdXNlIHRoZWlyIGNhbWVyYSwgaW4gbWFueSBjYXNlcyB0aGV5IGhhdmUg YWxzbyBhbGxvd2VkIHRoZSB3ZWJzaXRlIHRvIGdldCB0aGVpciBsb2NhdGlvbiB2aWEgdGhl IElQIGFkZHJlc3MuIEZyb20gYSB1c2VyIHBvaW50IG9mIHZpZXcsIEkgdGhpbmsgdGhpcyBp cyBhd2Z1bCwgVGhlcmUgYXJlIG1hbnkgcmVhc29ucyBJIG1pZ2h0IGFsbG93IGEgd2Vic2l0 ZSBJIGRvIG5vdCB0cnVzdCB0byBrbm93IG15IGxvY2F0aW9uIHRvIGFjY2VzcyBteSBjYW1l cmEgLSBmb3IgZXhhbXBsZSwgSSBoYXZlIGEgYmxhY2sgY292ZXIgb3ZlciBteSBjYW1lcmEg YW5kIHRoZSB3ZWJzaXRlIHdvbid0IHdvcmsgdW5sZXNzIEkgc2F5IHllcyB0byB0aGlzIHJl cXVlc3QuIE9yIGEgd2ViY2FtIHdvcmtlciB3aGVyZSB0aGUgam9iIGludm9sdmVzIHJldmVh bGluZyB2aWRlbyBidXQgcmV2ZWFsaW5nIHRoZSBsb2NhdGlvbnMgdGhleSB3b3JrIGF0IG1h eSBwdXQgdGhlbSBhdCByaXNrIG9mIHNlcmlvdXMgaGFybS4gT3IgSSBhbSBpbiBhIGRvbWVz dGljIGFidXNlIHNoZWx0ZXIgYW5kIHdhbnQgdG8gaGF2ZSBhIGNhbGwgYnV0IHJldmVhbGlu ZyBtYXkgbG9jYXRpb24gcHV0cyBtZSBhdCByaXNrIG9mIHBoeXNpY2FsIGhhcm0uIEkgZG8g bm90IHRoaW5rIHRoZSBJRVRGIHNob3VsZCBpbiBhbnkgd2F5IGVuZG9yc2UgdGhpcyBleHRy ZW1lbHkgbWlzbGVhZGluZyBmb3JtIG9mIGNvbnNlbnQuIEl0IGlzIHNpbXBseSBub3QgY29u c2VudC4gSSByZWFsaXplIHRoaXMgd291bGQgYmUgZ29vZCBmb3IgY29tcGFuaWVzIHRoYXQg YXJlIHByaW1hcnkgZnVuZGVkIGJ5IGJ5IHdlYiBhZHZlcnRpc2luZyBmb3Igd2hpY2ggbG9j YXRpb24gaXMgdmFsdWFibGUuDQoNCkkgYWdyZWUgd2l0aCB5b3UgaGVyZSBhbmQgdGhpcyBp cyBtb3N0IGxpa2VseSB0aGUgcmVhc29uIHdoeSBXZWJSVEMgaXMNCm9uIHRoZSBibGFja2xp c3Qgb2YgbWFueSBwcml2YWN5IGV4dGVuc2lvbnMgZm9yIGJyb3dzZXJzLg0KDQpIb3dldmVy LCBJIGJlbGlldmUgdGhlcmUgY291bGQgYmUgYSBmb3JtIG9mIGNvbnNlbnQgaW4gdGhlIGJy b3dzZXJzIC0NCnRlbGwgdGhlbSB3aGF0IHlvdSBhY3R1YWxseSB3YW50IHRvIGRvOiBFeHBv c2UgKGFsbCkgcHJpdmF0ZSBJUA0KYWRkcmVzc2VzIHRvIGNyZWF0ZSBhIGRpcmVjdCBjb25u ZWN0aW9uLiBZZXMsIGdldHRpbmcgdXNlcnMgdG8NCnVuZGVyc3RhbmQgd2hhdCBpdCBtZWFu cyB0byAiZXN0YWJsaXNoIGEgZGlyZWN0IGNvbm5lY3Rpb24iIG1heSBub3QgYmUNCnRyaXZp YWwgLSBncmFudGVkLiBCdXQgaXQncyBtdWNoIG1vcmUgc2luY2VyZSBBTkQgaXQgd291bGQg bm90DQpkaXNjcmltaW5hdGUgZGF0YSBjaGFubmVsIG9ubHkgdXNlIGNhc2VzICh5ZWFoLCBp dCdzIHJlYWxseSBzaGFkeSB0bw0KcmVxdWVzdCBjYXB0dXJlIHBlcm1pc3Npb25zIHRvIGJl IGFibGUgdG8gdXNlIG1vZGUgMSkuDQoNCkFuZCBGV0lXIEknbSBub3Qgc3VyZSB0aGlzIGZv cm0gb2YgY29uc2VudCBmaXRzIGludG8gdGhlIHNjb3BlIG9mIHRoZQ0KSUVURi4gTWF5YmUg dGhlIG1vZGVzIGNvdWxkIGJlIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBhbmQgd2hpY2gg bW9kZQ0KdG8gY2hvb3NlIHVuZGVyIHdoaWNoIGNpcmN1bXN0YW5jZXMgY291bGQgYmUgbW92 ZWQgaW50byB0aGUgVzNDIFdlYlJUQyBzcGVjLg0KDQpDaGVlcnMNCkxlbm5hcnQNCg== From nobody Tue Mar 27 18:53:55 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3C6126BF7 for ; Tue, 27 Mar 2018 18:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, TVD_SPACE_RATIO=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 Ylq48ClAG6id for ; Tue, 27 Mar 2018 18:53:50 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 B39F9120724 for ; Tue, 27 Mar 2018 18:53:50 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id w2S1jDdj010528 for ; Tue, 27 Mar 2018 21:53:49 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 2gywxs3pcq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 27 Mar 2018 21:53:49 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w2S1rmf4014342 for ; Tue, 27 Mar 2018 21:53:49 -0400 Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [135.66.87.52]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w2S1riMV014284 for ; Tue, 27 Mar 2018 21:53:45 -0400 Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [127.0.0.1]) by zlp27125.vci.att.com (Service) with ESMTP id 5465B167F70 for ; Wed, 28 Mar 2018 01:53:44 +0000 (GMT) Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (unknown [130.9.129.147]) by zlp27125.vci.att.com (Service) with ESMTPS id 3B0C7167F68 for ; Wed, 28 Mar 2018 01:53:44 +0000 (GMT) Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.209]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0361.001; Tue, 27 Mar 2018 21:53:44 -0400 From: "HANSEN, TONY L" To: "rtcweb@ietf.org" Thread-Topic: subscribe Thread-Index: AQHTxjeZVtYH3BXqNkmKUL7HaMx8cw== Date: Wed, 28 Mar 2018 01:53:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.210.5.18] Content-Type: multipart/alternative; boundary="_000_B9D27453C07848B8BE74810E8E9CF782attcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-27_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=415 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803280015 Archived-At: Subject: [rtcweb] subscribe X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 01:53:53 -0000 --_000_B9D27453C07848B8BE74810E8E9CF782attcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 c3Vic2NyaWJlDQo= --_000_B9D27453C07848B8BE74810E8E9CF782attcom_ Content-Type: text/html; charset="utf-8" Content-ID: <586CFE5423D44A4E88453E994D47BB72@LOCAL> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5zdWJzY3JpYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_B9D27453C07848B8BE74810E8E9CF782attcom_-- From nobody Wed Mar 28 07:15:02 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4919912711E for ; Wed, 28 Mar 2018 07:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 0uaZ5a-KML2h for ; Wed, 28 Mar 2018 07:14:58 -0700 (PDT) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (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 1FC7F12711B for ; Wed, 28 Mar 2018 07:14:57 -0700 (PDT) Received: (qmail 23257 invoked from network); 28 Mar 2018 14:14:55 -0000 X-APM-Authkey: 255286/0(159927/0) 1465 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 28 Mar 2018 14:14:55 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 91E4118A029F; Wed, 28 Mar 2018 15:14:55 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jk5DPsJFRxYO; Wed, 28 Mar 2018 15:14:55 +0100 (BST) Received: from [192.67.4.84] (unknown [192.67.4.84]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 6D2D218A016C; Wed, 28 Mar 2018 15:14:55 +0100 (BST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: westhawk In-Reply-To: <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca> Date: Wed, 28 Mar 2018 15:14:54 +0100 Cc: RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca> To: Cullen Jennings X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 14:15:01 -0000 I tend to agree with Cullen here, this is an issue. (As I said when I = first raised it way back when). It is bad practice to ask a user one (clear) question and the deduce their agreement to some other things that aren=E2=80=99t (at least to = the user) related. Conversely an infinite series of questions before each call isn=E2=80=99t = going to work either, With that in mind, perhaps we are hanging off the wrong existing = consent. Given that the VPN users in question are (in practice) trying to hide = their location, perhaps that=E2=80=99s the dialog we should hang off instead. =E2=80=9CThis page would like to use your location: allow, deny=E2=80=9D would also unlock public IP address access. Tim. > On 27 Mar 2018, at 17:57, Cullen Jennings wrote: >=20 > Theses comments are sent as an individual contributor.=20 >=20 > Let me start by saying I think I am in the rough on the consensus of = this draft and I expect the draft to be sent to the IESG with no = changes. For the record, as I have said at the floor microphone in the = past, I don't agree with the draft.=20 >=20 > This draft results in the situation where implementations decide if = they should reveal the users location to the website by asking a = questions of the form "Will you allow example.com to use your camera?" = If the user says that is OK to use their camera, in many cases they have = also allowed the website to get their location via the IP address. =46rom = a user point of view, I think this is awful, There are many reasons I = might allow a website I do not trust to know my location to access my = camera - for example, I have a black cover over my camera and the = website won't work unless I say yes to this request. Or a webcam worker = where the job involves revealing video but revealing the locations they = work at may put them at risk of serious harm. Or I am in a domestic = abuse shelter and want to have a call but revealing may location puts me = at risk of physical harm. I do not think the IETF should in any way = endorse this extremely misleading form of consent. It is simply not = consent. I realize this would be good for companies that are primary = funded by by web advertising for which location is valuable. >=20 > There are several people who's opinion I deeply respect that have = looked at this problem in detail. They somewhat agree the above is a = problem, but they argue it is better than any alternative design. I = disagree with this.The root of the problem we are trying to solve with = this draft is that some VPNs are configured to send some packets over = the VPN while at the same time some other packets are not sent over the = VPN. If you use a VPN configured like this to try and hide your = location, WebRTC can end up sending packets not over the VPN and that = can reveal your location. I think the right solution to this problem is = to acknowledge this is a VPN problem, not a WebRTC problem. If you are = using a VPN to hide your location, do not allow that VPN to send packets = outside the VPN. I will note most VPNs support this.=20 >=20 > John Morris words from [1], more or less sum up about how I feel about = this - just reverse W3C and IETF. >=20 > "By not actually building privacy into the specification, the W3C = has =20 > both missed a significant opportunity to improve user privacy on = the =20 > Web, and it has harmed the efforts of another standards body -- the = =20 > IETF -- to protect location privacy and to improve the privacy =20 > paradigm for Internet services." >=20 > =46rom a process point of view: 1) I have had time to express this = opinion in the rtcweb WG meetings and it has been discussed. My read of = the consensus in the room is that I am in the rough on this topic 2) I = don't think the rtcweb WG is the WG in the IETF with the most expertise = in VPNs >=20 > Thanks, Cullen >=20 >=20 > As FYI, the actual questions that are asked by today's browsers are = roughly the following: >=20 > In firefox: "Will you allow webrtc.github.io to use your camera?" >=20 > In chrome: "webrtc.github.io wants to use your camera" >=20 > In safari: "Allow webrtc.github.io to use your camera?" >=20 > In edge: "Let webrtc.github.io use your webcam?=E2=80=9D >=20 >=20 > [1] = https://lists.w3.org/Archives/Public/public-geolocation/2009Jul/0020.html >=20 >=20 >=20 >> On Mar 7, 2018, at 7:49 PM, Sean Turner wrote: >>=20 >> All, >>=20 >> This is the WGLC for the "WebRTC IP Address Handling Requirements=E2=80= =9D draft available @ = https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/. Please = review the draft and send your comments to this list by 2359UTC on 30 = March 30 2017. >>=20 >> Thanks, >> C/T/S >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Mar 28 11:37:20 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0271271DF for ; Wed, 28 Mar 2018 11:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 z8eJch0TR4pf for ; Wed, 28 Mar 2018 11:37:15 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FFD01201F2 for ; Wed, 28 Mar 2018 11:37:14 -0700 (PDT) Received: from [192.168.1.230] ([84.20.98.117]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id w2SIbLL2027974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 28 Mar 2018 20:37:23 +0200 To: rtcweb@ietf.org References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca> From: Philipp Hancke Message-ID: <5342f187-b600-576a-815b-fadbe7d95f80@goodadvice.pages.de> Date: Wed, 28 Mar 2018 20:37:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 18:37:18 -0000 Am 27.03.2018 um 18:57 schrieb Cullen Jennings: [...] > I disagree with this.The root of the problem we are trying to solve with this draft is that some VPNs are configured to send some packets over the VPN while at the same time some other packets are not sent over the VPN. If you use a VPN configured like this to try and hide your location, WebRTC can end up sending packets not over the VPN and that can reveal your location. Isn't the problem that some VPNs promise you to hide your location while actually operating in split mode? > I think the right solution to this problem is to acknowledge this is a VPN problem, not a WebRTC problem. If you are using a VPN to hide your location, do not allow that VPN to send packets outside the VPN. I will note most VPNs support this. I find it somewhat interesting that the narrative among "hide my location" VPN vendors is still "webrtc exposes you" and not "oh, you are using $competitors product? here is your real location. We can protect you for a modest fee". IIRC initially there was also an actual issue in Chrome where is leaked UDP candidates when a socks proxy was set (which is how tor operates). This was bad has been fixed pretty quickly. From nobody Wed Mar 28 21:39:50 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A393B126C0F for ; Wed, 28 Mar 2018 21:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzcWYPf9cJqv for ; Wed, 28 Mar 2018 21:39:44 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 2F798124B0A for ; Wed, 28 Mar 2018 21:39:44 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id v134so2676796vkd.10 for ; Wed, 28 Mar 2018 21:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X+pDQnn6IklJ+87bYBp0jVLh2NaYSh0D3jiJY/f7WIE=; b=enm9UMQQmbil+dy1/hOWMoeQSbq2LaQI0engVdZDyo/BNeU3EhssMghDFXSI0UZkf6 tgnL6a0YbVpHrFdFHK1ij85PR5qdKFKMmPd02rssOeud7gWlFcze36o5Ta+SuIhFwgvR n09YPxR5AfHxdEk1FNYpmtMyuNmCLcjbdFvONo9WxvdGDvkWK3y7ZpfTSMCMVtACfQDg zdp9LORzrDmoMrsYRcWJhBiMqwJBGT5dc54iP/g4EK/umVgX+3XLhRfOO8yXMhptvgdq /BeLWtxSPllaNMeUes85wYh+ldiWy2VDpz5WMkWcEVlKP98wCQYq3tYw0nktHVqvmaOy 4fXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=X+pDQnn6IklJ+87bYBp0jVLh2NaYSh0D3jiJY/f7WIE=; b=DXK5J2QG8XRXDali+ekn/nI+/LIAmibWF8YhjhZqtMJ0O6x1v9q4n7Jsm21dLr61m/ OXd33seffqvu2xP+lXCQWz72+6s3k9+VeUupFoAG5u4Apa1dTM+mczoUkfHsgLeI+E4+ H2wA6fyLl15pJEK+Go8fUHld115YOTIBqVxgh9P1d/Et0aykU/bw7X0V3t1xKfA8NvyX Bj7fQn4fieDf+1Cwi7dJ0O9Sj3RHoMLukmu9ZB+xZjGUT/QhAPnt6iRjQrnzT8Yd4Fb3 nE1pc62QzL5iQ8ks/3JbgyUMLR2RvYibBDtJfsWJclHEC1h4jFY6O44MPDQNrEcC/tOG 1zhg== X-Gm-Message-State: AElRT7HiVXq5OeAbyHYoqfhsmFfGvxDnW4z15ANye1OmMbnEoxG71ogk DOnsfqXk+MwsLxq4vB2SikZ/HWPynzHl0Z9ZOffigymb X-Google-Smtp-Source: AIpwx48R9aAZcaDhDwiNvsQze1nJIfRBOhVI7RtNL0J/upLkppx9x6gJMy1jyPGOKpTudiE2A8A/1HG8YjW3wtOj2d4= X-Received: by 10.31.223.129 with SMTP id w123mr4236181vkg.9.1522298382700; Wed, 28 Mar 2018 21:39:42 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca> In-Reply-To: From: Justin Uberti Date: Thu, 29 Mar 2018 04:39:32 +0000 Message-ID: To: Tim Panton Cc: Cullen Jennings , RTCWeb IETF Content-Type: multipart/alternative; boundary="94eb2c07dc90588095056885b6b9" Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2018 04:39:49 -0000 --94eb2c07dc90588095056885b6b9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Note that this VPN behavior is not unique to web browsers. Mobile applications are free to use whichever interface they prefer without needing any additional user permissions. On Wed, Mar 28, 2018 at 7:15 AM westhawk wrote: > I tend to agree with Cullen here, this is an issue. (As I said when I > first raised it way back when). > > It is bad practice to ask a user one (clear) question and the deduce > their agreement to some other things that aren=E2=80=99t (at least to the= user) > related. > > Conversely an infinite series of questions before each call isn=E2=80=99t= going to > work either, > > With that in mind, perhaps we are hanging off the wrong existing consent. > Given that the VPN users in question are (in practice) trying to hide > their location, > perhaps that=E2=80=99s the dialog we should hang off instead. > > =E2=80=9CThis page would like to use your location: allow, deny=E2=80=9D > would also unlock public IP address access. > > Tim. > > > > On 27 Mar 2018, at 17:57, Cullen Jennings wrote: > > > > Theses comments are sent as an individual contributor. > > > > Let me start by saying I think I am in the rough on the consensus of > this draft and I expect the draft to be sent to the IESG with no changes. > For the record, as I have said at the floor microphone in the past, I don= 't > agree with the draft. > > > > This draft results in the situation where implementations decide if the= y > should reveal the users location to the website by asking a questions of > the form "Will you allow example.com to use your camera?" If the user > says that is OK to use their camera, in many cases they have also allowed > the website to get their location via the IP address. From a user point o= f > view, I think this is awful, There are many reasons I might allow a websi= te > I do not trust to know my location to access my camera - for example, I > have a black cover over my camera and the website won't work unless I say > yes to this request. Or a webcam worker where the job involves revealing > video but revealing the locations they work at may put them at risk of > serious harm. Or I am in a domestic abuse shelter and want to have a call > but revealing may location puts me at risk of physical harm. I do not thi= nk > the IETF should in any way endorse this extremely misleading form of > consent. It is simply not consent. I realize this would be good for > companies that are primary funded by by web advertising for which locatio= n > is valuable. > > > > There are several people who's opinion I deeply respect that have looke= d > at this problem in detail. They somewhat agree the above is a problem, bu= t > they argue it is better than any alternative design. I disagree with > this.The root of the problem we are trying to solve with this draft is th= at > some VPNs are configured to send some packets over the VPN while at the > same time some other packets are not sent over the VPN. If you use a VPN > configured like this to try and hide your location, WebRTC can end up > sending packets not over the VPN and that can reveal your location. I thi= nk > the right solution to this problem is to acknowledge this is a VPN proble= m, > not a WebRTC problem. If you are using a VPN to hide your location, do no= t > allow that VPN to send packets outside the VPN. I will note most VPNs > support this. > > > > John Morris words from [1], more or less sum up about how I feel about > this - just reverse W3C and IETF. > > > > "By not actually building privacy into the specification, the W3C ha= s > > both missed a significant opportunity to improve user privacy on the > > Web, and it has harmed the efforts of another standards body -- the > > IETF -- to protect location privacy and to improve the privacy > > paradigm for Internet services." > > > > From a process point of view: 1) I have had time to express this opinio= n > in the rtcweb WG meetings and it has been discussed. My read of the > consensus in the room is that I am in the rough on this topic 2) I don't > think the rtcweb WG is the WG in the IETF with the most expertise in VPNs > > > > Thanks, Cullen > > > > > > As FYI, the actual questions that are asked by today's browsers are > roughly the following: > > > > In firefox: "Will you allow webrtc.github.io to use your camera?" > > > > In chrome: "webrtc.github.io wants to use your camera" > > > > In safari: "Allow webrtc.github.io to use your camera?" > > > > In edge: "Let webrtc.github.io use your webcam?=E2=80=9D > > > > > > [1] > https://lists.w3.org/Archives/Public/public-geolocation/2009Jul/0020.html > > > > > > > >> On Mar 7, 2018, at 7:49 PM, Sean Turner wrote: > >> > >> All, > >> > >> This is the WGLC for the "WebRTC IP Address Handling Requirements=E2= =80=9D > draft available @ > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/. Please > review the draft and send your comments to this list by 2359UTC on 30 Mar= ch > 30 2017. > >> > >> Thanks, > >> C/T/S > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --94eb2c07dc90588095056885b6b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Note that this VPN behavior is not unique to web browsers.= Mobile applications are free to use whichever interface they prefer withou= t needing any additional user permissions.


On Wed, Mar 28, 2018 at 7:15 AM westhawk <thp@westhawk.co.uk> wrote:
I tend to agree with Cullen here, this is a= n issue. (As I said when I first raised it way back when).

It is bad practice to ask a user one (clear) question and the deduce
their agreement to some other things that aren=E2=80=99t (at least to the u= ser) related.

Conversely an infinite series of questions before each call isn=E2=80=99t g= oing to
work either,

With that in mind, perhaps we are hanging off the wrong existing consent. Given that the VPN users in question are (in practice) trying to hide their= location,
perhaps that=E2=80=99s the dialog we should hang off instead.

=E2=80=9CThis page would like to use your location: allow, deny=E2=80=9D would also unlock public IP address access.

Tim.


> On 27 Mar 2018, at 17:57, Cullen Jennings <fluffy@iii.ca> wrote:
>
> Theses comments are sent as an individual contributor.
>
> Let me start by saying I think I am in the rough on the consensus of t= his draft and I expect the draft to be sent to the IESG with no changes. Fo= r the record, as I have said at the floor microphone in the past, I don'= ;t agree with the draft.
>
> This draft results in the situation where implementations decide if th= ey should reveal the users location to the website by asking a questions of= the form "Will you allow example.com to use your camera?" If the us= er says that is OK to use their camera, in many cases they have also allowe= d the website to get their location via the IP address. From a user point o= f view, I think this is awful, There are many reasons I might allow a websi= te I do not trust to know my location to access my camera - for example, I = have a black cover over my camera and the website won't work unless I s= ay yes to this request. Or a webcam worker where the job involves revealing= video but revealing the locations they work at may put them at risk of ser= ious harm. Or I am in a domestic abuse shelter and want to have a call but = revealing may location puts me at risk of physical harm. I do not think the= IETF should in any way endorse this extremely misleading form of consent. = It is simply not consent. I realize this would be good for companies that a= re primary funded by by web advertising for which location is valuable.
>
> There are several people who's opinion I deeply respect that have = looked at this problem in detail. They somewhat agree the above is a proble= m, but they argue it is better than any alternative design. I disagree with= this.The root of the problem we are trying to solve with this draft is tha= t some VPNs are configured to send some packets over the VPN while at the s= ame time some other packets are not sent over the VPN. If you use a VPN con= figured like this to try and hide your location, WebRTC can end up sending = packets not over the VPN and that can reveal your location. I think the rig= ht solution to this problem is to acknowledge this is a VPN problem, not a = WebRTC problem. If you are using a VPN to hide your location, do not allow = that VPN to send packets outside the VPN. I will note most VPNs support thi= s.
>
> John Morris words from [1], more or less sum up about how I feel about= this - just reverse W3C and IETF.
>
>=C2=A0 =C2=A0 "By not actually building privacy into the specifica= tion, the W3C has
>=C2=A0 =C2=A0 both missed a significant opportunity to improve user pri= vacy on the
>=C2=A0 =C2=A0 Web, and it has harmed the efforts of another standards b= ody -- the
>=C2=A0 =C2=A0 IETF -- to protect location privacy and to improve the pr= ivacy
>=C2=A0 =C2=A0 paradigm for Internet services."
>
> From a process point of view: 1) I have had time to express this opini= on in the rtcweb WG meetings and it has been discussed. My read of the cons= ensus in the room is that I am in the rough on this topic=C2=A0 2) I don= 9;t think the rtcweb WG is the WG in the IETF with the most expertise in VP= Ns
>
> Thanks, Cullen
>
>
> As FYI, the actual questions that are asked by today's browsers ar= e roughly the following:
>
> In firefox: "Will you allow webrtc.github.io to use your camera= ?"
>
> In chrome: "webrtc.github.io wants to use your camera"
>
> In safari: "Allow webrtc.github.io to use your camera?" >
> In edge: "Let webrtc.github.io use your webcam?=E2=80=9D
>
>
> [1] https://lists.w3.o= rg/Archives/Public/public-geolocation/2009Jul/0020.html
>
>
>
>> On Mar 7, 2018, at 7:49 PM, Sean Turner <sean@sn3rd.com> wrote:
>>
>> All,
>>
>> This is the WGLC for the "WebRTC IP Address Handling Requirem= ents=E2=80=9D draft available @ https= ://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/.=C2=A0 Pleas= e review the draft and send your comments to this list by 2359UTC on 30 Mar= ch 30 2017.
>>
>> Thanks,
>> C/T/S
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--94eb2c07dc90588095056885b6b9-- From nobody Thu Mar 29 01:30:00 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B21F12708C for ; Thu, 29 Mar 2018 01:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 HWSxkFzIe43c for ; Thu, 29 Mar 2018 01:29:56 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 56B3D1241F3 for ; Thu, 29 Mar 2018 01:29:56 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id o23so17485534wmf.0 for ; Thu, 29 Mar 2018 01:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nDb2wtDkNIQp3VSdXDgvq+tMuId6Mpzqc68gz/I9s4o=; b=Hermms16+lyg+5NYuuQ4xU9Jy9onWpyMwTMof5E3WkJuuv/npv9AZ/C+nQzzUInofc CNClBnwH0mSi0XGrpH7PzCZzriJwRyZPEE0VvBNMhKlicyxvpRApcehD4Qj3X9YK0gK4 O9BYQjS4eZRQGldj7xiPS1a+nU5Nlx7/p9s+rA5JFxpAXcFUir7WpJqavhGYMNYRNAGa 8r1QbVpJjiJO6AcU7TTV0o9DABMsJzHttskOHh5e6JNXgOVZdKkpO5AoteTP8A7hM5L1 YyKOyuxxIUCZroGks+J11XrsZM4WoFchfoRLeksbdw316PMmrhf0PyOYT+no14zJgwCh 9rEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nDb2wtDkNIQp3VSdXDgvq+tMuId6Mpzqc68gz/I9s4o=; b=pRG0u2JVCVYt5A0IprF5595gWzkJUsi2NAjYvAqJQEg/2BGc0ZNSNCPpiLStBZVPHu yfyI4WXF8ksNks5Bc4qr4w+1wH7ueY/KiZPoAXiTlhuv1X12hygqhBhmUJCSEV4UAnIS vnAttam5oinpb3mCEmX3CYX1TZkr6GbaAYrNFJ/zai2TB1uzkc/NaO6Dw/LIL56evxOv PO3LikidtXDP0JPylPUINGvkKzbuOUNqnUw6CerDz+rqj9jw+QfyN8ycgC52ByxAFvKo q2QljZ+xjuU85Mk2Ob1eNVCvwSVM29jXUuhIOIfK0aEncggUvxF3+s+fHt5T5EuMhrMU oGrw== X-Gm-Message-State: AElRT7GMrlR28jGIWq5xSxikVyJSSvg/OupGyWJyQd+JyDqBsKoMGn6z foAvIYFahz27sUa4lUVCz4c6bKVtNswwnzRJo8k= X-Google-Smtp-Source: AIpwx48G/HofxBd3brMFlTldaC0f13D7m/iZwGaACqRJqjY3kb6kW8RoNvipSA5eHKj5VSCujhE6513MA9qOn/6dzdY= X-Received: by 10.80.183.144 with SMTP id h16mr6460959ede.96.1522312194743; Thu, 29 Mar 2018 01:29:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.150.3 with HTTP; Thu, 29 Mar 2018 01:29:34 -0700 (PDT) In-Reply-To: References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca> From: Balwant Bisht Date: Thu, 29 Mar 2018 13:59:34 +0530 Message-ID: To: Justin Uberti Cc: Tim Panton , RTCWeb IETF Content-Type: multipart/alternative; boundary="94eb2c0ddf329ae317056888edbf" Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2018 08:29:59 -0000 --94eb2c0ddf329ae317056888edbf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable All VPN setup are not for hiding location, but some are setup to allow remote users to connect to company network. If MCU server is inside VPN and browser didn't get VPN candidates then its not possible to establish PeerConnection with MCU. Also linking it with device access is bad, e.g. if participants joining a webinar and they didn't want to give access to devices, they will not be able to join at all. Regards Balwant Bisht On Thu, Mar 29, 2018 at 10:09 AM, Justin Uberti < juberti=3D40google.com@dmarc.ietf.org> wrote: > Note that this VPN behavior is not unique to web browsers. Mobile > applications are free to use whichever interface they prefer without > needing any additional user permissions. > > > On Wed, Mar 28, 2018 at 7:15 AM westhawk wrote: > >> I tend to agree with Cullen here, this is an issue. (As I said when I >> first raised it way back when). >> >> It is bad practice to ask a user one (clear) question and the deduce >> their agreement to some other things that aren=E2=80=99t (at least to th= e user) >> related. >> >> Conversely an infinite series of questions before each call isn=E2=80=99= t going to >> work either, >> >> With that in mind, perhaps we are hanging off the wrong existing consent= . >> Given that the VPN users in question are (in practice) trying to hide >> their location, >> perhaps that=E2=80=99s the dialog we should hang off instead. >> >> =E2=80=9CThis page would like to use your location: allow, deny=E2=80=9D >> would also unlock public IP address access. >> >> Tim. >> >> >> > On 27 Mar 2018, at 17:57, Cullen Jennings wrote: >> > >> > Theses comments are sent as an individual contributor. >> > >> > Let me start by saying I think I am in the rough on the consensus of >> this draft and I expect the draft to be sent to the IESG with no changes= . >> For the record, as I have said at the floor microphone in the past, I do= n't >> agree with the draft. >> > >> > This draft results in the situation where implementations decide if >> they should reveal the users location to the website by asking a questio= ns >> of the form "Will you allow example.com to use your camera?" If the user >> says that is OK to use their camera, in many cases they have also allowe= d >> the website to get their location via the IP address. From a user point = of >> view, I think this is awful, There are many reasons I might allow a webs= ite >> I do not trust to know my location to access my camera - for example, I >> have a black cover over my camera and the website won't work unless I sa= y >> yes to this request. Or a webcam worker where the job involves revealing >> video but revealing the locations they work at may put them at risk of >> serious harm. Or I am in a domestic abuse shelter and want to have a cal= l >> but revealing may location puts me at risk of physical harm. I do not th= ink >> the IETF should in any way endorse this extremely misleading form of >> consent. It is simply not consent. I realize this would be good for >> companies that are primary funded by by web advertising for which locati= on >> is valuable. >> > >> > There are several people who's opinion I deeply respect that have >> looked at this problem in detail. They somewhat agree the above is a >> problem, but they argue it is better than any alternative design. I >> disagree with this.The root of the problem we are trying to solve with t= his >> draft is that some VPNs are configured to send some packets over the VPN >> while at the same time some other packets are not sent over the VPN. If = you >> use a VPN configured like this to try and hide your location, WebRTC can >> end up sending packets not over the VPN and that can reveal your locatio= n. >> I think the right solution to this problem is to acknowledge this is a V= PN >> problem, not a WebRTC problem. If you are using a VPN to hide your >> location, do not allow that VPN to send packets outside the VPN. I will >> note most VPNs support this. >> > >> > John Morris words from [1], more or less sum up about how I feel about >> this - just reverse W3C and IETF. >> > >> > "By not actually building privacy into the specification, the W3C h= as >> > both missed a significant opportunity to improve user privacy on th= e >> > Web, and it has harmed the efforts of another standards body -- the >> > IETF -- to protect location privacy and to improve the privacy >> > paradigm for Internet services." >> > >> > From a process point of view: 1) I have had time to express this >> opinion in the rtcweb WG meetings and it has been discussed. My read of = the >> consensus in the room is that I am in the rough on this topic 2) I don'= t >> think the rtcweb WG is the WG in the IETF with the most expertise in VPN= s >> > >> > Thanks, Cullen >> > >> > >> > As FYI, the actual questions that are asked by today's browsers are >> roughly the following: >> > >> > In firefox: "Will you allow webrtc.github.io to use your camera?" >> > >> > In chrome: "webrtc.github.io wants to use your camera" >> > >> > In safari: "Allow webrtc.github.io to use your camera?" >> > >> > In edge: "Let webrtc.github.io use your webcam?=E2=80=9D >> > >> > >> > [1] https://lists.w3.org/Archives/Public/public-geolocation/ >> 2009Jul/0020.html >> > >> > >> > >> >> On Mar 7, 2018, at 7:49 PM, Sean Turner wrote: >> >> >> >> All, >> >> >> >> This is the WGLC for the "WebRTC IP Address Handling Requirements=E2= =80=9D >> draft available @ https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip- >> handling/. Please review the draft and send your comments to this list >> by 2359UTC on 30 March 30 2017. >> >> >> >> Thanks, >> >> C/T/S >> >> _______________________________________________ >> >> rtcweb mailing list >> >> rtcweb@ietf.org >> >> https://www.ietf.org/mailman/listinfo/rtcweb >> > >> > _______________________________________________ >> > rtcweb mailing list >> > rtcweb@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --94eb2c0ddf329ae317056888edbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All VPN setup are not for hiding location, but some are se= tup to allow remote users to connect to company network. If MCU server is i= nside VPN and browser didn't get VPN candidates then its not possible t= o establish PeerConnection with MCU. Also linking it with device access is = bad, e.g. if participants joining a webinar and they didn't want to giv= e access to devices, they will not be able to join at all.



Regards
Balwant Bisht


On Thu, Mar 29, 2018 at 10:09 AM, Justin Ube= rti <juberti=3D40google.com@dmarc.ietf.org> wrote:
Note that thi= s VPN behavior is not unique to web browsers. Mobile applications are free = to use whichever interface they prefer without needing any additional user = permissions.


On Wed, Mar 28, 2018 at 7:15 AM westhawk= <thp@westhawk.c= o.uk> wrote:
I tend to agree= with Cullen here, this is an issue. (As I said when I first raised it way = back when).

It is bad practice to ask a user one (clear) question and the deduce
their agreement to some other things that aren=E2=80=99t (at least to the u= ser) related.

Conversely an infinite series of questions before each call isn=E2=80=99t g= oing to
work either,

With that in mind, perhaps we are hanging off the wrong existing consent. Given that the VPN users in question are (in practice) trying to hide their= location,
perhaps that=E2=80=99s the dialog we should hang off instead.

=E2=80=9CThis page would like to use your location: allow, deny=E2=80=9D would also unlock public IP address access.

Tim.


> On 27 Mar 2018, at 17:57, Cullen Jennings <fluffy@iii.ca> wrote:
>
> Theses comments are sent as an individual contributor.
>
> Let me start by saying I think I am in the rough on the consensus of t= his draft and I expect the draft to be sent to the IESG with no changes. Fo= r the record, as I have said at the floor microphone in the past, I don'= ;t agree with the draft.
>
> This draft results in the situation where implementations decide if th= ey should reveal the users location to the website by asking a questions of= the form "Will you allow example.com to use your camera?" If the us= er says that is OK to use their camera, in many cases they have also allowe= d the website to get their location via the IP address. From a user point o= f view, I think this is awful, There are many reasons I might allow a websi= te I do not trust to know my location to access my camera - for example, I = have a black cover over my camera and the website won't work unless I s= ay yes to this request. Or a webcam worker where the job involves revealing= video but revealing the locations they work at may put them at risk of ser= ious harm. Or I am in a domestic abuse shelter and want to have a call but = revealing may location puts me at risk of physical harm. I do not think the= IETF should in any way endorse this extremely misleading form of consent. = It is simply not consent. I realize this would be good for companies that a= re primary funded by by web advertising for which location is valuable.
>
> There are several people who's opinion I deeply respect that have = looked at this problem in detail. They somewhat agree the above is a proble= m, but they argue it is better than any alternative design. I disagree with= this.The root of the problem we are trying to solve with this draft is tha= t some VPNs are configured to send some packets over the VPN while at the s= ame time some other packets are not sent over the VPN. If you use a VPN con= figured like this to try and hide your location, WebRTC can end up sending = packets not over the VPN and that can reveal your location. I think the rig= ht solution to this problem is to acknowledge this is a VPN problem, not a = WebRTC problem. If you are using a VPN to hide your location, do not allow = that VPN to send packets outside the VPN. I will note most VPNs support thi= s.
>
> John Morris words from [1], more or less sum up about how I feel about= this - just reverse W3C and IETF.
>
>=C2=A0 =C2=A0 "By not actually building privacy into the specifica= tion, the W3C has
>=C2=A0 =C2=A0 both missed a significant opportunity to improve user pri= vacy on the
>=C2=A0 =C2=A0 Web, and it has harmed the efforts of another standards b= ody -- the
>=C2=A0 =C2=A0 IETF -- to protect location privacy and to improve the pr= ivacy
>=C2=A0 =C2=A0 paradigm for Internet services."
>
> From a process point of view: 1) I have had time to express this opini= on in the rtcweb WG meetings and it has been discussed. My read of the cons= ensus in the room is that I am in the rough on this topic=C2=A0 2) I don= 9;t think the rtcweb WG is the WG in the IETF with the most expertise in VP= Ns
>
> Thanks, Cullen
>
>
> As FYI, the actual questions that are asked by today's browsers ar= e roughly the following:
>
> In firefox: "Will you allow webrtc.github.io to use your camera= ?"
>
> In chrome: "webrtc.github.io wants to use your camera"
>
> In safari: "Allow webrtc.github.io to use your camera?" >
> In edge: "Let webrtc.github.io use your webcam?=E2=80=9D
>
>
> [1] https://lists.w3.o= rg/Archives/Public/public-geolocation/2009Jul/0020.html
>
>
>
>> On Mar 7, 2018, at 7:49 PM, Sean Turner <sean@sn3rd.com> wrote:
>>
>> All,
>>
>> This is the WGLC for the "WebRTC IP Address Handling Requirem= ents=E2=80=9D draft available @ https= ://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/.= =C2=A0 Please review the draft and send your comments to this list by 2359U= TC on 30 March 30 2017.
>>
>> Thanks,
>> C/T/S
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/rtcw= eb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--94eb2c0ddf329ae317056888edbf-- From nobody Thu Mar 29 01:30:21 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA82812DA41 for ; Thu, 29 Mar 2018 01:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522312207; bh=6bOzt3e6qEf+QhxchecMHopGUXLdW2deL7lMLv6Ag0E=; h=In-Reply-To:References:From:Date:Subject:Cc:To; b=OVtOhz5q/byGUiJ9V9iHum26SMxdUt+kXTavfm0JfTqihdm6IGkVuUIOk7UaT5Dl+ 1oeCYJJuCKc/NiiB4bYedxT/If4MSxDraxq2YNPWUc8o0NiANeZoKPxOufZSHFeJNN kpqGlp7kzrH0CzoU8VdM1dPyGLf+8Q1bc29ruOxY= X-Mailbox-Line: From balwant.bisht@gmail.com Thu Mar 29 01:30:04 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F80712DA1A; Thu, 29 Mar 2018 01:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522312204; bh=z8V7DmugU5wksutB0c/PlKVlOG6AdH+OJg6/Sosk7ag=; h=In-Reply-To:References:From:Date:Subject:Cc:To; b=D4MyCnvYJtwi3qodp9MItXXOBz7OxibpkqKwlPxjMVcCiOZeW5t76qCkXeUVTS44s Wv8dtrbexNSui7D58LT1BycMZ5UzO+YG0ncywrJ5FtVG4GR9ImNd8hcI/4sWlEO891 hetq2yaAkZ8bKA0IABLw2cqkbdRjfEufOKSewW1U= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8364512D95B for ; Thu, 29 Mar 2018 01:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 ZG0DiF0F5IX7 for ; Thu, 29 Mar 2018 01:30:00 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 846E6124207 for ; Thu, 29 Mar 2018 01:29:56 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id p9so9237711wmc.3 for ; Thu, 29 Mar 2018 01:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nDb2wtDkNIQp3VSdXDgvq+tMuId6Mpzqc68gz/I9s4o=; b=Hermms16+lyg+5NYuuQ4xU9Jy9onWpyMwTMof5E3WkJuuv/npv9AZ/C+nQzzUInofc CNClBnwH0mSi0XGrpH7PzCZzriJwRyZPEE0VvBNMhKlicyxvpRApcehD4Qj3X9YK0gK4 O9BYQjS4eZRQGldj7xiPS1a+nU5Nlx7/p9s+rA5JFxpAXcFUir7WpJqavhGYMNYRNAGa 8r1QbVpJjiJO6AcU7TTV0o9DABMsJzHttskOHh5e6JNXgOVZdKkpO5AoteTP8A7hM5L1 YyKOyuxxIUCZroGks+J11XrsZM4WoFchfoRLeksbdw316PMmrhf0PyOYT+no14zJgwCh 9rEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nDb2wtDkNIQp3VSdXDgvq+tMuId6Mpzqc68gz/I9s4o=; b=rWoVF3OwG6sSwR73KvGc92OtJyUn4g5er5FqnBfMOHMdDqNYWGsSAi+7jjCxvYNA7Q O0nCfK9j1VOedvLnz2JkMYgo0cd0MQ1Luw3Hi6aspYIpvMnYOqCFzrEcH6JYZ6JAczH3 KluRUWsekZv6L0hRGPRjyyawlGupTqNFoHpEkwbiSHA5X2cc9KO2frZJzJzgkqDAAgDX capLlB+gxI3H21ye70FPoVj8dcj3cC3sZrKiL3GSC1kDICu0MWHg4eByZcylEwcMtlZC R3LkAacF0ptlSAQY1FzHKXmxh6AnQzOnjR12GMZ1NaWNCmDN9DvNsBW+lGx+aRKdQESZ hu2w== X-Gm-Message-State: AElRT7FSn0BEiHDGEaDnGNRmKPBTnHtRVB9ez5PgNnTUntPNcTNZJ8Mh yB3XoI8mCDE3XbFUP7eZu5sAA/7ui/V/VkcyZrU= X-Google-Smtp-Source: AIpwx48G/HofxBd3brMFlTldaC0f13D7m/iZwGaACqRJqjY3kb6kW8RoNvipSA5eHKj5VSCujhE6513MA9qOn/6dzdY= X-Received: by 10.80.183.144 with SMTP id h16mr6460959ede.96.1522312194743; Thu, 29 Mar 2018 01:29:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.150.3 with HTTP; Thu, 29 Mar 2018 01:29:34 -0700 (PDT) In-Reply-To: References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca> From: Balwant Bisht Date: Thu, 29 Mar 2018 13:59:34 +0530 Message-ID: Cc: Tim Panton , RTCWeb IETF Content-Type: multipart/alternative; boundary="94eb2c0ddf329ae317056888edbf" To: Justin Uberti Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2018 08:30:09 -0000 --94eb2c0ddf329ae317056888edbf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable All VPN setup are not for hiding location, but some are setup to allow remote users to connect to company network. If MCU server is inside VPN and browser didn't get VPN candidates then its not possible to establish PeerConnection with MCU. Also linking it with device access is bad, e.g. if participants joining a webinar and they didn't want to give access to devices, they will not be able to join at all. Regards Balwant Bisht On Thu, Mar 29, 2018 at 10:09 AM, Justin Uberti < juberti=3D40google.com@dmarc.ietf.org> wrote: > Note that this VPN behavior is not unique to web browsers. Mobile > applications are free to use whichever interface they prefer without > needing any additional user permissions. > > > On Wed, Mar 28, 2018 at 7:15 AM westhawk wrote: > >> I tend to agree with Cullen here, this is an issue. (As I said when I >> first raised it way back when). >> >> It is bad practice to ask a user one (clear) question and the deduce >> their agreement to some other things that aren=E2=80=99t (at least to th= e user) >> related. >> >> Conversely an infinite series of questions before each call isn=E2=80=99= t going to >> work either, >> >> With that in mind, perhaps we are hanging off the wrong existing consent= .. >> Given that the VPN users in question are (in practice) trying to hide >> their location, >> perhaps that=E2=80=99s the dialog we should hang off instead. >> >> =E2=80=9CThis page would like to use your location: allow, deny=E2=80=9D >> would also unlock public IP address access. >> >> Tim. >> >> >> > On 27 Mar 2018, at 17:57, Cullen Jennings wrote: >> > >> > Theses comments are sent as an individual contributor. >> > >> > Let me start by saying I think I am in the rough on the consensus of >> this draft and I expect the draft to be sent to the IESG with no changes= .. >> For the record, as I have said at the floor microphone in the past, I do= n't >> agree with the draft. >> > >> > This draft results in the situation where implementations decide if >> they should reveal the users location to the website by asking a questio= ns >> of the form "Will you allow example.com to use your camera?" If the user >> says that is OK to use their camera, in many cases they have also allowe= d >> the website to get their location via the IP address. From a user point = of >> view, I think this is awful, There are many reasons I might allow a webs= ite >> I do not trust to know my location to access my camera - for example, I >> have a black cover over my camera and the website won't work unless I sa= y >> yes to this request. Or a webcam worker where the job involves revealing >> video but revealing the locations they work at may put them at risk of >> serious harm. Or I am in a domestic abuse shelter and want to have a cal= l >> but revealing may location puts me at risk of physical harm. I do not th= ink >> the IETF should in any way endorse this extremely misleading form of >> consent. It is simply not consent. I realize this would be good for >> companies that are primary funded by by web advertising for which locati= on >> is valuable. >> > >> > There are several people who's opinion I deeply respect that have >> looked at this problem in detail. They somewhat agree the above is a >> problem, but they argue it is better than any alternative design. I >> disagree with this.The root of the problem we are trying to solve with t= his >> draft is that some VPNs are configured to send some packets over the VPN >> while at the same time some other packets are not sent over the VPN. If = you >> use a VPN configured like this to try and hide your location, WebRTC can >> end up sending packets not over the VPN and that can reveal your locatio= n. >> I think the right solution to this problem is to acknowledge this is a V= PN >> problem, not a WebRTC problem. If you are using a VPN to hide your >> location, do not allow that VPN to send packets outside the VPN. I will >> note most VPNs support this. >> > >> > John Morris words from [1], more or less sum up about how I feel about >> this - just reverse W3C and IETF. >> > >> > "By not actually building privacy into the specification, the W3C h= as >> > both missed a significant opportunity to improve user privacy on th= e >> > Web, and it has harmed the efforts of another standards body -- the >> > IETF -- to protect location privacy and to improve the privacy >> > paradigm for Internet services." >> > >> > From a process point of view: 1) I have had time to express this >> opinion in the rtcweb WG meetings and it has been discussed. My read of = the >> consensus in the room is that I am in the rough on this topic 2) I don'= t >> think the rtcweb WG is the WG in the IETF with the most expertise in VPN= s >> > >> > Thanks, Cullen >> > >> > >> > As FYI, the actual questions that are asked by today's browsers are >> roughly the following: >> > >> > In firefox: "Will you allow webrtc.github.io to use your camera?" >> > >> > In chrome: "webrtc.github.io wants to use your camera" >> > >> > In safari: "Allow webrtc.github.io to use your camera?" >> > >> > In edge: "Let webrtc.github.io use your webcam?=E2=80=9D >> > >> > >> > [1] https://lists.w3.org/Archives/Public/public-geolocation/ >> 2009Jul/0020.html >> > >> > >> > >> >> On Mar 7, 2018, at 7:49 PM, Sean Turner wrote: >> >> >> >> All, >> >> >> >> This is the WGLC for the "WebRTC IP Address Handling Requirements=E2= =80=9D >> draft available @ https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip- >> handling/. Please review the draft and send your comments to this list >> by 2359UTC on 30 March 30 2017. >> >> >> >> Thanks, >> >> C/T/S >> >> _______________________________________________ >> >> rtcweb mailing list >> >> rtcweb@ietf.org >> >> https://www.ietf.org/mailman/listinfo/rtcweb >> > >> > _______________________________________________ >> > rtcweb mailing list >> > rtcweb@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --94eb2c0ddf329ae317056888edbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All VPN setup are not for hiding location, but some are se= tup to allow remote users to connect to company network. If MCU server is i= nside VPN and browser didn't get VPN candidates then its not possible t= o establish PeerConnection with MCU. Also linking it with device access is = bad, e.g. if participants joining a webinar and they didn't want to giv= e access to devices, they will not be able to join at all.



Regards
Balwant Bisht


On Thu, Mar 29, 2018 at 10:09 AM, Justin Ube= rti <juberti=3D40google.com@dmarc.ietf.org> wrote:
Note that thi= s VPN behavior is not unique to web browsers. Mobile applications are free = to use whichever interface they prefer without needing any additional user = permissions.


On Wed, Mar 28, 2018 at 7:15 AM westhawk= <thp@westhawk.c= o.uk> wrote:
I tend to agree= with Cullen here, this is an issue. (As I said when I first raised it way = back when).

It is bad practice to ask a user one (clear) question and the deduce
their agreement to some other things that aren=E2=80=99t (at least to the u= ser) related.

Conversely an infinite series of questions before each call isn=E2=80=99t g= oing to
work either,

With that in mind, perhaps we are hanging off the wrong existing consent. Given that the VPN users in question are (in practice) trying to hide their= location,
perhaps that=E2=80=99s the dialog we should hang off instead.

=E2=80=9CThis page would like to use your location: allow, deny=E2=80=9D would also unlock public IP address access.

Tim.


> On 27 Mar 2018, at 17:57, Cullen Jennings <fluffy@iii.ca> wrote:
>
> Theses comments are sent as an individual contributor.
>
> Let me start by saying I think I am in the rough on the consensus of t= his draft and I expect the draft to be sent to the IESG with no changes. Fo= r the record, as I have said at the floor microphone in the past, I don'= ;t agree with the draft.
>
> This draft results in the situation where implementations decide if th= ey should reveal the users location to the website by asking a questions of= the form "Will you allow example.com to use your camera?" If the us= er says that is OK to use their camera, in many cases they have also allowe= d the website to get their location via the IP address. From a user point o= f view, I think this is awful, There are many reasons I might allow a websi= te I do not trust to know my location to access my camera - for example, I = have a black cover over my camera and the website won't work unless I s= ay yes to this request. Or a webcam worker where the job involves revealing= video but revealing the locations they work at may put them at risk of ser= ious harm. Or I am in a domestic abuse shelter and want to have a call but = revealing may location puts me at risk of physical harm. I do not think the= IETF should in any way endorse this extremely misleading form of consent. = It is simply not consent. I realize this would be good for companies that a= re primary funded by by web advertising for which location is valuable.
>
> There are several people who's opinion I deeply respect that have = looked at this problem in detail. They somewhat agree the above is a proble= m, but they argue it is better than any alternative design. I disagree with= this.The root of the problem we are trying to solve with this draft is tha= t some VPNs are configured to send some packets over the VPN while at the s= ame time some other packets are not sent over the VPN. If you use a VPN con= figured like this to try and hide your location, WebRTC can end up sending = packets not over the VPN and that can reveal your location. I think the rig= ht solution to this problem is to acknowledge this is a VPN problem, not a = WebRTC problem. If you are using a VPN to hide your location, do not allow = that VPN to send packets outside the VPN. I will note most VPNs support thi= s.
>
> John Morris words from [1], more or less sum up about how I feel about= this - just reverse W3C and IETF.
>
>=C2=A0 =C2=A0 "By not actually building privacy into the specifica= tion, the W3C has
>=C2=A0 =C2=A0 both missed a significant opportunity to improve user pri= vacy on the
>=C2=A0 =C2=A0 Web, and it has harmed the efforts of another standards b= ody -- the
>=C2=A0 =C2=A0 IETF -- to protect location privacy and to improve the pr= ivacy
>=C2=A0 =C2=A0 paradigm for Internet services."
>
> From a process point of view: 1) I have had time to express this opini= on in the rtcweb WG meetings and it has been discussed. My read of the cons= ensus in the room is that I am in the rough on this topic=C2=A0 2) I don= 9;t think the rtcweb WG is the WG in the IETF with the most expertise in VP= Ns
>
> Thanks, Cullen
>
>
> As FYI, the actual questions that are asked by today's browsers ar= e roughly the following:
>
> In firefox: "Will you allow webrtc.github.io to use your camera= ?"
>
> In chrome: "webrtc.github.io wants to use your camera"
>
> In safari: "Allow webrtc.github.io to use your camera?" >
> In edge: "Let webrtc.github.io use your webcam?=E2=80=9D
>
>
> [1] https://lists.w3.o= rg/Archives/Public/public-geolocation/2009Jul/0020.html
>
>
>
>> On Mar 7, 2018, at 7:49 PM, Sean Turner <sean@sn3rd.com> wrote:
>>
>> All,
>>
>> This is the WGLC for the "WebRTC IP Address Handling Requirem= ents=E2=80=9D draft available @ https= ://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/.= =C2=A0 Please review the draft and send your comments to this list by 2359U= TC on 30 March 30 2017.
>>
>> Thanks,
>> C/T/S
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/rtcw= eb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--94eb2c0ddf329ae317056888edbf-- From nobody Thu Mar 29 08:34:09 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4310312D95F for ; Thu, 29 Mar 2018 08:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=aruba.it 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 lpuCbSOj5GdX for ; Thu, 29 Mar 2018 08:34:06 -0700 (PDT) Received: from smtpcmd10101.aruba.it (smtpcmd14161.aruba.it [62.149.156.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6E312711B for ; Thu, 29 Mar 2018 08:34:05 -0700 (PDT) Received: from lminiero ([93.44.67.253]) by smtpcmd14.ad.aruba.it with bizsmtp id Tra31x00P5TrUJd01ra36B; Thu, 29 Mar 2018 17:34:04 +0200 Date: Thu, 29 Mar 2018 17:34:03 +0200 From: Lorenzo Miniero To: Lennart Grahl Cc: rtcweb@ietf.org Message-ID: <20180329173403.78d6efde@lminiero> In-Reply-To: References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca> Organization: Meetecho X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1522337644; bh=o68gxYFFPI57an1XKnwAEXwfugnHOdMbMHIMf70VIQc=; h=Date:From:To:Subject:MIME-Version:Content-Type; b=mUOlcTIvRkZcuGFYSwWZm7aJsnM+M+M6HQsKcHWM2r7BnR7KKMkn8sNW8GlmC2CpD WanjbLN/ysx8tQFBoWiRBOJs++H5SbPv6axqllIU/LlXrSWqeXPx0M3fhT00RTRrRP Tc2KqHU/WasUGS9px0uDNUQABsxnuZ64jkKU+EWPEioGMvrP3dadH2uDmLIAlhbz5u jiIadf2HxvHxR8cT9/Y/6gg3HWGe7iqZXx6JI31w7ePlNqwt3wQEMk/6zuUvcvRwaC oHDqeR5RjgawehdVCTVykSGdNFY3Rl/NHUCPwtRmUdJOd//FPDoN3ZgVP9XM+fI+5E cBavscV3w8Nlg== Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2018 15:34:09 -0000 On Wed, 28 Mar 2018 03:49:59 +0200 Lennart Grahl wrote: > On 27.03.2018 18:57, Cullen Jennings wrote: > > This draft results in the situation where implementations decide if > > they should reveal the users location to the website by asking a > > questions of the form "Will you allow example.com to use your > > camera?" If the user says that is OK to use their camera, in many > > cases they have also allowed the website to get their location via > > the IP address. From a user point of view, I think this is awful, > > There are many reasons I might allow a website I do not trust to > > know my location to access my camera - for example, I have a black > > cover over my camera and the website won't work unless I say yes to > > this request. Or a webcam worker where the job involves revealing > > video but revealing the locations they work at may put them at risk > > of serious harm. Or I am in a domestic abuse shelter and want to > > have a call but revealing may location puts me at risk of physical > > harm. I do not think the IETF should in any way endorse this > > extremely misleading form of consent. It is simply not consent. I > > realize t > his would be good for companies that are primary funded by by web > advertising for which location is valuable. > > I agree with you here and this is most likely the reason why WebRTC is > on the blacklist of many privacy extensions for browsers. > > However, I believe there could be a form of consent in the browsers - > tell them what you actually want to do: Expose (all) private IP > addresses to create a direct connection. Yes, getting users to > understand what it means to "establish a direct connection" may not be > trivial - granted. But it's much more sincere AND it would not > discriminate data channel only use cases (yeah, it's really shady to > request capture permissions to be able to use mode 1). > And let's not forget we're not just talking of discriminating data channels, here. As someone else already pointed out, this would affect recvonly audio/video PeerConnections as well. Requiring access to a local device to implement those would be a very hacky solution (and in fact Safari, which currently does something like this, is horrible in that regard), especially considering that, just as for data channels, there would be no need to require access to your webcam if you just wanted to attend a webinar and never say anything yourself. It would actually have the effect of looking even shadier to end users ("why exactly do you want to access my webcam? I'm just trying to watch something here!"), just as it would for datachannel-only PCs, and further reduce the trust people would have in WebRTC as a technology. As Lennart said, a different popup that says something like "this page wants to create " would be a much better solution. Yes, another UI knob or something like this, but still much better than abusing the only consent request we currently expose simply because it's, again, the only we have and we don't want to annoy users too much. Lorenzo > And FWIW I'm not sure this form of consent fits into the scope of the > IETF. Maybe the modes could be defined in this document and which mode > to choose under which circumstances could be moved into the W3C > WebRTC spec. > > Cheers > Lennart > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- I'm getting older but, unlike whisky, I'm not getting any better https://twitter.com/elminiero From nobody Thu Mar 29 14:04:07 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66CD712DA07 for ; Thu, 29 Mar 2018 14:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=aliax-net.20150623.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 RMBdL0UmmZFq for ; Thu, 29 Mar 2018 14:04:02 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 64E4F12D958 for ; Thu, 29 Mar 2018 14:04:02 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id y127so4110790vky.9 for ; Thu, 29 Mar 2018 14:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=vtAP2mgHWqcCWw+FK57yMXcEOZbNzjNLFMNQdoHGV1c=; b=qLV4XyHzR3503y5rfykiC4Om7x76CJp6QAJywHiLzAnMAktpjIHrJGSwHj4+suhH4Q sk+qOravojb28RneDh/U73DFFBQDrzTvSnakPcBMhkslGlLi4IZBrPMiV1F6gCakiVmT yuJH7CC/5Zml5V0VIbLAIHNXo45ehw573G/w3+E6JOTvS5S7hyfa6apH6z/EP+Y0u6hi FKB18sSRiznxlGrjER2YpckBOfQxHJeIZ0w1wn2OxsqXpYWyNYSQYIEUQPPut7/HzQRZ oSTku+FnHfe5r1RpEHYjswyBlwtbVpH+6Tpv0p3bTC6VDqy7ylKGgyn1L5a+fV8KlLdy /peg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=vtAP2mgHWqcCWw+FK57yMXcEOZbNzjNLFMNQdoHGV1c=; b=jwwS2UY4EnmYVhZf7rCp75SDz7OCP8Lrq3agfMWH93rPBblc5Syqza+KvaA3qPUCNn kTziVCzRjd8bbcveGUdwIaA4iOak8Ve/SvjfRH+gbemRCYhY71v6Wnp1kuQE/AUYxG0A L+iGU6dXNnMI7kNFBsxVX6LdeCEUCsz4FMVZnVz+fDC2ShDXw/PyPugOksHNNPCtGuj8 6qFDMpRnv5oOEyUMGV+PZuDQL5y42FBq6Vhaffh9kV9wZyk/k3zvYGKX2tVhXDFnyxNm Ckldv/Zq33a3p687hE7ycTMg27gx6It0fAzFO7rd8lS1dZRh7rsjlZUDgLlKmfGpAJJB 5uTw== X-Gm-Message-State: AElRT7G637mKuPdqs15oCw9jlE9aR/cY7DRMQeJ5jeILbUMiuA1Jq4qf EPAXO0YdaaacA3RG6DJGWOf+GSb2ohfHQkUparrwCKy6 X-Google-Smtp-Source: AIpwx4+z3WBecTFZdWiPXzSR315nRc9RIHIDBeTH/4pWEhrIo/WcwrNLweIFV/eeAjL0+CycfuLhOH0znkRpVt/xbts= X-Received: by 10.31.92.82 with SMTP id q79mr6154769vkb.159.1522357441411; Thu, 29 Mar 2018 14:04:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.130 with HTTP; Thu, 29 Mar 2018 14:03:40 -0700 (PDT) In-Reply-To: <20180329173403.78d6efde@lminiero> References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca> <20180329173403.78d6efde@lminiero> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 29 Mar 2018 23:03:40 +0200 Message-ID: To: Lorenzo Miniero Cc: Lennart Grahl , rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2018 21:04:05 -0000 On 29 March 2018 at 17:34, Lorenzo Miniero wrote: > And let's not forget we're not just talking of discriminating data > channels, here. As someone else already pointed out, this would affect > recvonly audio/video PeerConnections as well. Requiring access to > a local device to implement those would be a very hacky solution (and > in fact Safari, which currently does something like this, is horrible > in that regard), especially considering that, just as for data channels, > there would be no need to require access to your webcam if you just > wanted to attend a webinar and never say anything yourself. It would > actually have the effect of looking even shadier to end users ("why > exactly do you want to access my webcam? I'm just trying to watch > something here!"), just as it would for datachannel-only PCs, and > further reduce the trust people would have in WebRTC as a technology. > > As Lennart said, a different popup that says something like "this page > wants to create " would be a much better solution. Yes, > another UI knob or something like this, but still much better than > abusing the only consent request we currently expose simply because > it's, again, the only we have and we don't want to annoy users too much. Completely agreed with Lorenzo. Asking for "mic/webcam access" to get full IP access and then not using the mic/webcam (because the app just wants to receive media or run a datachannel) is a hacky and ugly solution. Please, just add a new prompt to ask for full IP access and save such a setting per origin (same as getUserMedia when HTTPS). That's all. --=20 I=C3=B1aki Baz Castillo From nobody Thu Mar 29 14:21:49 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDC8126D05 for ; Thu, 29 Mar 2018 14:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOAjKlParuiH for ; Thu, 29 Mar 2018 14:21:37 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (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 D502712EA24 for ; Thu, 29 Mar 2018 14:21:22 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id s92so4429223uas.11 for ; Thu, 29 Mar 2018 14:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JuV3yzlO91MJh7E/CIVSXLkh5AgwfK5APE+Hx3d+Lok=; b=M/lcZx6DmEKfQCN/OG3HDnJCWbHc/HbBgNzdXuDmVweF6xhp/q11J2mEBMPOWQNRaf GLfsrjhoJxNm8VaZVK2Ku2qPMK+rYpu3Z7D+pnQYvPLjHMQehShuagoMMAp+aKldqgV3 rdXto1NrdfirFxul7OjSPp5N8xxxnjGT6IbwZ0A1U1uoAa8Ls+NctshzjXI1uSXcEgDQ w4e/DPsYB16TzkEITSOXsbbLvgLjaOjjtX27MzAaocPtuxmC5I1k4QYthwC5yuN2DaTn JI1XtbEmJCQdhArfM1D1o98GrzNnd47VE1PCiMQZAALIovHz5mjsSQWUqwi5FowO7wF0 8VFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JuV3yzlO91MJh7E/CIVSXLkh5AgwfK5APE+Hx3d+Lok=; b=K0MpmqloYu4w9/s9B/Jv9YKbeqknqpllx7OgJcQ5khD2SLb2Y7v5IiN9pze9PksKoN PE3rTNTsF7TO+VTzxux1as4Llr+AeS2Am3Pzkpj2u1/Jmmmietc5A2+qcR4CFegL8swU 0iVVXOfL5co6AeELgtxos3pPsjGh+3RNB7dTZNHVeJl0HaTwU6ofv94hJVX/2znVGa/+ 2gSbhEBNyhyMuO+TcvjWoOHCXbrqQypH20Lvl4vbWiS0i2n/SOyYZbxS5PhgCOOGaWYy O80B/NBkou+lln6ECUjvIQm7y4ZyUHocuy7rotti6cT8ZEh1Z75yz6QKBlaWxMC3tmPD UJ5w== X-Gm-Message-State: AElRT7Fyyh0gvkDh6sjMROQBnKIrjiPNaFpphsSGHVexXNkm1+coFFG5 /3v6H9/9kmkUH0hPo+o2Be1w0O0edy5elncUOvz8Kg== X-Google-Smtp-Source: AIpwx4+mnTM301H7VRp8yyZUeTBG3DIAHIRhTPh2ijkFgAAnbagzu4kFBDF25f0JZdXatWa2tsYhA5urjQOzBHintFY= X-Received: by 10.176.21.1 with SMTP id o1mr6253977uae.60.1522358481532; Thu, 29 Mar 2018 14:21:21 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca> <20180329173403.78d6efde@lminiero> In-Reply-To: From: Justin Uberti Date: Thu, 29 Mar 2018 21:21:10 +0000 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: Lorenzo Miniero , RTCWeb IETF Content-Type: multipart/alternative; boundary="001a11463dcc83df5a056893b4c9" Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2018 21:21:47 -0000 --001a11463dcc83df5a056893b4c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This notion of sites asking for device access just to get a full set of IP addresses has been discussed many times, but I am not aware of any cases of this happening in the real world. If the user is on a VPN and trying to contact a MCU that is on the VPN, Mode 2 (no devices access needed) will do the right thing, assuming HTTP traffic is being routed correctly. On Thu, Mar 29, 2018 at 2:04 PM I=C3=B1aki Baz Castillo wro= te: > On 29 March 2018 at 17:34, Lorenzo Miniero wrote: > > And let's not forget we're not just talking of discriminating data > > channels, here. As someone else already pointed out, this would affect > > recvonly audio/video PeerConnections as well. Requiring access to > > a local device to implement those would be a very hacky solution (and > > in fact Safari, which currently does something like this, is horrible > > in that regard), especially considering that, just as for data channels= , > > there would be no need to require access to your webcam if you just > > wanted to attend a webinar and never say anything yourself. It would > > actually have the effect of looking even shadier to end users ("why > > exactly do you want to access my webcam? I'm just trying to watch > > something here!"), just as it would for datachannel-only PCs, and > > further reduce the trust people would have in WebRTC as a technology. > > > > As Lennart said, a different popup that says something like "this page > > wants to create " would be a much better solution. Yes, > > another UI knob or something like this, but still much better than > > abusing the only consent request we currently expose simply because > > it's, again, the only we have and we don't want to annoy users too much= . > > Completely agreed with Lorenzo. Asking for "mic/webcam access" to get > full IP access and then not using the mic/webcam (because the app just > wants to receive media or run a datachannel) is a hacky and ugly > solution. > > Please, just add a new prompt to ask for full IP access and save such > a setting per origin (same as getUserMedia when HTTPS). That's all. > > > -- > I=C3=B1aki Baz Castillo > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11463dcc83df5a056893b4c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This notion of sites asking for device access just to get = a full set of IP addresses has been discussed many times, but I am not awar= e of any cases of this happening in the real world.

If t= he user is on a VPN and trying to contact a MCU that is on the VPN, Mode 2 = (no devices access needed) will do the right thing, assuming HTTP traffic i= s being routed correctly.


On Thu, Mar 29, 2018 at 2:04 PM I=C3=B1aki Baz Castillo <<= a href=3D"mailto:ibc@aliax.net">ibc@aliax.net> wrote:
On 29 March 2018 at 17:34, Lorenzo Miniero <lorenzo@meetecho.co= m> wrote:
> And let's not forget we're not just talking of discriminating = data
> channels, here. As someone else already pointed out, this would affect=
> recvonly audio/video PeerConnections as well. Requiring access to
> a local device to implement those would be a very hacky solution (and<= br> > in fact Safari, which currently does something like this, is horrible<= br> > in that regard), especially considering that, just as for data channel= s,
> there would be no need to require access to your webcam if you just > wanted to attend a webinar and never say anything yourself. It would > actually have the effect of looking even shadier to end users ("w= hy
> exactly do you want to access my webcam? I'm just trying to watch<= br> > something here!"), just as it would for datachannel-only PCs, and=
> further reduce the trust people would have in WebRTC as a technology.<= br> >
> As Lennart said, a different popup that says something like "this= page
> wants to create <something>" would be a much better solutio= n. Yes,
> another UI knob or something like this, but still much better than
> abusing the only consent request we currently expose simply because > it's, again, the only we have and we don't want to annoy users= too much.

Completely agreed with Lorenzo. Asking for "mic/webcam access" to= get
full IP access and then not using the mic/webcam (because the app just
wants to receive media or run a datachannel) is a hacky and ugly
solution.

Please, just add a new prompt to ask for full IP access and save such
a setting per origin (same as getUserMedia when HTTPS). That's all.


--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>= ;

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--001a11463dcc83df5a056893b4c9-- From nobody Thu Mar 29 14:29:39 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7D21272E1 for ; Thu, 29 Mar 2018 14:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 8FEoNoQtfi43 for ; Thu, 29 Mar 2018 14:29:34 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 3E321127078 for ; Thu, 29 Mar 2018 14:29:34 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id b16so4147028vka.5 for ; Thu, 29 Mar 2018 14:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ywwCbMASUrrCdTJc0qmLm+bEJq/p+EXkJXtKsmN1MGA=; b=Rm/LYgPZmnjTGuPz8q0LfGdowuOMvq1N0x3yiLWpaHxbUTpMQ2YJWVOkVnB211rJoc uTNXx0s0eLYoaAPgVwTO+jkUqc+Dh1egMKI0yjanenpFfAUBsRBqO9T4Vul6IXEabJcz rwt+Ie1CPcYY4EpqFvOx37xpTMPbhLdhvJsF1bZeBXiHxtlHlLbOb/fjZLNdQlUACzN2 BbfAhybr48gl2pUgGi+z03TplAuYB3qYONLe/vvZZpAtLCAXtwHTv/sytLE0HYZxyRJY gb+c4d5BVhF6XxUBdjbhKhwPGRAQL4X0Avek3z98ckhTSHVXUkvX/ddE3TTneu/OdF8T uVqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ywwCbMASUrrCdTJc0qmLm+bEJq/p+EXkJXtKsmN1MGA=; b=h0avz7aCJejznDjn3/KojntoIJLjU4jo56V3SgT1+Z2xMda98Lv/pSAVwZ2615RNtI DuduwCOfTEV/BjphuNspRJuq3fwzBGMwmGX6jTPCElLEP8/UsMP0TS4Y6RONEkDrQx8s G9HpOTC8pme+7rMtaS51R+NDsq+9OqB2+4xI6TRGw+gfFwE+7Rfg9325eozxQfHGXmCi 63VcUvQoavCf8i1cK5/4yRVBTtMSvcYyTMriTW/2kyFum6estyePyVR75MwXtV6rM9AN 32m61ThWu3ZT36BHo2VVIHqdbRnJclsStl5yGIkYGjF0WczH2oZRVB/iDooc2Yt6yeuX Bu/g== X-Gm-Message-State: ALQs6tBCvqfY2/Z6g4uJ4VqcxB3MxRR4MRD0O19tV/+p16HqMuyXm+Kn xFYWrdv9rKA/gmvqM/5sh9OWS1py3JW2C114eOMgvA== X-Google-Smtp-Source: AIpwx4+cqL+rcNVQRzpmrvzJpA4X7h97DiPYL+sD+87IdhtVTYwLhc4v36ROm6nJBjnoS7RxWzdx1gQZAOCyS0v3uSg= X-Received: by 10.31.183.203 with SMTP id h194mr5994846vkf.32.1522358973008; Thu, 29 Mar 2018 14:29:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.81.100 with HTTP; Thu, 29 Mar 2018 14:29:12 -0700 (PDT) In-Reply-To: References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> From: Bernard Aboba Date: Thu, 29 Mar 2018 14:29:12 -0700 Message-ID: To: Stephen Farrell Cc: Justin Uberti , RTCWeb IETF Content-Type: multipart/alternative; boundary="001a1143a498ce9332056893d108" Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2018 21:29:37 -0000 --001a1143a498ce9332056893d108 Content-Type: text/plain; charset="UTF-8" Stephen Farrell said: "So it's all a bit of a fig leaf IMO." [BA] Correct me if I'm missing something, but there are a class of abusive applications that don't even pretend to support realtime communications and don't call getUserMedia (probably so as not to give the user an inkling of what they are up to). So while there is some leeway to argue about the meaning of "consent" for an application that actually utilizes the WebRTC APIs for communications between browsers, there are a class of abusive applications that don't fulfill even the most liberal definition of "consent". On Wed, Mar 7, 2018 at 2:51 PM, Stephen Farrell wrote: > > > On 07/03/18 22:35, Justin Uberti wrote: > >>> In addition, while gUM consent is given as an example, it is not > >> normative. > >>> Mode 1 MUST only be used when user consent has been provided. The > >>> details of this consent are left to the implementation; one > potential > >>> mechanism is to tie this consent to getUserMedia consent. > >> Sure. OTOH, IIUC, that is what's done in web browsers so it kind > >> of really is normative, in practice. Again, apologies if there > >> are other things done in browsers. > >> > > I believe that the Brave browser uses Mode 4 in its private browsing > mode. > > https://github.com/brave/browser-laptop/issues/260 > > Interesting, didn't know that and good to see. > > OTOH, still the vast majority of web browsers will I assume > do mode 1 for the vast majority of webrtc calls. > > So it's a bit of a fig leaf IMO. > > S. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a1143a498ce9332056893d108 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Stephen Farrell said:=C2=A0

"So it= 's all a bit of a fig leaf IMO."=C2=A0
=C2=A0
= [BA] Correct me if I'm missing something, but there are a class of abus= ive applications that don't even pretend to support realtime communicat= ions and don't call getUserMedia (probably so as not to give the user a= n inkling of what they are up to).

So while there = is some leeway to argue about the meaning of "consent" for an app= lication that actually utilizes the WebRTC APIs for communications between = browsers, there are a class of abusive applications that don't fulfill = even the most liberal definition of "consent".=C2=A0
<= div class=3D"gmail_extra">
On Wed, Mar 7, 201= 8 at 2:51 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


On 07/03/18 22:35, Justin Uberti wrote:
>>> In addition, while gUM consent is given as an example, it is n= ot
>> normative.
>>>=C2=A0 =C2=A0 Mode 1 MUST only be used when user consent has be= en provided.=C2=A0 The
>>>=C2=A0 =C2=A0 details of this consent are left to the implement= ation; one potential
>>>=C2=A0 =C2=A0 mechanism is to tie this consent to getUserMedia = consent.
>> Sure. OTOH, IIUC, that is what's done in web browsers so it ki= nd
>> of really is normative, in practice. Again, apologies if there
>> are other things done in browsers.
>>
> I believe that the Brave browser uses Mode 4 in its private browsing m= ode.
> https://github.com/brave/browser-laptop/= issues/260

Interesting, didn't know that and good to see.

OTOH, still the vast majority of web browsers will I assume
do mode 1 for the vast majority of webrtc calls.

So it's a bit of a fig leaf IMO.

S.



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--001a1143a498ce9332056893d108-- From nobody Thu Mar 29 15:03:27 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B615E12E893 for ; Thu, 29 Mar 2018 15:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTReLNmEyaBR for ; Thu, 29 Mar 2018 15:03:14 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (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 69FCB12EAA9 for ; Thu, 29 Mar 2018 15:03:11 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id q12so4497366uae.4 for ; Thu, 29 Mar 2018 15:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YrGmcgqBNglOJkfCbs9s/eyT0HJYfIAsCLbom4vaeYc=; b=jdGKqX5NaheTciPK5okEMVmjRxLv47sTH7yROMTXGWWME8tO1tOQ1mS/oZ2zseH+22 HbqQsy15Y1nQQmLgIKkhvic3eoh9nRLvKqYULB6MTn/vN8fzjnXX5vI3ZEvBbOCMpwpG a0yw8vb7NqdlD5WrUMbCpqWrNZvaZMzEuRIR8kTrK4NUV6NV9yeraWB8rTAxs2+a3hIv l9f4b/AN446o3qn2iLVR3YAMb1gOfEq4rlA7HOIx3g40YjLe0fxFnw6r6ZD+GGZYbv4M nWMXOkr1yxVY5rRUq/oOiRZF5bhTQ1S9rid8zI6jgQv2sHQ7EEg8I1+q8uljts1pER1p EmQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YrGmcgqBNglOJkfCbs9s/eyT0HJYfIAsCLbom4vaeYc=; b=ov2kehitccFcG7wUNbPoSCpIb/Zw73fJy1YfpuRcP+uB2OWl3aEp0A4u0tf+XH5nw6 DxiSVN9szWvgEiQKl78Y8fDu/tcb5AHV7/RowNhFd1XjsW18r0wQmK+IsWJxjIhDUiPJ xDy/8EewRxXnuSkM0a0YB/xXNwmymua+yg1TlNmBYo+rzmJ6dtbWLDOUBCDQgNZgZCKC 6eJkes8iZg1a0Enj2YaYTzTUFShMD/CEr+QBL+fxjk4iNgGWMciFBk2/GNAfuHocVUL2 DM80T8xOxpPMEUGXq2lRzhhBs7OjfZ/dxTLx0kVMvsELPQHVTDvAKrmW5Qs9Hj3DDTIh JMIg== X-Gm-Message-State: AElRT7GOh7ALXYd6KpB/0y8GieQTi959pDo/BJmMjQsYcUj0QK53n0N9 0z0ebKOiH/vbI5Z64xaXzTKtaZbz7xztx1S04Y25AQ== X-Google-Smtp-Source: AIpwx489eTj2BeSnwJI9edvEx5tsKdxACGRM3PvpVJrFXI1DwBZoKE4D2TCnWgi6/funGm6nDfBbUb2qxa+P12P8Pis= X-Received: by 10.176.95.93 with SMTP id z29mr6750270uah.87.1522360989944; Thu, 29 Mar 2018 15:03:09 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> In-Reply-To: From: Justin Uberti Date: Thu, 29 Mar 2018 22:02:58 +0000 Message-ID: To: Bernard Aboba Cc: Stephen Farrell , RTCWeb IETF Content-Type: multipart/alternative; boundary="f403045fe14c0724770568944a27" Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2018 22:03:24 -0000 --f403045fe14c0724770568944a27 Content-Type: text/plain; charset="UTF-8" Correct, and I think there are two distinct scenarios being conflated in this discussion. 1) Web pages who aren't using WebRTC for communication, and therefore don't call getUserMedia (Bernard's scenario) 2) Web pages who are using WebRTC for communication, and typically do call getUserMedia. This document attempts to prevent sites in scenario 1) from having access to all IP addresses, and I believe does so successfully. There is of course the question of whether sites in scenario 2) should have access to all IP addresses. Some observations: 1) This problem is not specific to web browsers. Existing mobile apps already have access to all IP addresses. 2) The 'right' behavior here is situation-dependent. As an example, should a user on a VPN send their media traffic over the VPN or not? One can construct a valid rationale for either position. 3) In the event where specific behavior is desired, this document does provide specific modes to allow browsers or extensions to select the desired behavior. As such, I believe a full treatment of scenario 2 is out of scope of this document, and the existing options presented in the document are sufficient. On Thu, Mar 29, 2018 at 2:29 PM Bernard Aboba wrote: > Stephen Farrell said: > > "So it's all a bit of a fig leaf IMO." > > [BA] Correct me if I'm missing something, but there are a class of abusive > applications that don't even pretend to support realtime communications and > don't call getUserMedia (probably so as not to give the user an inkling of > what they are up to). > > So while there is some leeway to argue about the meaning of "consent" for > an application that actually utilizes the WebRTC APIs for communications > between browsers, there are a class of abusive applications that don't > fulfill even the most liberal definition of "consent". > > On Wed, Mar 7, 2018 at 2:51 PM, Stephen Farrell > wrote: > >> >> >> On 07/03/18 22:35, Justin Uberti wrote: >> >>> In addition, while gUM consent is given as an example, it is not >> >> normative. >> >>> Mode 1 MUST only be used when user consent has been provided. The >> >>> details of this consent are left to the implementation; one >> potential >> >>> mechanism is to tie this consent to getUserMedia consent. >> >> Sure. OTOH, IIUC, that is what's done in web browsers so it kind >> >> of really is normative, in practice. Again, apologies if there >> >> are other things done in browsers. >> >> >> > I believe that the Brave browser uses Mode 4 in its private browsing >> mode. >> > https://github.com/brave/browser-laptop/issues/260 >> >> Interesting, didn't know that and good to see. >> >> OTOH, still the vast majority of web browsers will I assume >> do mode 1 for the vast majority of webrtc calls. >> >> So it's a bit of a fig leaf IMO. >> >> S. >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --f403045fe14c0724770568944a27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Correct, and I think there are two distinct scenarios bein= g conflated in this discussion.
1) Web pages who aren't using WebRT= C for communication, and therefore don't call getUserMedia (Bernard'= ;s scenario)
2) Web pages who are using WebRTC for communication,= and typically do call getUserMedia.=C2=A0

This do= cument attempts to prevent sites in scenario 1) from having access to all I= P addresses, and I believe does so successfully.

T= here is of course the question of whether sites in scenario 2) should have = access to all IP addresses. Some observations:
1) This problem is= not specific to web browsers. Existing mobile apps already have access to = all IP addresses.
2) The 'right' behavior here is situati= on-dependent. As an example, should a user on a VPN send their media traffi= c over the VPN or not? One can construct a valid rationale for either posit= ion.
3) In the event where specific behavior is desired, this doc= ument does provide specific modes to allow browsers or extensions to select= the desired behavior.

As such, I believe a full t= reatment of scenario 2 is out of scope of this document, and the existing o= ptions presented in the document are sufficient.


On Thu, Mar 29, 2018 at 2:29 PM Bernar= d Aboba <bernard.aboba@gmail.= com> wrote:
Stephen Farrell said:=C2=A0

"So it's all a bit= of a fig leaf IMO."=C2=A0
=C2=A0
[BA] Correct me = if I'm missing something, but there are a class of abusive applications= that don't even pretend to support realtime communications and don'= ;t call getUserMedia (probably so as not to give the user an inkling of wha= t they are up to).

So while there is some leeway t= o argue about the meaning of "consent" for an application that ac= tually utilizes the WebRTC APIs for communications between browsers, there = are a class of abusive applications that don't fulfill even the most li= beral definition of "consent".=C2=A0

On Wed, Mar 7, 2018 at 2:51 PM, St= ephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
=


On 07/03/18 22:35, Justin Uberti wrote:
>>> In addition, while gUM consent is given as an example, it is n= ot
>> normative.
>>>=C2=A0 =C2=A0 Mode 1 MUST only be used when user consent has be= en provided.=C2=A0 The
>>>=C2=A0 =C2=A0 details of this consent are left to the implement= ation; one potential
>>>=C2=A0 =C2=A0 mechanism is to tie this consent to getUserMedia = consent.
>> Sure. OTOH, IIUC, that is what's done in web browsers so it ki= nd
>> of really is normative, in practice. Again, apologies if there
>> are other things done in browsers.
>>
> I believe that the Brave browser uses Mode 4 in its private browsing m= ode.
> https://github.com/brave/browser-laptop/issue= s/260

Interesting, didn't know that and good to see.

OTOH, still the vast majority of web browsers will I assume
do mode 1 for the vast majority of webrtc calls.

So it's a bit of a fig leaf IMO.

S.



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb


--f403045fe14c0724770568944a27-- From nobody Thu Mar 29 20:48:48 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D414D129C5D for ; Thu, 29 Mar 2018 20:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 R8vAZGKmYvsy for ; Thu, 29 Mar 2018 20:48:46 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (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 0D04E124205 for ; Thu, 29 Mar 2018 20:48:46 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id 80so7033132wrb.2 for ; Thu, 29 Mar 2018 20:48:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:openpgp:cc:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=5EwMwCDkOO/Wm+I2/Guv0kz+l4ZgJ8a6QdL2sTN4MI4=; b=cvli9dFVoGHADQRWGiSJQWtCeLMsI++fxemfk4J/GC1tIU27WZINlc8uxYGPlkx6/S uUoVeTHFBoy2aT0YQanVcntSeCrmKlr0qC8jgd3QLcrmUWb1GM8FR7LgDa9xOAUGzuGp OiYF6/NC8YX0X4jqEjBP45qQHkKlYhBmSqGOqrhwc4CyNajNVFc1WYO/19Qh6zmPlgUj +xuhY8gPxHCkQbeC/kuYF/a2CkhHco10ELbXmgtj5MSQohPtm74VY19RglvqnuSZMSF+ nMaXUXhOH6+Fbd8VUxQNIgEjtGRkBily5411A0S3NYZcJvBooCvWWa0XKDNbsCRWZDj0 +O+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:cc:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5EwMwCDkOO/Wm+I2/Guv0kz+l4ZgJ8a6QdL2sTN4MI4=; b=aLVHu2Ye8pSIjAhMMp0ZH8ywyH1JqVDPXAm2+82bIeRpi+kuoOiO21sJRUNucQdsdO KmMVBggLl9ebpmVpXlTmQUppU+pOLnfNLEe2YrS8ikpzh6cXzY56i5y3UzN+7i1BjU91 lwSscPrh8KRPxp3noztDscnY0Is4CKK5BMHg62loNvfExJVB34QrTM4m7xoCuEq0qEBj NTNzNw2A2XqgH2q4dqo1TtK3G77jrJnmIOnB3qubk/vygItTT1OI7YKbdilMl+A8KtOZ jshWzNLyh/X9+5Psf+fI2qlu+SCFjKZ5IHgUVk7hxbpo0WFNlp/9q+5Mu9IYuFGB6KG0 IytA== X-Gm-Message-State: AElRT7G+KuhAvlK+X8c0W1daymQSgrmyuAiaQyHZrXUogLAT8kLZB4k1 Z4HH41v89eCMPL7sdQlntWR4bQ== X-Google-Smtp-Source: AIpwx4/S7BTanX7srSRRut9rbN4O+4F073ExnDi07Gnsef1Cvqa8D9zQVd6zbMT0aRW6gt1Il5miFA== X-Received: by 10.223.156.206 with SMTP id h14mr7710750wre.281.1522381724412; Thu, 29 Mar 2018 20:48:44 -0700 (PDT) Received: from ?IPv6:2003:cd:6bc2:9a00:6944:64ab:75ab:e226? ([2003:cd:6bc2:9a00:6944:64ab:75ab:e226]) by smtp.gmail.com with ESMTPSA id l73sm10846735wma.10.2018.03.29.20.48.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Mar 2018 20:48:43 -0700 (PDT) To: rtcweb@ietf.org References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> From: Lennart Grahl Openpgp: preference=signencrypt Cc: Justin Uberti Message-ID: <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> Date: Fri, 30 Mar 2018 05:48:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2018 03:48:48 -0000 On 30.03.2018 00:02, Justin Uberti wrote: > As such, I believe a full treatment of scenario 2 is out of scope of this > document, and the existing options presented in the document are sufficient. I would agree with you that the document is sufficient when it comes to the modes it provides (even though the clever mDNS experiment Apple runs at the moment might be worth adding to mode 2 and 3 if proven successful). But the more I think of it, the less I agree with the "consent" part of the document, especially this particular statement: > [...] one potential mechanism is to tie this consent to getUserMedia consent It's a "potential mechanism" that has been gladly accepted by all browser vendors, let's face it, probably because it's easy and it seemed to work well for many use cases. But it's showing its weaknesses: 1. It discriminates various use cases (just one example: a peer-to-peer file sharing application using data channels, potentially in the same network), and 2. assumes the user is okay with mode 1 when the application gets capture permissions. Cullen pointed out that this may be a false assumption in some cases. Now, even though the document states that mode 2 SHOULD be used if no consent has been given (and that would be fine for the majority of use cases I have in mind), we're already seeing browsers going for mode 3 when no "consent" is available. But the only form of "consent" we have at the moment is getUserMedia. That makes it a problem for the use cases that simply cannot utilise those permission requests. And the impact of being forced to NAT hairpinning or even TURN can be much higher than it would be for an audio/video conference. Thus, the implementations in the browsers based on the suggestion in this document already hinder some interesting use cases. I'm fine with the modes, I don't have a strong opinion on whether or not an IETF document should include some form of "consent". But I do have a problem with the suggestion to use getUserMedia. Can we maybe remove it? Cheers Lennart From nobody Fri Mar 30 15:12:14 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9596127342 for ; Fri, 30 Mar 2018 15:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 TyvqVCHhHked for ; Fri, 30 Mar 2018 15:12:12 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 D3630126DFB for ; Fri, 30 Mar 2018 15:12:11 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id s48so10534148qtb.10 for ; Fri, 30 Mar 2018 15:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+Q+0yVpXBXN1h3JpKoCh0qi0JEyIMv6TC3qBw3ct/9g=; b=KsT6IZ2TUeO0kB9laEp136K7W2pUYX+wwDBQosDtmusp1J9tqxlFfUhAghuAN1y27q oO2wAcs4CcDzK/2ononmfJKOlk/53trrCSVd848BJgdu0WzHe5vXFmqQ9AsPVPCXqMHu m7xBKtQeVta7iXfgpwuDw1ncrw6Y2DmVNGPkY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+Q+0yVpXBXN1h3JpKoCh0qi0JEyIMv6TC3qBw3ct/9g=; b=UIPe+mCE9ShD445LZ/vR2eFq/mMKLCqzHDslA6NPdhD5mMM3MNTDLcqQHyiSDmUDGF ca5kW9gaxdu/M3n51UsIKP4Lk0w4DbV7MGE/G0RnlsKcJ2fhGc/GhYnXCA4ZYARwbET7 UnfbIVdD1Agf51olXtx6zVowHwsZ1n0FZwD52aTBCQJlskSlXJxpmcp03xNrAWCGOJk6 1AGi1SeSAnFR7ueTyBB43uqJk7EWy1EBKKYf5fq4iYDDiDkfxJLDKdMuh02GKIwgECiH vuUKk6nk4fUtKm4yb0Lk/MzzRgE4Fyie+CsMJp+OF4XVd3GhgW9nb466uOq+JjjQaImR QprA== X-Gm-Message-State: ALQs6tCvtMA9T6emp2AKiHD2z6LS+0Vu+/jSkjuv1TlVh1xbI1l/lT3W 2R4cIbA8nkN4aYpvjau+PyF5uA== X-Google-Smtp-Source: AIpwx4+C6q32U5XgUuyI1PO7P+GSRzVD76qe31nDnWangc2ysokBCNELwfqWqxcXZgG3LJbBA1O+kw== X-Received: by 10.200.27.3 with SMTP id y3mr1107013qtj.161.1522447930828; Fri, 30 Mar 2018 15:12:10 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id u4sm6019062qka.47.2018.03.30.15.12.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Mar 2018 15:12:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Turner In-Reply-To: <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> Date: Fri, 30 Mar 2018 18:12:08 -0400 Cc: rtcweb@ietf.org, Justin Uberti Content-Transfer-Encoding: quoted-printable Message-Id: <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> To: Lennart Grahl X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2018 22:12:14 -0000 > On Mar 29, 2018, at 23:48, Lennart Grahl = wrote: >=20 > I'm fine with the modes, I don't have a strong opinion on whether or = not > an IETF document should include some form of "consent". But I do have = a > problem with the suggestion to use getUserMedia. Can we maybe remove = it? As the draft shepherd, I=E2=80=99m trying to figure out how to draw this = WGLC to a close all in the hopes that we can help each other get this = RTCweb WG ship docked. As far as dropping the getUserMedia suggestion, I=E2=80=99m a little = hesitant to just drop it at this late date. That suggestion has been in = the draft since October 2016 and it=E2=80=99s stood the test of a couple = of WG reviews; not last calls mind you but there=E2=80=99s been plenty = of time for folks to say get that outta there. And technically, it=E2=80=99= s just a suggestion with no normative language. So =E2=80=A6 maybe a = happy middle ground is to have another suggestion so that there=E2=80=99s = more than one potential mechanism? spt= From nobody Fri Mar 30 15:12:20 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F2D127342 for ; Fri, 30 Mar 2018 15:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522447934; bh=GkjVe4rAnbRW3H/3UIubhFsinhnL698cZJgPvECbdag=; h=Subject:From:In-Reply-To:Date:References:To:Cc:Cc; b=mEaMOGYKmj5wtpw85OpmZJnYOBaT6XPVRkaq7WgxWDZ7yFsmep8nCysmjM2vtElsg v51e2YufW+F1r3Ung+eNubE7UbrEhdBb0D9S6Djds4IONC6y8Spq7HaWe5IGFZmc3+ OUtQ3sn+oz+8xzLYBfhlc8EhIFTRTxlk349h4DvQ= X-Mailbox-Line: From sean@sn3rd.com Fri Mar 30 15:12:14 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23333126CE8; Fri, 30 Mar 2018 15:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522447934; bh=GkjVe4rAnbRW3H/3UIubhFsinhnL698cZJgPvECbdag=; h=Subject:From:In-Reply-To:Date:References:To:Cc:Cc; b=mEaMOGYKmj5wtpw85OpmZJnYOBaT6XPVRkaq7WgxWDZ7yFsmep8nCysmjM2vtElsg v51e2YufW+F1r3Ung+eNubE7UbrEhdBb0D9S6Djds4IONC6y8Spq7HaWe5IGFZmc3+ OUtQ3sn+oz+8xzLYBfhlc8EhIFTRTxlk349h4DvQ= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09BC126DFB for ; Fri, 30 Mar 2018 15:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 JCcBs9Omt9DE for ; Fri, 30 Mar 2018 15:12:11 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 C046D126CE8 for ; Fri, 30 Mar 2018 15:12:11 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id j26so10534553qtl.11 for ; Fri, 30 Mar 2018 15:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+Q+0yVpXBXN1h3JpKoCh0qi0JEyIMv6TC3qBw3ct/9g=; b=KsT6IZ2TUeO0kB9laEp136K7W2pUYX+wwDBQosDtmusp1J9tqxlFfUhAghuAN1y27q oO2wAcs4CcDzK/2ononmfJKOlk/53trrCSVd848BJgdu0WzHe5vXFmqQ9AsPVPCXqMHu m7xBKtQeVta7iXfgpwuDw1ncrw6Y2DmVNGPkY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+Q+0yVpXBXN1h3JpKoCh0qi0JEyIMv6TC3qBw3ct/9g=; b=Zev7bYB2UrD/AUYwFWorFO5H01s2DfIx/ZXtfn/yNrsQ1NZTN1m3Ok7F8UFBI4GMW4 U64dRPlJh0IdvHrYPmuB3vECr9WX7rZnxvULXi7bINx0mNoEqGcVMy2Op7DYlPaY3MPY M/TG9PeIJAjBjo6Ml0i9a8MkkUt/XoRfAQVCUe2bFMrtB7GoPTH6hFfb7p5qWZIv2FMF AW+qXXhoieGeP4rQOi9wzuT2ViiqW9lf6209PuRmAU/mZS7cEe5DPQ1Aog+u7yUJrXMC 7V3HMWG1GbBXsb0FF1Xeo9K6vEyjtwVIxW/MbXd+Y2jZkSMendmj1kEJEyB7iNTCd7Dc huDg== X-Gm-Message-State: ALQs6tAHq32M/YoCzC2/pDK4VsVEWuP4bTjL8IHBfLx8tkU98TtT7+Zg 09oh3vGdrAkB5IikuWg2VX/x4g== X-Google-Smtp-Source: AIpwx4+C6q32U5XgUuyI1PO7P+GSRzVD76qe31nDnWangc2ysokBCNELwfqWqxcXZgG3LJbBA1O+kw== X-Received: by 10.200.27.3 with SMTP id y3mr1107013qtj.161.1522447930828; Fri, 30 Mar 2018 15:12:10 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id u4sm6019062qka.47.2018.03.30.15.12.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Mar 2018 15:12:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Turner In-Reply-To: <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> Date: Fri, 30 Mar 2018 18:12:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> To: Lennart Grahl X-Mailer: Apple Mail (2.3445.6.18) Cc: rtcweb@ietf.org Cc: Justin Uberti Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2018 22:12:14 -0000 > On Mar 29, 2018, at 23:48, Lennart Grahl = wrote: >=20 > I'm fine with the modes, I don't have a strong opinion on whether or = not > an IETF document should include some form of "consent". But I do have = a > problem with the suggestion to use getUserMedia. Can we maybe remove = it? As the draft shepherd, I=E2=80=99m trying to figure out how to draw this = WGLC to a close all in the hopes that we can help each other get this = RTCweb WG ship docked. As far as dropping the getUserMedia suggestion, I=E2=80=99m a little = hesitant to just drop it at this late date. That suggestion has been in = the draft since October 2016 and it=E2=80=99s stood the test of a couple = of WG reviews; not last calls mind you but there=E2=80=99s been plenty = of time for folks to say get that outta there. And technically, it=E2=80=99= s just a suggestion with no normative language. So =E2=80=A6 maybe a = happy middle ground is to have another suggestion so that there=E2=80=99s = more than one potential mechanism? spt= From nobody Fri Mar 30 16:04:39 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9E61200C5 for ; Fri, 30 Mar 2018 16:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 mSaBsvPfC0Mz for ; Fri, 30 Mar 2018 16:04:35 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 B40251272E1 for ; Fri, 30 Mar 2018 16:04:34 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id w6so10325828qkb.4 for ; Fri, 30 Mar 2018 16:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5M0OycS/A3sE9lPXPOJe4vZdMyAr01cFviohlDWSzCI=; b=DO8y4G0orFlD3enIfm7hbZwPeLfHk491l0MMTsUAD9BhigbEey/iNqGRxVYJbScjnA fBhEY04VNSN09HoTdztkKZW7kjvhAtC0L7z8v9UIMEPjfu1jSnqzRvTR7xIifJSjHWqj sgFZmgGt6P0nf/e21EslWGLz6uwZRb55b6fww= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5M0OycS/A3sE9lPXPOJe4vZdMyAr01cFviohlDWSzCI=; b=ryfvn2DlkAdty40ZK0O4O8s/8lKhBo9CP2uDcxSXXFu3dCR61w9t1KdE7YwSleNIk3 YIFQ7Mtb3u3OVBplJ54T6buYhvMkpwmF/cv9bxNW0QSh6InQ4XJqybXF6q3ALr7UcLAN JYSfdYuat9h0i2bCmC71kOHTEsLtfZBN1Yl3wekhBv8rK8xh3Ui55sAGUq5CZ/f/qOhy i7C493iSq388Xt6HI+7HqJ/72DgxsQV9wQ/KHWtY5Wt8U3y0GcSB70LU6l0fQhmfChQH wo9kyArOokAEwFB9QevfxTwXm4/FqIJAT1ukKGcOhGMKVnNQwsVISNinNdDF+LOHlGGM qjJQ== X-Gm-Message-State: ALQs6tDrhp0MAGQCPNyLvRCByvPp8jkQyzVenKnyj9YyQB6ysILiVjjG LOyc6OipK9eI901nQTgyxLnTLw== X-Google-Smtp-Source: AIpwx4+VWWYG2/iE33WbgOEBw1EZPPhUTfpvYlTIsCANCZn0vUX3MRLOemWPGezBH4Hj+xYm3lDKDg== X-Received: by 10.55.185.69 with SMTP id j66mr1261542qkf.216.1522451073764; Fri, 30 Mar 2018 16:04:33 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id l124sm6763194qkc.1.2018.03.30.16.04.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Mar 2018 16:04:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Turner In-Reply-To: Date: Fri, 30 Mar 2018 19:04:31 -0400 Cc: Sergio Garcia Murillo , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <059F139E-B586-4587-B6C1-B3FB7A8AEF83@sn3rd.com> References: <7fe32dcf-23da-b0fb-cd53-d8bba2ad2662@gmail.com> <2a21956e-cf9e-d185-8041-78e1ad332d3a@gmail.com> <7394bf9b-3101-1ac6-e2ea-202b78d5c936@gmail.com> <9cccc0b9-7f54-41d4-d3d4-eff174b4b3fc@gmail.com> <3DFDEC10-38D1-4D5E-A638-EB484872CDED@westhawk.co.uk> <5d59eec9-62d6-94e4-517e-da6d0b9e3c41@gmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] Possible identity security vulnerability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2018 23:04:37 -0000 I think this might somewhat be addressed here: https://tools.ietf.org/html/draft-ietf-rtcweb-security-10#section-4.4.1 spt > On Mar 19, 2018, at 10:43, Martin Thomson = wrote: >=20 > As a practical matter, if the browser were to use the same certificate > for multiple origins, then it would create a massive privacy problem > that enables linkability (aka user tracking). I couldn't find that > written down, but I thought it was. If it isn't written down, then we > should correct that. >=20 > On Mon, Mar 19, 2018 at 1:57 PM, Sergio Garcia Murillo > wrote: >> On 19/03/2018 14:45, westhawk wrote: >>=20 >> On 19 Mar 2018, at 13:40, Martin Thomson = wrote: >>=20 >> It's anything that *the site* initiates (not so much the browser). >> Certificates are origin-scoped. >>=20 >> Are they? is the private key needed in the re-use of the assertion? >> (I haven=E2=80=99t looked at this for ages) >> If not the you could push the ASN1 of the public cert somewhere not = scoped >> to the >> origin and have another site re-use it. (e.g. transfer it to an = advert >> iframe with postmessage) >>=20 >>=20 >> After checking if further, that may not be clearly explicit on the = webrtc >> w3c spec: >>=20 >> For the purposes of this API, the [[Certificate]] slot contains = unstructured >> binary data. No mechanism is provided for applications to access the >> [[KeyingMaterial]] internal slot. Implementations MUST support = applications >> storing and retrieving RTCCertificate objects from persistent = storage. In >> implementations where an RTCCertificate might not directly hold = private >> keying material (it might be stored in a secure module), a reference = to the >> private key can be held in the [[KeyingMaterial]] internal slot, = allowing >> the private key to be stored and used. >>=20 >> So it is not clear to me if certificates are origin-scoped or if the = key >> materials could be exported outside of the browser. Worst case, = certificate >> could be exported and identity assertion reused even by a different = service. >>=20 >> Best regards >> Sergio >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sat Mar 31 03:18:11 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5484012D574 for ; Sat, 31 Mar 2018 03:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 q3oaXJed-UYm for ; Sat, 31 Mar 2018 03:18:06 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 8BB8812D0C3 for ; Sat, 31 Mar 2018 03:18:06 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id r131so19919340wmb.2 for ; Sat, 31 Mar 2018 03:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MN/PIz8T1kB8qRAspGMkn2dvrs0pGdfCDmjeb3QsINs=; b=eOZrfU6K/C+ou8fAMfk+pZ9+2rIIFKpfDEO7R18raXa79veZD+yhojrldOe7IYzzco AZP1I4cSqASocTc4Af+4ZpRemPJiTcLVBrEizYp6mMGpFprXIFAsJ9ddaAfMwdJZQb5/ dgF3Eijnvm548J7pHmBtfqiUlDFQ/oHAXT8r8Q5NiCCc167ekG/ZA/h+NFvRVvxpcYlM jneUg8oS380AwteTpspf5GmscT89npY6Pr8v88Cw4hM44+0UB7MIaSgfTBkL5huodFO4 DgzEmtKDE9Bo9bZefQAcJ3dB0asrkgP3MQ7T+g1p3W3+W3etUJ3xhbDlyt+FwZypQ85w Vqxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=MN/PIz8T1kB8qRAspGMkn2dvrs0pGdfCDmjeb3QsINs=; b=S/CqXtQ661TwoqaBxFODs7pwcIVMycIcKyEuFTdlruZHoU4JV3XLGR4wS+6XTg3XWi iXdWyTTzcXHbpsATDzA/9iDeLmrronZ1MCqIB2xmLg47kjA6xge0MsO9pwG/dq439+ks Zw8/qtg+VQplLyEwcv5k3hEDvDh4jr1L5JIvE+Q6gRHuQ828J90rXinMwES8gQb5TVRg SYxUluYdpLogDkxQ9Vjuy//2Wi2f6x43MblYA8SNlWkdrDW4Tb+rO1orjeOuEzxeNuRT 3QKDec3jY70miUCN3tsn4M2yaKxiW1eC4oci70AWmyTm1XxiK2Q3p3APv8rKmVG87/xU QG+Q== X-Gm-Message-State: AElRT7EiN3kjSi+AmjVqIRue5YQzuz8p6zXLeDdMFKCmCpZ9q2r9Kbc9 npjbN5JTHG2gtkIRe6T1Mzg= X-Google-Smtp-Source: AIpwx48lstHY1WebkO9bw+rQ2lkc8V1LmBumkyPbUBaEuca2wGHCiJsmCixtepld5S39ynYt1fMVbA== X-Received: by 10.80.163.196 with SMTP id t4mr5837250edb.202.1522491485043; Sat, 31 Mar 2018 03:18:05 -0700 (PDT) Received: from [192.168.44.248] (tmo-101-79.customers.d1-online.com. [80.187.101.79]) by smtp.gmail.com with ESMTPSA id v9sm6300364edi.16.2018.03.31.03.17.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 31 Mar 2018 03:17:58 -0700 (PDT) To: Sean Turner Cc: rtcweb@ietf.org, Justin Uberti References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> From: Lennart Grahl Openpgp: preference=signencrypt Autocrypt: addr=lennart.grahl@gmail.com; keydata= xsBNBFMHjy4BCADZR/nHk6jzDsEA2+dPG13NiXyBl34TtChDsZekZyO5jBgwslLgHVksQxlS 79n1lvVH0MxcI8SFifwLAAIjMfukNLGPAjEyJEQhQVpfXxkJXyZgncM2Wq+nlVCDZTiZLg/E 6jJP1zx9vB7sf5dWaB/Dt0YDHLM86EcDChQur9lrJk9K0Jiwt27Oo3B4FFfIOaVNUXgnRPbr Vw1/+O2jLg87Fsib9LP7Ghyv0Z2/VV7wJ4NLsLmIu60vcZVDYDOvcQRH4FZ76VBvlmlO+2TL 5L6yZLGgXS9GZyF3QXKAwhYqu5ouWEOUgXHch5deryjbENanimj4ntZQmF1nkxSZayk9ABEB AAHNJ0xlbm5hcnQgR3JhaGwgPGxlbm5hcnQuZ3JhaGxAZ21haWwuY29tPsLAfwQTAQIAKQUC UwePLgIbIwUJCWYBgAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEPmPvtEEgqumkk0H /2dMGPa9VmgR0kmr2inGODWuCy4WXNUxeEMfY/Hob/8Ou50os6iK35TQI9WtvvlAq23aIvoJ +1OjnqekgKmavPoQ0Uf1h2LegiQNKpDGC6/S33SLitQoQyELyJCU5Ato9lIL0AzpLvr+8UaF plWbPB4Z0GfZGBQSyp0Dmdeb00sld378m9qXHByJfHjPGiDFY+el1talbCuxS87+SvwIvM05 5m1/ceJbZDjx3trvgzbSQOHMT82/Hva7cSyVAch7mJc/lIq2Q0hjoZlD9nqS6gVJ9PQnEW8z dAXXVvBoy9DtomH18jimq+xUxeBwiFRB64gZx3Yyo1CKgULzeWaQ/qfOwE0EUwePLgEIAKP+ Dw5Ow5QuITKcI+ooXZAOBCBOitdsAGrGAEORjv1VyYU1jvjNb07UlRWmpjtaZsQoC2DwfEJy OaBphhErkOVEHCvetfBq8aJ718on4A49XwyQZeyh521BvLQUj0VY5D1iTYzgNVr4Ic39duH/ 00b489Wf9sM7TwzONJOCR5pSKUzYfGUIfQIJRc4tbzOM+bzSknLwbYAWRraOstbRjf2+V3pf 46mzv8tteLnsMm91qshFUwiBfeMNZiKAM3eid80ghlEbQo5J07FOrqK1GxqMi8LQT/oA5lpu +BB6UzGP5nQ5fip95zAq3vu+Iasz1DWj6F1HkHDEHfdtVpTAN70AEQEAAcLAZQQYAQIADwUC UwePLgIbDAUJCWYBgAAKCRD5j77RBIKrpihiCACQq7ARCPSzDrtUcq3uTdP+fMHp8YCYD4UD fdt3vcw4a5JESaknUcWi7CbQrdcLT7iIFYa3pk5I8w4n2lH29uUTWwt9boDtdYkBY5a4Rg+m Z9ndsLh0fHdZM6BXv/6gWMMdGbV5+xcV0FDcXZIlHLZIriDgeZQR3cDEa9lFWUYrI9KKmdoq ngaND7jPZaMCyvn9VDOAGBWxg49gQV/x1d+DiIyMbF9J+ya4YqaSZtu2y/H03eVCawmI6SMH UzdOo+Yqen3Udcdur0KnWMUOP3FIdjgxaPoIEKfFTBy7n8rlzrrTzyrv5Gouusxj0JHMwvuh ixK1bmVy/XYqoG0TVwBt Message-ID: Date: Sat, 31 Mar 2018 12:17:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2018 10:18:09 -0000 I really don't have a good suggestion other than being completely honest: "Hey user, I want to establish a direct connection - is that okay for you? Oh, and here is a help page that will tell you what impact this may have on your privacy..." These permission requests don't have to be mutually exclusive either. The above request could also be embedded inside the permission request for getUserMedia to avoid multiple requests: Camera to share: [WebCam 3000 |v] :WebCam 3000 : :WebCam 4000 : Direct connection: (?) <-- "help" button [No (Default) |v] :Yes : :Yes, but hide private addresses : :No (Default) : :No, and force using a proxy : [x] Remember the decision for this page [Don't allow] [Allow] Cheers Lennart On 31.03.2018 00:12, Sean Turner wrote: > > >> On Mar 29, 2018, at 23:48, Lennart Grahl wrote: >> >> I'm fine with the modes, I don't have a strong opinion on whether or not >> an IETF document should include some form of "consent". But I do have a >> problem with the suggestion to use getUserMedia. Can we maybe remove it? > > As the draft shepherd, I’m trying to figure out how to draw this WGLC to a close all in the hopes that we can help each other get this RTCweb WG ship docked. > > As far as dropping the getUserMedia suggestion, I’m a little hesitant to just drop it at this late date. That suggestion has been in the draft since October 2016 and it’s stood the test of a couple of WG reviews; not last calls mind you but there’s been plenty of time for folks to say get that outta there. And technically, it’s just a suggestion with no normative language. So … maybe a happy middle ground is to have another suggestion so that there’s more than one potential mechanism? > > spt > From nobody Sat Mar 31 03:18:15 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8E412D72F for ; Sat, 31 Mar 2018 03:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522491489; bh=O6NmAapYe2aFzW9UmUwc993ts0vdXZ187ejBritdSYc=; h=Subject:To:References:From:Date:In-Reply-To:Cc:Cc; b=Wd1NUXArfy69Xv384IOPXj2l0HB2zOQ9/oIAmL+W14KcZUcqV2S1Le7tPpLHqSciU X+ayWWdk47//uN7QDKmkpEmRPiJ32ja3hx+4SAqUenY3xa6u0ItTbYhpUS7tnjqghf x0eYfMVATnHdas1fA8nW/0ajHf3JbbqVhHx59LLg= X-Mailbox-Line: From lennart.grahl@gmail.com Sat Mar 31 03:18:09 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6365D12D0C3; Sat, 31 Mar 2018 03:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522491489; bh=O6NmAapYe2aFzW9UmUwc993ts0vdXZ187ejBritdSYc=; h=Subject:To:References:From:Date:In-Reply-To:Cc:Cc; b=Wd1NUXArfy69Xv384IOPXj2l0HB2zOQ9/oIAmL+W14KcZUcqV2S1Le7tPpLHqSciU X+ayWWdk47//uN7QDKmkpEmRPiJ32ja3hx+4SAqUenY3xa6u0ItTbYhpUS7tnjqghf x0eYfMVATnHdas1fA8nW/0ajHf3JbbqVhHx59LLg= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3383C12AF84 for ; Sat, 31 Mar 2018 03:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 9V3HK8iSwf2w for ; Sat, 31 Mar 2018 03:18:07 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 E23DF12D574 for ; Sat, 31 Mar 2018 03:18:06 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id f125so19908945wme.4 for ; Sat, 31 Mar 2018 03:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MN/PIz8T1kB8qRAspGMkn2dvrs0pGdfCDmjeb3QsINs=; b=eOZrfU6K/C+ou8fAMfk+pZ9+2rIIFKpfDEO7R18raXa79veZD+yhojrldOe7IYzzco AZP1I4cSqASocTc4Af+4ZpRemPJiTcLVBrEizYp6mMGpFprXIFAsJ9ddaAfMwdJZQb5/ dgF3Eijnvm548J7pHmBtfqiUlDFQ/oHAXT8r8Q5NiCCc167ekG/ZA/h+NFvRVvxpcYlM jneUg8oS380AwteTpspf5GmscT89npY6Pr8v88Cw4hM44+0UB7MIaSgfTBkL5huodFO4 DgzEmtKDE9Bo9bZefQAcJ3dB0asrkgP3MQ7T+g1p3W3+W3etUJ3xhbDlyt+FwZypQ85w Vqxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=MN/PIz8T1kB8qRAspGMkn2dvrs0pGdfCDmjeb3QsINs=; b=lUyNo8XKzyMqci7MnK6P3K33iLj96bFeilF7JFgCxoOAReW8qHQ+252M7S3Hm8O9Ub 7vem75Q2nJXM2dP7w46WnRRBhZlBwu9A/exGUETjfQp+yRNhH8zK0NCj24dprftYJNo9 /qL7hsfj5ItiDK/UwGlL6N9PkO7y454JfwS4Ht/qYUFlOemeJf3d4OFv/IupF7eTi1pJ lT2YoJxE1V3h6RSu8NjXGjPP3f1E8Lt7KCKe3WEXNLabJatA1qlKCGfY+jNgxpI1WWbk nLRhjXzWLd1Mt8A3smlzULyBbav2PS3NLl+7t9ocSZWaLyIXpx5G86hKLjKqfw2+vZq/ PiJA== X-Gm-Message-State: AElRT7Ft1gmTBMitAkPN9CkEQFud/mwKsYcaDv4GFsmB0Qj/ymJI4FM5 hJ7gIJ1zchC5eV3rMEUXvxwRVrFD/y4= X-Google-Smtp-Source: AIpwx48lstHY1WebkO9bw+rQ2lkc8V1LmBumkyPbUBaEuca2wGHCiJsmCixtepld5S39ynYt1fMVbA== X-Received: by 10.80.163.196 with SMTP id t4mr5837250edb.202.1522491485043; Sat, 31 Mar 2018 03:18:05 -0700 (PDT) Received: from [192.168.44.248] (tmo-101-79.customers.d1-online.com. [80.187.101.79]) by smtp.gmail.com with ESMTPSA id v9sm6300364edi.16.2018.03.31.03.17.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 31 Mar 2018 03:17:58 -0700 (PDT) To: Sean Turner References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> From: Lennart Grahl Openpgp: preference=signencrypt Autocrypt: addr=lennart.grahl@gmail.com; keydata= xsBNBFMHjy4BCADZR/nHk6jzDsEA2+dPG13NiXyBl34TtChDsZekZyO5jBgwslLgHVksQxlS 79n1lvVH0MxcI8SFifwLAAIjMfukNLGPAjEyJEQhQVpfXxkJXyZgncM2Wq+nlVCDZTiZLg/E 6jJP1zx9vB7sf5dWaB/Dt0YDHLM86EcDChQur9lrJk9K0Jiwt27Oo3B4FFfIOaVNUXgnRPbr Vw1/+O2jLg87Fsib9LP7Ghyv0Z2/VV7wJ4NLsLmIu60vcZVDYDOvcQRH4FZ76VBvlmlO+2TL 5L6yZLGgXS9GZyF3QXKAwhYqu5ouWEOUgXHch5deryjbENanimj4ntZQmF1nkxSZayk9ABEB AAHNJ0xlbm5hcnQgR3JhaGwgPGxlbm5hcnQuZ3JhaGxAZ21haWwuY29tPsLAfwQTAQIAKQUC UwePLgIbIwUJCWYBgAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEPmPvtEEgqumkk0H /2dMGPa9VmgR0kmr2inGODWuCy4WXNUxeEMfY/Hob/8Ou50os6iK35TQI9WtvvlAq23aIvoJ +1OjnqekgKmavPoQ0Uf1h2LegiQNKpDGC6/S33SLitQoQyELyJCU5Ato9lIL0AzpLvr+8UaF plWbPB4Z0GfZGBQSyp0Dmdeb00sld378m9qXHByJfHjPGiDFY+el1talbCuxS87+SvwIvM05 5m1/ceJbZDjx3trvgzbSQOHMT82/Hva7cSyVAch7mJc/lIq2Q0hjoZlD9nqS6gVJ9PQnEW8z dAXXVvBoy9DtomH18jimq+xUxeBwiFRB64gZx3Yyo1CKgULzeWaQ/qfOwE0EUwePLgEIAKP+ Dw5Ow5QuITKcI+ooXZAOBCBOitdsAGrGAEORjv1VyYU1jvjNb07UlRWmpjtaZsQoC2DwfEJy OaBphhErkOVEHCvetfBq8aJ718on4A49XwyQZeyh521BvLQUj0VY5D1iTYzgNVr4Ic39duH/ 00b489Wf9sM7TwzONJOCR5pSKUzYfGUIfQIJRc4tbzOM+bzSknLwbYAWRraOstbRjf2+V3pf 46mzv8tteLnsMm91qshFUwiBfeMNZiKAM3eid80ghlEbQo5J07FOrqK1GxqMi8LQT/oA5lpu +BB6UzGP5nQ5fip95zAq3vu+Iasz1DWj6F1HkHDEHfdtVpTAN70AEQEAAcLAZQQYAQIADwUC UwePLgIbDAUJCWYBgAAKCRD5j77RBIKrpihiCACQq7ARCPSzDrtUcq3uTdP+fMHp8YCYD4UD fdt3vcw4a5JESaknUcWi7CbQrdcLT7iIFYa3pk5I8w4n2lH29uUTWwt9boDtdYkBY5a4Rg+m Z9ndsLh0fHdZM6BXv/6gWMMdGbV5+xcV0FDcXZIlHLZIriDgeZQR3cDEa9lFWUYrI9KKmdoq ngaND7jPZaMCyvn9VDOAGBWxg49gQV/x1d+DiIyMbF9J+ya4YqaSZtu2y/H03eVCawmI6SMH UzdOo+Yqen3Udcdur0KnWMUOP3FIdjgxaPoIEKfFTBy7n8rlzrrTzyrv5Gouusxj0JHMwvuh ixK1bmVy/XYqoG0TVwBt Message-ID: Date: Sat, 31 Mar 2018 12:17:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Cc: Justin Uberti Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2018 10:18:10 -0000 I really don't have a good suggestion other than being completely honest: "Hey user, I want to establish a direct connection - is that okay for you? Oh, and here is a help page that will tell you what impact this may have on your privacy..." These permission requests don't have to be mutually exclusive either. The above request could also be embedded inside the permission request for getUserMedia to avoid multiple requests: Camera to share: [WebCam 3000 |v] :WebCam 3000 : :WebCam 4000 : Direct connection: (?) <-- "help" button [No (Default) |v] :Yes : :Yes, but hide private addresses : :No (Default) : :No, and force using a proxy : [x] Remember the decision for this page [Don't allow] [Allow] Cheers Lennart On 31.03.2018 00:12, Sean Turner wrote: > > >> On Mar 29, 2018, at 23:48, Lennart Grahl wrote: >> >> I'm fine with the modes, I don't have a strong opinion on whether or not >> an IETF document should include some form of "consent". But I do have a >> problem with the suggestion to use getUserMedia. Can we maybe remove it? > > As the draft shepherd, I’m trying to figure out how to draw this WGLC to a close all in the hopes that we can help each other get this RTCweb WG ship docked. > > As far as dropping the getUserMedia suggestion, I’m a little hesitant to just drop it at this late date. That suggestion has been in the draft since October 2016 and it’s stood the test of a couple of WG reviews; not last calls mind you but there’s been plenty of time for folks to say get that outta there. And technically, it’s just a suggestion with no normative language. So … maybe a happy middle ground is to have another suggestion so that there’s more than one potential mechanism? > > spt > From nobody Sat Mar 31 15:27:07 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3075F120725 for ; Sat, 31 Mar 2018 15:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xNMMDEDY4_u for ; Sat, 31 Mar 2018 15:27:04 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 65E0C1200F1 for ; Sat, 31 Mar 2018 15:27:04 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id v134so6628784vkd.10 for ; Sat, 31 Mar 2018 15:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sRv2ECwFkzBtObJBjQMzQQew96r7X+6nzRKUDp9VgfQ=; b=RHfJfVTRGiXd+dpTCc1w+PINjfUEL+0wIT4+a1ppd8bHnfCVjrwt9nLrHaTJE4csLL cZjs7JTWQUMad7d4qaBP848yk/JhcdGgoI+5ZmG7o2eFcVG+FaZic54kfAQ3uDc2kdsQ zzYndnB/IaKk6lvX8GCHx0t8A7eU155O7rO2KCvtKZD15Acj2kkJi9uPtUrZk2DBZh3c wdb5Flh924hyoXplwvQk8qUWY0eetvemgYiBTsF3lqUF0PJxsKcSPgCjfW+yP2tu8RMW HVXrJp6LUkhnCXvp4s/Muj5AV1LwhJPa/SACGB8pEy81uIlbAF3DDXb+Iy5CtTe9s9fx sUOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sRv2ECwFkzBtObJBjQMzQQew96r7X+6nzRKUDp9VgfQ=; b=q1Vxa+L7iasmhL9EBMjdqYEaaO1lKMLv1DnOtk+wrLvUHSFDDNcLl5Tr7nt/j6vJTJ HIOk7IhS5qtmZNk8VkzUiuKr4tEUHff1DDdSPa0FFuMzISf1yrGseMplwkrNK9Vaqc9+ EqGuCYVq2Pus80zhLun2Cl2nwhAhWJjOwWesoCjne0LOoMFNr89HQXFafBQlZv3qpA0T D3EotFXZDgtEwRD5UwMGeyxJ9cekJ2J8+vb91fNro+jrVt00Yi5VlClRamLoeFcOOvMw OhLarEUtgEGtszaWevkDPPcGGzcJfEI+JW2HFWK7Yaw/J1PSqVWIFS5PpbzpiDgiHYOc I0dQ== X-Gm-Message-State: ALQs6tBreJsGqbapXd0K3zlrz7Qe9LLHdUXY0qDfxwHGlkYL3EnXCNKY /8kZTeT/6b7tvw6ZmU/heeL+ZzBQ2OLtllDm1Iamqy7J X-Google-Smtp-Source: AIpwx4+V36hM87N6IlMsP0UfpXKUHbM+cw/exMQ3t84SyeUeJDg1XPnVmrkK7oZliHb7WLhDwGeu9CR/9vnslEDfLBs= X-Received: by 10.31.252.68 with SMTP id a65mr2411829vki.78.1522535222818; Sat, 31 Mar 2018 15:27:02 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> In-Reply-To: From: Justin Uberti Date: Sat, 31 Mar 2018 22:26:50 +0000 Message-ID: To: Lennart Grahl Cc: Sean Turner , RTCWeb IETF Content-Type: multipart/alternative; boundary="94eb2c14c6cc1e04060568bcdb47" Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2018 22:27:06 -0000 --94eb2c14c6cc1e04060568bcdb47 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As stated before, this is not a problem unique to web browsers. That is, by installing a mobile application, you implicitly allow it to use all of your network interfaces. As such, trying to design browser mechanisms for networking consent seems like misdirected effort. Perhaps the key issue here is the word 'consent'. If we replaced this with some notion of 'trust', i.e., that the user has specifically engaged with this app with the intent of having a communications session, maybe that provides a way out, as one can easily claim that installed mobile applications and web apps with gUM rights are 'trusted'. On Sat, Mar 31, 2018 at 3:18 AM Lennart Grahl wrote: > I really don't have a good suggestion other than being completely > honest: "Hey user, I want to establish a direct connection - is that > okay for you? Oh, and here is a help page that will tell you what impact > this may have on your privacy..." > > These permission requests don't have to be mutually exclusive either. > The above request could also be embedded inside the permission request > for getUserMedia to avoid multiple requests: > > Camera to share: > [WebCam 3000 |v] > :WebCam 3000 : > :WebCam 4000 : > > Direct connection: (?) <-- "help" button > [No (Default) |v] > :Yes : > :Yes, but hide private addresses : > :No (Default) : > :No, and force using a proxy : > > [x] Remember the decision for this page > > [Don't allow] [Allow] > > Cheers > Lennart > > On 31.03.2018 00:12, Sean Turner wrote: > > > > > >> On Mar 29, 2018, at 23:48, Lennart Grahl > wrote: > >> > >> I'm fine with the modes, I don't have a strong opinion on whether or n= ot > >> an IETF document should include some form of "consent". But I do have = a > >> problem with the suggestion to use getUserMedia. Can we maybe remove i= t? > > > > As the draft shepherd, I=E2=80=99m trying to figure out how to draw thi= s WGLC to > a close all in the hopes that we can help each other get this RTCweb WG > ship docked. > > > > As far as dropping the getUserMedia suggestion, I=E2=80=99m a little he= sitant to > just drop it at this late date. That suggestion has been in the draft > since October 2016 and it=E2=80=99s stood the test of a couple of WG revi= ews; not > last calls mind you but there=E2=80=99s been plenty of time for folks to = say get > that outta there. And technically, it=E2=80=99s just a suggestion with n= o > normative language. So =E2=80=A6 maybe a happy middle ground is to have = another > suggestion so that there=E2=80=99s more than one potential mechanism? > > > > spt > > > --94eb2c14c6cc1e04060568bcdb47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As stated before, this is not a problem unique to web brow= sers. That is, by installing a mobile application, you implicitly allow it = to use all of your network interfaces. As such, trying to design browser me= chanisms for networking consent seems like misdirected effort.

Perhaps the key issue here is the word 'consent'. If we repl= aced this with some notion of 'trust', i.e., that the user has spec= ifically engaged with this app with the intent of having a communications s= ession, maybe that provides a way out, as one can easily claim that install= ed mobile applications and web apps with gUM rights are 'trusted'.<= /div>

On Sat, Mar 31, = 2018 at 3:18 AM Lennart Grahl <lennart.grahl@gmail.com> wrote:
I really don't have a good suggestion other than being completely=
honest: "Hey user, I want to establish a direct connection - is that okay for you? Oh, and here is a help page that will tell you what impact this may have on your privacy..."

These permission requests don't have to be mutually exclusive either. The above request could also be embedded inside the permission request
for getUserMedia to avoid multiple requests:

Camera to share:
[WebCam 3000 |v]
:WebCam 3000=C2=A0 =C2=A0:
:WebCam 4000=C2=A0 =C2=A0:

Direct connection: (?) <-- "help" button
[No (Default)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 |v]
:Yes=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:
:Yes, but hide private addresses=C2=A0 =C2=A0:
:No (Default)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 :
:No, and force using a proxy=C2=A0 =C2=A0 =C2=A0 =C2=A0:

[x] Remember the decision for this page

[Don't allow] [Allow]

Cheers
Lennart

On 31.03.2018 00:12, Sean Turner wrote:
>
>
>> On Mar 29, 2018, at 23:48, Lennart Grahl <lennart.grahl@gmail.com> wro= te:
>>
>> I'm fine with the modes, I don't have a strong opinion on = whether or not
>> an IETF document should include some form of "consent". = But I do have a
>> problem with the suggestion to use getUserMedia. Can we maybe remo= ve it?
>
> As the draft shepherd, I=E2=80=99m trying to figure out how to draw th= is WGLC to a close all in the hopes that we can help each other get this RT= Cweb WG ship docked.
>
> As far as dropping the getUserMedia suggestion, I=E2=80=99m a little h= esitant to just drop it at this late date.=C2=A0 That suggestion has been i= n the draft since October 2016 and it=E2=80=99s stood the test of a couple = of WG reviews; not last calls mind you but there=E2=80=99s been plenty of t= ime for folks to say get that outta there.=C2=A0 And technically, it=E2=80= =99s just a suggestion with no normative language.=C2=A0 So =E2=80=A6 maybe= a happy middle ground is to have another suggestion so that there=E2=80=99= s more than one potential mechanism?
>
> spt
>
--94eb2c14c6cc1e04060568bcdb47-- From nobody Sat Mar 31 15:44:16 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E339120725 for ; Sat, 31 Mar 2018 15:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPu68fzKn_6F for ; Sat, 31 Mar 2018 15:44:13 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (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 E5E021200F1 for ; Sat, 31 Mar 2018 15:44:12 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id a17so133uaf.13 for ; Sat, 31 Mar 2018 15:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XUuHXpqg7BYGc1tkxHrp9fMfTVooGfyWOl/OsrY7vOE=; b=u3wZyQ/ef61MtUB/zDPrK+Vmi65rcHwvqby0TOzw1sIEd4TxUqdw8GfcsKT4gZjER+ 7iMoLjCyfxWpTXwqa7GkIyjVneqTjbO1YCPb3MLZQEXxaUWwoDZyHZ+5r3rCs/pKaKvb pSYByJcTv87x365hzK5Eqmb+3qJAVpAZZu493eM16ehGfKdIt88Y+Sj4jEf0Z596zRLB wG/fYrdmbefduB9DuzScMaRgJ2wq5el082X5Y5woaXpBq6E72vnDx7UXf68eZsFfaXlK 11N3odeIkpqXyj64NvA7DOuPh3HzFZV2NRkpXG5wRK/1f9IZc/EPbVz9lBg3qpZbCx0X osfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XUuHXpqg7BYGc1tkxHrp9fMfTVooGfyWOl/OsrY7vOE=; b=PgeOLO2Oht4qQ3clgeb3GW3MrPLpDTB4gRzsvPyaojUQC8fq7D3XvC++tHPIR8bENX P4eoWkNlGJWofVoyPc77ReO30w0MT6IRSsfGko+LvNpSf+gLxg0ww0OU+d+NhPkkJXWm pN8tYN0u3bNCjBDTY2CxuycIGCLIzfIa8gD9tlxCadPBist41BE9ISw3KAOZkhfvU1gJ tugxPVdcKlCTqLJHmX+hwYEqdiFzsnFBXwjDy4FhQxDiyALc1johaWuEU20F/vGs6Lk6 IQLC3+LSvzbd/bhvjbhdGzHfMP36XwC7S0DTMiJUpuZ8Vc+k1Dw3DL5Um97kADvUP6Hy uEWQ== X-Gm-Message-State: ALQs6tADOnv5ZPpwUqorxzlcRCUhZVwqc26p3P18701ft6PprldTgh9x CsfIhbgnbnBkk4efAo0mT5MoH4inKP1KtixzaLL4rQ== X-Google-Smtp-Source: AIpwx48JeUFw8NSiW3UrOXokRezkCHHUCcj9q8PJDGVYGoN797SKVsaXl4LWfFM9CuQKW3wQTrAc4JHH9NW3fKfTQjw= X-Received: by 10.176.95.93 with SMTP id z29mr2041056uah.87.1522536251414; Sat, 31 Mar 2018 15:44:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Sat, 31 Mar 2018 22:43:58 +0000 Message-ID: To: Christer Holmberg Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="f403045fe14c6cf5b80568bd1879" Archived-At: Subject: Re: [rtcweb] JSEP: remote-candidate attribute X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2018 22:44:15 -0000 --f403045fe14c6cf5b80568bd1879 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable JSEP doesn't use the remote-candidates attribute because it isn't necessary; because JSEP assumes that the selected pair will be handled entirely within the ICE process (i.e., through USE-CANDIDATE and/or PRIORITY), the answerer doesn't need to wait for its checks to complete before sending an answer. On Tue, Mar 6, 2018 at 6:11 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > The following has probably been discussed at some point, but I could not > find it in the mail archive, and it is not described in JSEP. > > My understanding is that JSEP does not use the remote-candidate attribute > (it must parse it if received, but it doesn=E2=80=99t process it). > > What was the reason for that? > > Regards, > > Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f403045fe14c6cf5b80568bd1879 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
JSEP doesn't use the remote-candidates attribute becau= se it isn't necessary; because JSEP assumes that the selected pair will= be handled entirely within the ICE process (i.e., through USE-CANDIDATE an= d/or PRIORITY), the answerer doesn't need to wait for its checks to com= plete before sending an answer.

On Tue, Mar 6, 2018 at 6:11 AM Christer Holmberg <christer.holmberg@ericsson.com>= ; wrote:
Hi,

The following has probably been discussed at some point, but I could n= ot find it in the mail archive, and it is not described in JSEP.

My understanding is that JSEP does not use the remote-candidate attrib= ute (it must parse it if received, but it doesn=E2=80=99t process it).

What was the reason for that?

Regards,

Christer
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--f403045fe14c6cf5b80568bd1879-- From nobody Sat Mar 31 16:47:59 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45420126DFB for ; Sat, 31 Mar 2018 16:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 f2g93Aq8VuY9 for ; Sat, 31 Mar 2018 16:47:56 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (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 2F611124BFA for ; Sat, 31 Mar 2018 16:47:56 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id y55so10654005wry.3 for ; Sat, 31 Mar 2018 16:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:openpgp:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Aj8DgxawmVfMKVtYApQATnJ3W0diAnRjAnSF9G4jL7o=; b=MIlWMqIpPXRgrQWglASUbd6l4sfc9lj0Yv+dOh98rWjmxnp6eoWt1fAtDSnoIDu3Ck E3msbKY1kTKx3xOSV7DcPlua9Ep6FqAvX79QIaflE+pLuMaKj0usX7sYkN2kx5TQvCmd I53fZWteUojogHX3W38B/2rFzAXOM8N+tkkZZPRpTsMGAgQ7luE87gA/36gH156gKO0o szbo+mpEqGy4XvryD9tozoXchfOo7JGWU1AHP08RzderzKcS6QW4WyVGFBSBIPFvtU3s imMcB+f/GuFtV+yjmKv7miviUM09eSTgbrBDRQ5QWv7fmDBvZKF/gEZPqWDw5upJJXlh p73Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Aj8DgxawmVfMKVtYApQATnJ3W0diAnRjAnSF9G4jL7o=; b=T35mn0pEHqGWbBGOOsjgG6BxxFk/Jaj/vKK6GY7nUOvtS2kDh2JKMhde5qX2GdLRKZ JmCdoidxLj6NoMke4mNw3WOGQQbnIq/jAeK/H0kE91NzazTuAa/IWMXPpJqx6cqT38Z1 hkxMsN5PzXg6g4Fay/c3M8L0Ls3CBBoRgvKzjwM32Whffy9c2ODhQdksTsSBunKLKFdx bTQ+qeJgYNvkMEvxC2TNAQARdUANnJ+Hdw1dm+Ka8KHQLn7ECXKdisCBj3Gr6u3m3aCr UJms5BSnyEDriKcM4suy+oH5OOgDnnXhad4NamqneJr27/wo/jd3oRl72T0BpqZKOMEf yG7A== X-Gm-Message-State: AElRT7EK7YEanUHuUMUoTvFJmThpbpRvzEsa8md59ezO5bs06rtKPjKX XbKCXEUpW9ICO4pn4rT6r9DJpgzszsw= X-Google-Smtp-Source: AIpwx49zFfOYDBLRI+SAlpbDE+R1ow9mjjwyQlNGhm8Gy2hz/YMbXtkfnZVFqXPFd6CPw0Q046zPuw== X-Received: by 10.223.182.143 with SMTP id j15mr3017790wre.43.1522540074430; Sat, 31 Mar 2018 16:47:54 -0700 (PDT) Received: from [192.168.43.132] (tmo-122-247.customers.d1-online.com. [80.187.122.247]) by smtp.gmail.com with ESMTPSA id s49sm17597871wrc.36.2018.03.31.16.47.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 31 Mar 2018 16:47:53 -0700 (PDT) To: Justin Uberti Cc: Sean Turner , RTCWeb IETF References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> From: Lennart Grahl Openpgp: preference=signencrypt Message-ID: <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> Date: Sun, 1 Apr 2018 01:47:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2018 23:47:58 -0000 On 01.04.2018 00:26, Justin Uberti wrote: > As stated before, this is not a problem unique to web browsers. That is, by > installing a mobile application, you implicitly allow it to use all of your > network interfaces. As such, trying to design browser mechanisms for > networking consent seems like misdirected effort. First of all, that comparison doesn't really work for me since an app is much less of a sandbox. So, I personally do not trust arbitrary websites but I do trust apps that I install (or I just don't install them, or I partially trust them and revoke some of the permissions they have). It's all about expectations: WebRTC networking is special - it does networking entirely different to what people were accustomed to in browsers. Which is probably why people are so irritated when they learn that it leaks IPs even though they've set a proxy or a VPN. And along with the argument that gUM just does not work for a bunch of use cases, that is the rationale for my suggestion towards a networking "consent" mechanism. With that mechanism in place the user has a voice, we cover more use cases, browsers can ship stricter modes by default without breaking everything we love about peer-to-peer connections and privacy extensions might consider dropping WebRTC from their blacklist. I honestly do not see this as being terribly misguided. > Perhaps the key issue here is the word 'consent'. If we replaced this with > some notion of 'trust', i.e., that the user has specifically engaged with > this app with the intent of having a communications session, maybe that > provides a way out, as one can easily claim that installed mobile > applications and web apps with gUM rights are 'trusted'. I'm sorry but I don't really see the difference. gUM requests a permission to access your camera and your microphone and then assumes you're "trusting" the page for something different as well. > > On Sat, Mar 31, 2018 at 3:18 AM Lennart Grahl > wrote: > >> I really don't have a good suggestion other than being completely >> honest: "Hey user, I want to establish a direct connection - is that >> okay for you? Oh, and here is a help page that will tell you what impact >> this may have on your privacy..." >> >> These permission requests don't have to be mutually exclusive either. >> The above request could also be embedded inside the permission request >> for getUserMedia to avoid multiple requests: >> >> Camera to share: >> [WebCam 3000 |v] >> :WebCam 3000 : >> :WebCam 4000 : >> >> Direct connection: (?) <-- "help" button >> [No (Default) |v] >> :Yes : >> :Yes, but hide private addresses : >> :No (Default) : >> :No, and force using a proxy : >> >> [x] Remember the decision for this page >> >> [Don't allow] [Allow] >> >> Cheers >> Lennart >> >> On 31.03.2018 00:12, Sean Turner wrote: >>> >>> >>>> On Mar 29, 2018, at 23:48, Lennart Grahl >> wrote: >>>> >>>> I'm fine with the modes, I don't have a strong opinion on whether or not >>>> an IETF document should include some form of "consent". But I do have a >>>> problem with the suggestion to use getUserMedia. Can we maybe remove it? >>> >>> As the draft shepherd, I’m trying to figure out how to draw this WGLC to >> a close all in the hopes that we can help each other get this RTCweb WG >> ship docked. >>> >>> As far as dropping the getUserMedia suggestion, I’m a little hesitant to >> just drop it at this late date. That suggestion has been in the draft >> since October 2016 and it’s stood the test of a couple of WG reviews; not >> last calls mind you but there’s been plenty of time for folks to say get >> that outta there. And technically, it’s just a suggestion with no >> normative language. So … maybe a happy middle ground is to have another >> suggestion so that there’s more than one potential mechanism? >>> >>> spt >>> >> > From nobody Sat Mar 31 17:12:21 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9B612711E for ; Sat, 31 Mar 2018 17:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 ptKDhhZ2L_iD for ; Sat, 31 Mar 2018 17:12:17 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) (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 87261127078 for ; Sat, 31 Mar 2018 17:12:17 -0700 (PDT) Received: (qmail 34313 invoked from network); 1 Apr 2018 00:12:15 -0000 X-APM-Authkey: 255286/0(159927/0) 3 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 1 Apr 2018 00:12:15 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id A947618A0AFD for ; Sun, 1 Apr 2018 01:12:15 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id oDx1150r8S8U for ; Sun, 1 Apr 2018 01:12:15 +0100 (BST) Received: from [192.67.4.84] (unknown [192.67.4.84]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 7E4C618A040D for ; Sun, 1 Apr 2018 01:12:15 +0100 (BST) From: westhawk Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Sun, 1 Apr 2018 01:12:14 +0100 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> To: RTCWeb IETF In-Reply-To: <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> Message-Id: <03D3C806-B93F-4CD0-B57B-507B07E869A0@westhawk.co.uk> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 00:12:20 -0000 GuM permission is the wrong trust measure here. So for example, If I use webRTC to get a realtime feed from a webcam/ = baby monitor then I won=E2=80=99t use GuM, all my recv_only video traffic will go via = a TURN server even if I=E2=80=99m on the same Wifi ? Likewise if I use webRTC DC to control my lighting, I get extra latency = because I don=E2=80=99t need GuM? (Both of these are real projects). My current workaround is to use the camera to scan a QR and piggyback = off that permission. (Which is crazy). The IP address reveal is unrelated to the UserMedia. It is a =E2=80=98Trust/location' issue. Also - if GuM permission was granted for this origin, does this mean = that=20 subsequent page loads that _don=E2=80=99t_ request GuM don=E2=80=99t get = local candidates even if they would get GuM if they asked for it? (i.e. if I=E2=80=99ve once scanned a QR on this domain, do I always = reveal my local/public IPs?) Try explaining the logic of any of that to anyone outside this group=E2=80= =A6. Tim. > On 1 Apr 2018, at 00:47, Lennart Grahl = wrote: >=20 > On 01.04.2018 00:26, Justin Uberti wrote: >> As stated before, this is not a problem unique to web browsers. That = is, by >> installing a mobile application, you implicitly allow it to use all = of your >> network interfaces. As such, trying to design browser mechanisms for >> networking consent seems like misdirected effort. >=20 > First of all, that comparison doesn't really work for me since an app = is > much less of a sandbox. So, I personally do not trust arbitrary = websites > but I do trust apps that I install (or I just don't install them, or I > partially trust them and revoke some of the permissions they have). >=20 > It's all about expectations: WebRTC networking is special - it does > networking entirely different to what people were accustomed to in > browsers. Which is probably why people are so irritated when they = learn > that it leaks IPs even though they've set a proxy or a VPN. And along > with the argument that gUM just does not work for a bunch of use = cases, > that is the rationale for my suggestion towards a networking "consent" > mechanism. With that mechanism in place the user has a voice, we cover > more use cases, browsers can ship stricter modes by default without > breaking everything we love about peer-to-peer connections and privacy > extensions might consider dropping WebRTC from their blacklist. I > honestly do not see this as being terribly misguided. >=20 >> Perhaps the key issue here is the word 'consent'. If we replaced this = with >> some notion of 'trust', i.e., that the user has specifically engaged = with >> this app with the intent of having a communications session, maybe = that >> provides a way out, as one can easily claim that installed mobile >> applications and web apps with gUM rights are 'trusted'. >=20 > I'm sorry but I don't really see the difference. gUM requests a > permission to access your camera and your microphone and then assumes > you're "trusting" the page for something different as well. >=20 >>=20 >> On Sat, Mar 31, 2018 at 3:18 AM Lennart Grahl = >> wrote: >>=20 >>> I really don't have a good suggestion other than being completely >>> honest: "Hey user, I want to establish a direct connection - is that >>> okay for you? Oh, and here is a help page that will tell you what = impact >>> this may have on your privacy..." >>>=20 >>> These permission requests don't have to be mutually exclusive = either. >>> The above request could also be embedded inside the permission = request >>> for getUserMedia to avoid multiple requests: >>>=20 >>> Camera to share: >>> [WebCam 3000 |v] >>> :WebCam 3000 : >>> :WebCam 4000 : >>>=20 >>> Direct connection: (?) <-- "help" button >>> [No (Default) |v] >>> :Yes : >>> :Yes, but hide private addresses : >>> :No (Default) : >>> :No, and force using a proxy : >>>=20 >>> [x] Remember the decision for this page >>>=20 >>> [Don't allow] [Allow] >>>=20 >>> Cheers >>> Lennart >>>=20 >>> On 31.03.2018 00:12, Sean Turner wrote: >>>>=20 >>>>=20 >>>>> On Mar 29, 2018, at 23:48, Lennart Grahl >>> wrote: >>>>>=20 >>>>> I'm fine with the modes, I don't have a strong opinion on whether = or not >>>>> an IETF document should include some form of "consent". But I do = have a >>>>> problem with the suggestion to use getUserMedia. Can we maybe = remove it? >>>>=20 >>>> As the draft shepherd, I=E2=80=99m trying to figure out how to draw = this WGLC to >>> a close all in the hopes that we can help each other get this RTCweb = WG >>> ship docked. >>>>=20 >>>> As far as dropping the getUserMedia suggestion, I=E2=80=99m a = little hesitant to >>> just drop it at this late date. That suggestion has been in the = draft >>> since October 2016 and it=E2=80=99s stood the test of a couple of WG = reviews; not >>> last calls mind you but there=E2=80=99s been plenty of time for = folks to say get >>> that outta there. And technically, it=E2=80=99s just a suggestion = with no >>> normative language. So =E2=80=A6 maybe a happy middle ground is to = have another >>> suggestion so that there=E2=80=99s more than one potential = mechanism? >>>>=20 >>>> spt >>>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb