From nobody Mon May 8 06:16:34 2017 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 13DD7129467; Mon, 8 May 2017 06:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[BAYES_40=-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 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 lc983qMlS730; Mon, 8 May 2017 06:16:25 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 3CA8912946D; Mon, 8 May 2017 06:16:25 -0700 (PDT) X-AuditID: c1b4fb2d-b3dff7000000196b-53-59106fa6c0d8 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id FD.08.06507.6AF60195; Mon, 8 May 2017 15:16:23 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.339.0; Mon, 8 May 2017 15:16:22 +0200 To: "mmusic (E-mail)" , "rtcweb@ietf.org" From: Magnus Westerlund Message-ID: Date: Mon, 8 May 2017 15:16:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkluLIzCtJLcpLzFFi42KZGbFdUXd5vkCkwa1eOYupyx+zWKz9187u wOSxZMlPpgDGKC6blNSczLLUIn27BK6M2RdPMhfc4ax4fukPYwNjM0cXIyeHhICJxM/zt5i6 GLk4hASOMErMa90E5SxjlGh7tJgVpEpEwEeic1U3E4jNJmAhcfNHI1sXIweHsICBxNXDUiBh XgF7iSt/N4GVswioSMxevZoZxBYViJFoWfKBEaJGUOLkzCcsIK3MQPUPtpaBhJkF5CWat84G KxcS0JZoaOpgncDIOwtJxyyEjllIOhYwMq9iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECAyg g1t+6+5gXP3a8RCjAAejEg/vgxn8kUKsiWXFlbmHGCU4mJVEeLelCkQK8aYkVlalFuXHF5Xm pBYfYpTmYFES53XYdyFCSCA9sSQ1OzW1ILUIJsvEwSnVwLjsyA7XKv+9EXlSM5y0gyYXxyil +eo5LjI+dGPhQwVl57wrt5vqv4Su3Z0w8+y+jaoS9qne5q+3q57XLTgiIPTrU5ZBdnDJwids ixV3fFVe6Jj3fvP5cyyX87MCq+WDm2xDYj/Lus417FXl/B5t6OJmoLyDZ0YIc/SfpCzR8nnz 17NufzN3nRJLcUaioRZzUXEiABoWZZYcAgAA Archived-At: Subject: [rtcweb] AVTCORE discussion of extmap and BUNDLE 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, 08 May 2017 13:16:27 -0000 MMUSIC and RTCWeb, I would like to make you aware of an ongoing discussion around how the SDP attribute for RTP header extensions (a=extmap) should work with BUNDLE. This is going on in the context of the update of RFC5285: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/ Thread start: https://www.ietf.org/mail-archive/web/avt/current/msg17531.html This discussion started as result of the SDP expert reviewer who noticed that we failed to take muxing into account for the SDP attributes. And extmap is non-trivial and classified as special. So far we agreed that clarificatio is needed, but we have not yet agreed to what clarifications and their impact. So please review the discussion and contribute on the AVTCORE mailing list. Cheers Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue May 9 15:43:43 2017 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 5E17A12714F for ; Tue, 9 May 2017 15:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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] 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 hPAfR_rnZGGP for ; Tue, 9 May 2017 15:43:36 -0700 (PDT) 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 52E0012EB0E for ; Tue, 9 May 2017 15:43:36 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id g49so17011063uaa.1 for ; Tue, 09 May 2017 15:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=MxhoYB841x7XaKgYc/3vyvM/FsaGVwuIWbQNdH3k2Lc=; b=haXSsg6vxS9WaXVjCq4RxJ8ElN0YQ4OxyEgFPjeVee7dM3Aie1OYXHkGmwD+ayj9RP Qm29Ov+VILuTFlh9xctJjgB2dXGY++Pf7wUuuTvIQ7UvyAa/Xg+ljddxtgXKFe41OGf/ h9RFxv2IcanWqURBLqSo8onjg+hnPsdh1OiW2ri3UpKVsIn1lkyEcXnvP3lQgQafYNs1 M/AXMDi1GZABhU/QvK85GQkMOvS5Z7enS+rZwi+0dDHCoP6EVryX8wI5z3UjelaUqlDk JvsqdPqSNgWmg6xWz6NVF749KN0OyEYTwMMATx6bpTYN5KPE47PIqonNeug1CNgOQ4VG 7khw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MxhoYB841x7XaKgYc/3vyvM/FsaGVwuIWbQNdH3k2Lc=; b=Vwkf3st6bhhParWGXn4PagiGAM8ZF93381sTh6sSqr4qvWNFMzNxvdxacIJO3it4Bh 5jpmjaQGBEyKwSFAhZkglIw0AUunw8onRVBpW7chCfsu1ssOJt06ltxTwH8oAQGS9JhU wwNYUP5Ig6Y6LMq9hBU/uFFJ+O/tNJuLQVgMi7/S8ApKoRKIcMwaAYPTFwbr63SIdyMS 7su2CbIbuOeXT8haI2MPEWKzFY5SZmKh2+uvS56d9GNMwJTu6oxzvRHsrV7tXmu1HvXT x55Z1aYm7Nz+E3eLMR3g+QfhuiBBAXb5fFCYSxCcZ4HtJxtkJIxGYNHEfWj+sbelf5I4 FNHg== X-Gm-Message-State: AODbwcCeAB/G72M5NfR0JgvHf6RrQOMZAc2KkxEBD0LC/OYEXtBPG62T jEJPKdfbToLmrcPyP78Y36WvW9+iSlDKfas= X-Received: by 10.31.174.4 with SMTP id x4mr1175331vke.136.1494369814973; Tue, 09 May 2017 15:43:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.49.18 with HTTP; Tue, 9 May 2017 15:43:13 -0700 (PDT) From: Bernard Aboba Date: Tue, 9 May 2017 18:43:13 -0400 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a1143847cfc15ae054f1f15c0 Archived-At: Subject: [rtcweb] Review of draft-ietf-rtcweb-ip-handling (part 1) 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, 09 May 2017 22:43:42 -0000 --001a1143847cfc15ae054f1f15c0 Content-Type: text/plain; charset=UTF-8 General points: a. Please expand acronyms on first use (e.g. HTTP, VPN, ICE, etc.). Details 1 . Introduction As a technology that supports peer-to-peer connections, WebRTC may send data over different network paths than the path used for HTTP traffic. This may allow a web application to learn additional information about the user, which may be problematic in certain cases. This document summarizes the concerns, and makes recommendations on how best to handle the tradeoff between privacy and media performance. [BA] There are a number of distinct privacy issues that WebRTC needs to address. I believe this document is focussed on IP address info that can be gleaned by Web applications (the second sentence). That is somewhat distinct from what information a web server might glean, or what a passive observer might be able to obtain looking at traffic generated by a WebRTC client. The first sentence therefore is a bit confusing to me. A suggestion: "As a technology that attempts to optimize peer-to-peer connections by testing connectivity between available addresses, WebRTC may allow a web application to learn additional information about the user compared to an application which only utilizes HTTP. This may be problematic in certain cases." 2 . Problem Statement WebRTC enables real-time peer-to-peer communications by enumerating network interfaces and discovering the best route through the ICE [RFC5245 ]protocol. During the ICE process, the peers involved in a session gather and exchange all the IP addresses they can discover, so that the connectivity of each IP pair can be checked, and the best path chosen. The addresses that are gathered usually consist of an endpoint's private physical/virtual addresses, and its public Internet addresses. [BA] The terms "route" and "path" used here do not refer to IP routing and so is a bit confusing. How about this? "In order to enable peer-to-peer communications, WebRTC peers utilize ICE [RFC5245] which gathers and exchanges all the IP addresses it can discover, so that the connectivity of each IP pair can be checked, and the best pair can be chosen. The addresses that are gathered usually consist of an endpoint's private physical/virtual addresses, and its public Internet addresses." 2. If the client tries to hide its physical location through a VPN, and the VPN and local OS support routing over multiple interfaces (i.e., a "split-tunnel" VPN), WebRTC will discover the public address for the VPN as well as the ISP public address that the VPN runs over. [BA] Even if the local OS doesn't support split-tunnel, isn't it still possible for an ICE implementation to discover other addresses? 3 . Goals Being peer-to-peer, WebRTC represents a privacy-enabling technology, and therefore we want to avoid solutions that disable WebRTC or make it harder to use. This means that WebRTC should be configured by default to only reveal the minimum amount of information needed to establish a performant WebRTC session, while providing options to reveal additional information upon user consent, or further limit this information if the user has specifically requested this. Specifically, WebRTC should: o Provide a privacy-friendly default behavior which strikes the right balance between privacy and media performance for most users and use cases. o For users who care more about one versus the other, provide a means to customize the experience. [BA] This section might state whether it is a goal to enable WebRTC to be used with The Onion Routing network (Tor). There are a number of reasons why enabling Javascript for use with Tor may represent a problem so that use of WebRTC might not be advisable: https://security.stackexchange.com/questions/95046/why-disable-javascript-in-tor 4 . Detailed Design 1. By default, WebRTC should follow normal IP routing rules, to the extent that this is easy to determine (i.e., not considering proxies). This can be accomplished by binding local sockets to the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which allows the OS to route WebRTC traffic the same way as it would HTTP traffic, and allows only the 'typical' public addresses to be discovered. [BA] This paragraph discusses routing behavior and address binding together and leads me to wonder whether some assumptions aren't being made (e.g. weak versus strong host model). My suggestion is to simplify the the paragraph and leave details to later on. For example: "1. By default WebRTC should only allow applications to discover the same address information made available by an HTTP application: the 'typical' public address." --001a1143847cfc15ae054f1f15c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


General points:

a. Please expand acronyms on first use (e.g. HTTP, VPN, ICE, etc.).= =C2=A0



Details
= 

1.  Introduction

<= pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar= gin-bottom:0px;color:rgb(0,0,0)"> As a technology that supports peer-to-p= eer connections, WebRTC may send data over different network paths than the path used for HTTP traffic. This may allow a web application to learn additional information about the user, which may be problematic in certain cases. This document summarizes the concerns, and makes recommendations on how best to handle the tradeoff between privacy and media performance.

= 
[BA] There are a number of distinct priva=
cy issues that WebRTC
needs to addre=
ss. I believe this document is focussed on IP
address info that can be gleaned by Web applications (the
second sentence). That is somewhat distinc= t from what information
a web server=
 might glean, or what a passive observer might be
able to obtain looking at traffic generated by a WebRTC clien=
t.
The first sentence therefore is a=
 bit confusing to me.

A suggestion:

"As a technology t=
hat attempts to optimize peer-to-peer
connections by testing connectivity between available
addresses, WebRTC may allow a web application to learn<=
/pre>
additional information about the use=
r compared to an
application which o=
nly utilizes HTTP.  This may be
prob=
lematic in certain cases."

=

2.  Problem Statement

   WebRTC enables real-time peer-to-peer communications by enumer=
ating
   network interfaces and discovering the best route through the ICE
   [RFC5245]protocol=
.  During the ICE process, the peers involved in a
   session gather and exchange all the IP addresses they can discover,
   so that the connectivity of each IP pair can be checked, and the best
   path chosen.  The addresses that are gathered usually consist of an
   endpoint's private physical/virtual addresses, and its public
   Internet addresses.

[BA=
] The terms "route" and "path" used here do not refer t=
o IP
routing and so is a bit confusing.  How about th=
is? 

   &=
quot;In order to enable peer-to-peer communications, WebRTC
   peers utilize ICE [RFC5245] which gathers and exchanges
   all the IP addresses it can discover, so that the 
   connectivity of each IP pair can be checked, and the best
   pair can be chosen.  The addresses that are gathered
   usually consist of an endpoint's private physical/virtual
   addresses, and its public Internet addresses."
= 

   2.  If the =
client tries to hide its physical location through a VPN,
       and the VPN and local OS support routing over multiple interfaces
       (i.e., a "split-tunnel" VPN), WebRTC will discover the pub=
lic
       address for the VPN as well as the ISP public address that the
       VPN runs over.

[BA]=
 Even if the local OS doesn't support split-tunnel,
isn't it still possible for an ICE implementation to
discover other addresses? 

3.  Goals

   Being peer-to-peer, WebRTC represents a privacy-enabling technology,
   and therefore we want to avoid solutions that disable WebRTC or make
   it harder to use.  This means that WebRTC should be configured by
   default to only reveal the minimum amount of information needed to
   establish a performant WebRTC session, while providing options to
   reveal additional information upon user consent, or further limit
   this information if the user has specifically requested this.
   Specifically, WebRTC should:

   o  Provide a privacy-friendly default behavior w=
hich strikes the
      right balance between privacy and media performance for most users
      and use cases.


   o  For users who care more about one versus the o=
ther, provide a
      means to customize the experience.

[BA] This section might state whether it is a 
goal to enable WebRTC to be used with 
The O=
nion Routing network (Tor). There
are a number of r=
easons why enabling Javascript
for  use with Tor may =
represent a problem so that
use of WebRTC might not b=
e advisable:
https://security.stack=
exchange.com/questions/95046/why-disable-javascript-in-tor 
=

 
4.  Detailed Design

   1.  By default, WebRTC sh=
ould follow normal IP routing rules, to the
       extent that this is easy to determine (i.e., not considering
       proxies).  This can be accomplished by binding local sockets to
       the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which
       allows the OS to route WebRTC traffic the same way as it would
       HTTP traffic, and allows only the 'typical' public addresses=
 to
       be discovered.


[BA] This paragraph discusses routing behavior an=
d
address binding together and leads me to wonder whether
some assumptions aren't being made (e.g. weak versus
stron= g host model). My suggestion is to simplify the
the paragraph an= d leave details to later on. For example:

"1.= By default WebRTC should only allow applications
to discover the= same address information made available
by an HTTP application: = the 'typical' public address."
--001a1143847cfc15ae054f1f15c0-- From nobody Tue May 9 18:46:23 2017 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 EC08F12EB98 for ; Tue, 9 May 2017 18:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 2x6FlcA8b5ZF for ; Tue, 9 May 2017 18:46:19 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 D89FA126DED for ; Tue, 9 May 2017 18:46:18 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id h4so11745494lfj.3 for ; Tue, 09 May 2017 18:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=TS29PViLD/sA5Ch6xx1hgkmwrpkCbjRDLJOCOcZbckY=; b=tEzW1LRSeo0tKEo5Ztmp7qfP1ef89aqjxV5UaYLL+4MSLmS9ctTrLOxWu2RKPXZuv0 jCM8zU0+KpqjOzpvumO7Aip2CgEmBbWYFbPRUipamC4PpYFgRksfoCcAMcTrQXSrzedI vAtDw/vf/N0tApxT/arz7gyuZfgcaglulo0iaCPxSenHPK0E7qRZUyfUbvUGn29NOTKQ jouhCwTIra8cBZ+6xDqRtKSkmk6edzSS/nt0TEXzYlK8QezzwgxDLt62dqZdSJbDki0h oClHz2F+RK3pc8+qffXUcC+nob3c2ZsgxhL8yfp2RW8p+Uggr8w1VOyfChcgvpLFIn9q ADwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TS29PViLD/sA5Ch6xx1hgkmwrpkCbjRDLJOCOcZbckY=; b=Lw9k2MOMHHi9AeieZnCus7mbpAzENSoVOFpyq7GLGHK9t0e4/anBqgDrZKmkaTy5CM ZthKOY4cK6RUHqlneVcpuV+DYYlrj4CHzcoyRpla1JG1YLkPWcw2P66EiGz09fJQ1zIk NAQPBKGluZB/SFG37U2IqIAeCbOH0DuN26QPd3fBkWsk19PPdtwx5wZZQcx+PbdLm8Ro OdvwPzXihEti+/YgffqJyGLYY5D1ycVqMFM4zPx2kXDWbdlmF87p5lfHM43fsc3FxajZ FlGZX2OYulg0yNSh5nLpnb6IRc7TbPNzfc9PDnWOSSNOPbzsnSWHVK+RDgoxXV49YMI0 dG5w== X-Gm-Message-State: AODbwcA9NIXvAxQqq9Nw6Yy+4L36mRNiVTwR+kl6n+jThtw7l12YLkOZ zEa7fTR2S5HlqiUgR96E/P6Pmm3RC3PFb3I= X-Received: by 10.46.0.23 with SMTP id 23mr1657181lja.33.1494380776866; Tue, 09 May 2017 18:46:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Tue, 9 May 2017 18:46:16 -0700 (PDT) From: Martin Thomson Date: Wed, 10 May 2017 11:46:16 +1000 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [rtcweb] Review of 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, 10 May 2017 01:46:21 -0000 In Section 3, please don't imply that WebRTC is only for privacy. At a minimum "Being peer-to-peer, WebRTC represents a technology that could improve privacy," Though I'd avoid this sort of statement altogether. One interesting side effect of unintermediated or peer-to-peer communications is that there is now network-level metadata showing who was communicating. There is a direct flow between peers. The privacy gain (no single middleman with access to communications metadata) becomes a potential loss (passive network observers can see who was talking more easily). I think that Section 3 could be more simply stated as: Provide a framework for understanding the problem so that controls might be provided to make different trade-offs regarding performance and privacy concerns with WebRTC. Using that framework, define settings that enable peer-to-peer communications each with a different balance between performance and privacy. Finally, provide recommendations about settings that provide reasonable performance without also exposing addressing information in a way that might violate user expectations. In Section 4, the mention of RETURN isn't really necessary and it will stall progress of this draft. The framing of RETURN ensures that it falls into the "proxy" definition quite neatly, so it will work without changing this draft. Though RETURN would reduce the performance downsides of the higher-numbered modes - significantly - it doesn't really need a special mention here. I'm not very enthusiastic about this bullet in Section 5: o Future versions of browsers may present an indicator to signify that the page is using WebRTC to set up a peer-to-peer connection. Applications MUST only use WebRTC in a fashion that is consistent with user expectations. The indicator thing is kinda speculative; based on my experience with these things, I'd say that the chances that we did that would be close to zero. Also, the MUST here is completely toothless to the point that I think it's dangerous. Applications will care to the extent that they care, and yelling at them isn't going to influence that one iota. Also, since the whole point of this document is to establish a framework for thinking about this specific problem, I think that it's safe to remove this sentence. I would remove the entire bullet point. Nits: Many of the references need to have a space after the closing bracket. Remove the reference to 8.8.8.8. It's actually a good example, but it's not necessary and it is likely to cause some people's heads to explode. As much as I might personally enjoy that, it's not my document; you might be better avoiding this. From nobody Thu May 11 00:45:09 2017 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 94076129AC9; Thu, 11 May 2017 00:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 IJORgFQ8oRFA; Thu, 11 May 2017 00:45:06 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 671411274D2; Thu, 11 May 2017 00:45:05 -0700 (PDT) X-AuditID: c1b4fb3a-f56d89a000005025-82-5914167fe405 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 85.3E.20517.F7614195; Thu, 11 May 2017 09:45:03 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0339.000; Thu, 11 May 2017 09:44:02 +0200 From: Christer Holmberg To: Sean Turner CC: Eric Rescorla , The IESG , "rtcweb-chairs@ietf.org" , "rtcweb@ietf.org" , "draft-ietf-rtcweb-overview@ietf.org" Thread-Topic: [rtcweb] Eric Rescorla's Discuss on draft-ietf-rtcweb-overview-18: (with DISCUSS and COMMENT) Thread-Index: AQHSu1nlcZL8BStkfUysDoOyMAqI5qHTV0EQgAODp4CAGBVbgA== Date: Thu, 11 May 2017 07:44:00 +0000 Message-ID: References: <149285978295.25905.7347383325486705546.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CB805F3@ESESSMB109.ericsson.se> <15D737F9-2F65-45C5-AA26-946910B4030F@sn3rd.com> In-Reply-To: <15D737F9-2F65-45C5-AA26-946910B4030F@sn3rd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3C4F8E4392172947910720694E289526@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJIsWRmVeSWpSXmKPExsUyM2K7q269mEikwYxdshZbXp9gs1jx+hy7 xYw/E5ktet7eYLFY+6+d3eLKqkZmBzaPJUt+MnlMftzG7HHwIGMAcxSXTUpqTmZZapG+XQJX xuSp+xgLlnJVvP7Zw9jAuIuji5GTQ0LAROLsnx3sXYxcHEICRxglPj7pYYRwljBK7Fu+FMjh 4GATsJDo/qcN0iAioCDRdPQBK0gNs8BTRok1L9vBaoQFciQeHmOBqMmVuLlhJpTtJPG44TaY zSKgKrF/zndGEJtXwFqi78MbNrjFi76vYwdJcArYSnz+tZUZxGYUEJP4fmoNE4jNLCAucevJ fCaIqwUkluw5zwxhi0q8fPyPFcQWFdCT2PfvKxtEXFHi6vTlUL16EjemTmGDsK0l3l2bxgJh a0ssW/iaGeIgQYmTM5+wTGAUn4Vk3Swk7bOQtM9C0j4LSfsCRtZVjKLFqcXFuelGRnqpRZnJ xcX5eXp5qSWbGIERenDLb6sdjAefOx5iFOBgVOLhfSAjHCnEmlhWXJl7iFGCg1lJhHeSqEik EG9KYmVValF+fFFpTmrxIUZpDhYlcV6HfRcihATSE0tSs1NTC1KLYLJMHJxSDYxmbHfyT7Pv TJxfV37ttORV36sZUo6uIWvdnh3bazU1f3pC9uHz3uUHy78Xnmr9Wjlh81KrUvPKmfs8uPNZ r27x2NLKd37C3ZMntSY/rOthP7J35o5/U0rLF7/Nqb06af1r9s+blDq2h/r1vr41V8dsVuJV /1SP61v1FylZLP+/0SIswvnNlX0LlViKMxINtZiLihMBUHcboMwCAAA= Archived-At: Subject: Re: [rtcweb] Eric Rescorla's Discuss on draft-ietf-rtcweb-overview-18: (with DISCUSS and COMMENT) 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, 11 May 2017 07:45:08 -0000 Hi, What is the status regarding this? Regards, Christer On 26/04/17 06:02, "Sean Turner" wrote: > >> On Apr 23, 2017, at 14:44, Christer Holmberg >> wrote: >>=20 >> Hi, >>=20 >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>>=20 >>> Your citation to ICE is to 5245-bis, but at least the JSEP editor >>>consensus was that WebRTC depended on 5245, so this needs to be >>>resolved one way or the other. >>=20 >> Keep in mind that, no matter what draft-rtcweb-overview and >>draft-rtcweb-jsep explicitly say, both specs reference 5245bis >>*IMPLICITLY*, e.g., via draft-mmusic-bundle, draft-ice-trickle etc... As >>I have indicated in the past, it would cause confusion to reference both. >>=20 >> So, I think we shall reference 5245-bis everywhere (I also thought we >>already decided no that in the past)- >>=20 >> Regards, >>=20 >> Christer > >/* bike shed alert: >/*=20 >/* Assuming you=B9re of the mind that a bis/updates draft is >/* signaling to all implementors of the original RFC that the >/* intention is that all implementations be updated then it=B9s >/* a bit more than implicit. > >spt > From nobody Thu May 11 06:48:44 2017 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 6E53A12F257 for ; Thu, 11 May 2017 06:48:42 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 e09q64ND6sBg for ; Thu, 11 May 2017 06:48:40 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002: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 04A9A1300CF for ; Thu, 11 May 2017 06:44:33 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id b68so12682216ywe.3 for ; Thu, 11 May 2017 06:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H59RnawMto00ZelAgzXpYWdmNtklaTZ5UAPlvIK8FvI=; b=K27zOAOJs16KzX28Al30zaIX99UmikCAgINmly9qYdSQ81llQHCs5PGoFuKH2MXSLq RwgUAGEUmDiORf5w5GBj3XGE03Gqtm92KLxOo9lPM8jQflW8kRxXx/B78Ld4HjFvDEvW Q9jUjrNzyZvos4CWdmxEJs+gkTtI5KORJNVQWLACYjYP3T9LHZaIgcvH5Qfxt7rxK0QJ E5qylLLH7MeUQXOBSNYyzwoC5KmPthz6gt0g5QizegpL46bHoaLYbQsqOqP3qLOdyD2N wihtuZ9eiNp5uVVpaFWjiwVTZ3MyZSmm6NDdr0poOjLCUz86PUMBXwkGsvcL/3f6YlWl KdfA== 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=H59RnawMto00ZelAgzXpYWdmNtklaTZ5UAPlvIK8FvI=; b=BKFVyj7XeWMmjN+KNkvcJ/ir+ccUc6Hr32/l7kE4Xr1ZGC8Y7h40/JOr0o7s+d+HPB 9gSyBvcqaV4DuGodJRqLBX+oXx858bSTlUlfhs2Occ7SQEYYak6lCxFnIgWvlP/bPSqZ ZUwVeVSKKBkDOPGxCMCws1rU9sgTJFaudi7QdHmxPlKOw4/ME3ZlzJwHVXETzlmquWGQ DY6op6DS2WugBdSflm2NDEAhXuyzKbtdTGKBYGrBp0QNk4oQZDgraYkXLhMJ+H/+6kIN NTVlJ9vhvExLlUBTymCXIgpmbTLXNCw6nAwG3GWF1+VNlnCFJKtbYzi+m9Zy7U0tJZ48 0TKw== X-Gm-Message-State: AODbwcA0AzL5dphA1Y6BTjyq5FJTQTgGqj1Ocnq8aqbDoNxMlTBwwVms t346jj5U6sb/0zwP5xwUv2SERMu7+A== X-Received: by 10.13.255.199 with SMTP id p190mr325094ywf.312.1494510272279; Thu, 11 May 2017 06:44:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Thu, 11 May 2017 06:43:51 -0700 (PDT) In-Reply-To: References: <149285978295.25905.7347383325486705546.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CB805F3@ESESSMB109.ericsson.se> <15D737F9-2F65-45C5-AA26-946910B4030F@sn3rd.com> From: Eric Rescorla Date: Thu, 11 May 2017 06:43:51 -0700 Message-ID: To: Christer Holmberg Cc: Sean Turner , The IESG , "rtcweb-chairs@ietf.org" , "rtcweb@ietf.org" , "draft-ietf-rtcweb-overview@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c087eeae49022054f3fc949" Archived-At: Subject: Re: [rtcweb] Eric Rescorla's Discuss on draft-ietf-rtcweb-overview-18: (with DISCUSS and COMMENT) 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, 11 May 2017 13:48:43 -0000 --94eb2c087eeae49022054f3fc949 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Question for the chairs. On Thu, May 11, 2017 at 12:44 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > What is the status regarding this? > > Regards, > > Christer > > On 26/04/17 06:02, "Sean Turner" wrote: > > > > >> On Apr 23, 2017, at 14:44, Christer Holmberg > >> wrote: > >> > >> Hi, > >> > >>> ---------------------------------------------------------------------= - > >>> DISCUSS: > >>> ---------------------------------------------------------------------= - > >>> > >>> Your citation to ICE is to 5245-bis, but at least the JSEP editor > >>>consensus was that WebRTC depended on 5245, so this needs to be > >>>resolved one way or the other. > >> > >> Keep in mind that, no matter what draft-rtcweb-overview and > >>draft-rtcweb-jsep explicitly say, both specs reference 5245bis > >>*IMPLICITLY*, e.g., via draft-mmusic-bundle, draft-ice-trickle etc... A= s > >>I have indicated in the past, it would cause confusion to reference bot= h. > >> > >> So, I think we shall reference 5245-bis everywhere (I also thought we > >>already decided no that in the past)- > >> > >> Regards, > >> > >> Christer > > > >/* bike shed alert: > >/* > >/* Assuming you=C2=B9re of the mind that a bis/updates draft is > >/* signaling to all implementors of the original RFC that the > >/* intention is that all implementations be updated then it=C2=B9s > >/* a bit more than implicit. > > > >spt > > > > --94eb2c087eeae49022054f3fc949 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Question for the chairs.
<= br>
On Thu, May 11, 2017 at 12:44 AM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>
Hi,

What is the status regarding this?

Regards,

Christer

On 26/04/17 06:02, "Sean Turner" <sean@sn3rd.com> wrote:

>
>> On Apr 23, 2017, at 14:44, Christer Holmberg
>><christer.holm= berg@ericsson.com> wrote:
>>
>> Hi,
>>
>>> ---------------------------------------------------------= -------------
>>> DISCUSS:
>>> ---------------------------------------------------------= -------------
>>>
>>> Your citation to ICE is to 5245-bis, but at least the JSEP edi= tor
>>>consensus was that WebRTC depended on 5245, so this needs to be=
>>>resolved one way or the other.
>>
>> Keep in mind that, no matter what draft-rtcweb-overview and
>>draft-rtcweb-jsep explicitly say, both specs reference 5245bis
>>*IMPLICITLY*, e.g., via draft-mmusic-bundle, draft-ice-trickle etc.= .. As
>>I have indicated in the past, it would cause confusion to reference= both.
>>
>> So, I think we shall reference 5245-bis everywhere (I also thought= we
>>already decided no that in the past)-
>>
>> Regards,
>>
>> Christer
>
>/* bike shed alert:
>/*
>/* Assuming you=C2=B9re of the mind that a bis/updates draft is
>/* signaling to all implementors of the original RFC that the
>/* intention is that all implementations be updated then it=C2=B9s
>/* a bit more than implicit.
>
>spt
>


--94eb2c087eeae49022054f3fc949-- From nobody Fri May 12 16:58:02 2017 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 30B3D12EB6E; Fri, 12 May 2017 16:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 e_6AQiGzqWNG; Fri, 12 May 2017 16:57:52 -0700 (PDT) Received: from smtp145.dfw.emailsrvr.com (smtp145.dfw.emailsrvr.com [67.192.241.145]) (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 F1A2D12ECA6; Fri, 12 May 2017 16:54:58 -0700 (PDT) Received: from smtp19.relay.dfw1a.emailsrvr.com (localhost [127.0.0.1]) by smtp19.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 3E3BF40162; Fri, 12 May 2017 19:54:58 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp19.relay.dfw1a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 111DB40100; Fri, 12 May 2017 19:54:56 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.67] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 12 May 2017 19:54:58 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: Date: Fri, 12 May 2017 17:54:55 -0600 Cc: Sean Turner , The IESG , "rtcweb-chairs@ietf.org" , RTCWeb IETF , "draft-ietf-rtcweb-overview@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <149285978295.25905.7347383325486705546.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CB805F3@ESESSMB109.ericsson.se> <15D737F9-2F65-45C5-AA26-946910B4030F@sn3rd.com> To: Eric Rescorla , Christer Holmberg X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [rtcweb] Eric Rescorla's Discuss on draft-ietf-rtcweb-overview-18: (with DISCUSS and COMMENT) 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, 12 May 2017 23:57:54 -0000 Let me try and answer with the caveat that I may get this wrong and need = to be corrected by my co-chairs... TL;DR - The chairs recommend changing the ref in overview to point at = 5245 instead of 5245-bis here is the longer version....=20 First a side note on how we got here. Some of the reasons we set up = dependencies like they are is that many years ago we made guess about = what order work would get completed on and, shockingly, some predictions = of standards developments timelines were less than perfect. We also = assumed that some new work was going to require changes in ICE but as = that work went progressed, we largely figured out ways to make it work = with existing ICE implementations.=20 We are confident that overview does not actually depend on anything in = 5245-bis but instead just depends on 5245.=20 Next lets discuss trickle-ice. The WebRTC set of specs currently = normatively depends on trickle ICE. There is some questions if trickle = ICE might depend on 5245-bis. Some of the trickle ICE authors do not = think it does. One of the authors said the chairs asked them to ref 5245 = instead of 5245bis as both tickle ICE and 5245bis would be done around = the same time. In general, the webrtc chairs would prefer to make the = WebRTC dependency cluster as small as possible. If trickle ice actually = gets done before 5245bis, and it does not depend on any 5245bis = features, then clearly is should be changed to just depend on 5245. The = WG responsible for 5245bis and trickle ICE can figure out what they want = to do as both theses drafts progress. Given there is a strong = possibility that trickle ice will only reference 5245, we think it would = be better if overview did not bring 5245bis into the WebRTC dependency = cluster. If on the other hand, trickle ICE does end up depending on = 5245bis, there is no harm, and no need to change overview to point at = 5245.=20 There are other drafts that are normative dependencies of JSEP and the = WebRTC cluster that also point at 5245bis. When we consider the = technical things these drafts need, it seems likely they can also = reference 5245 instead of 5245bis. For example = draft-ietf-ice-dualstack-fairness, draft-ietf-mmusic-ice-sip-sdp, = draft-ietf-mmusic-sdp-bundle-negotiation, and = draft-ietf-rtcweb-transports (which is with the RFC Editor). The = argument for the others is roughly the same as it is with trickle ICE.=20= Cullen (without review from my co-chairs but trying to represent what we = discussed on our chair call) PS - if you are trying to figure out some of the dependencies for the = WebRTC cluster, you might find = https://datatracker.ietf.org/doc/draft-jennings-rtcweb-deps/?include_text=3D= 1 useful but it is not 100% accurate.=20 > On May 11, 2017, at 7:43 AM, Eric Rescorla wrote: >=20 > Question for the chairs. >=20 > On Thu, May 11, 2017 at 12:44 AM, Christer Holmberg = wrote: > Hi, >=20 > What is the status regarding this? >=20 > Regards, >=20 > Christer >=20 > On 26/04/17 06:02, "Sean Turner" wrote: >=20 > > > >> On Apr 23, 2017, at 14:44, Christer Holmberg > >> wrote: > >> > >> Hi, > >> > >>> = ---------------------------------------------------------------------- > >>> DISCUSS: > >>> = ---------------------------------------------------------------------- > >>> > >>> Your citation to ICE is to 5245-bis, but at least the JSEP editor > >>>consensus was that WebRTC depended on 5245, so this needs to be > >>>resolved one way or the other. > >> > >> Keep in mind that, no matter what draft-rtcweb-overview and > >>draft-rtcweb-jsep explicitly say, both specs reference 5245bis > >>*IMPLICITLY*, e.g., via draft-mmusic-bundle, draft-ice-trickle = etc... As > >>I have indicated in the past, it would cause confusion to reference = both. > >> > >> So, I think we shall reference 5245-bis everywhere (I also thought = we > >>already decided no that in the past)- > >> > >> Regards, > >> > >> Christer > > > >/* bike shed alert: > >/* > >/* Assuming you=C2=B9re of the mind that a bis/updates draft is > >/* signaling to all implementors of the original RFC that the > >/* intention is that all implementations be updated then it=C2=B9s > >/* a bit more than implicit. > > > >spt > > >=20 >=20 From nobody Sat May 13 00:56:31 2017 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 3C6D71243F3; Sat, 13 May 2017 00:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 4_aZjWq45h_G; Sat, 13 May 2017 00:56:27 -0700 (PDT) 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 9314E127876; Sat, 13 May 2017 00:54:11 -0700 (PDT) X-AuditID: c1b4fb25-0a3ff70000006049-1d-5916bb9e14ee Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 34.4E.24649.E9BB6195; Sat, 13 May 2017 09:54:09 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0339.000; Sat, 13 May 2017 09:54:06 +0200 From: Christer Holmberg To: Cullen Jennings , Eric Rescorla CC: Sean Turner , The IESG , "rtcweb-chairs@ietf.org" , RTCWeb IETF , "draft-ietf-rtcweb-overview@ietf.org" Thread-Topic: [rtcweb] Eric Rescorla's Discuss on draft-ietf-rtcweb-overview-18: (with DISCUSS and COMMENT) Thread-Index: AQHSu1nlcZL8BStkfUysDoOyMAqI5qHTV0EQgAODp4CAGBVbgIAAMMGAgAI9D4CAAKUNEA== Date: Sat, 13 May 2017 07:54:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CBA05BC@ESESSMB109.ericsson.se> References: <149285978295.25905.7347383325486705546.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CB805F3@ESESSMB109.ericsson.se> <15D737F9-2F65-45C5-AA26-946910B4030F@sn3rd.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2J7uO7C3WKRBhdWqVtseX2CzWLF63Ps Fh/W/2C0mPFnIrNFz9sbLBZr/7WzW1xZ1cjswO6xZMlPJo/L5z8yekx+3MbscfAgYwBLFJdN SmpOZllqkb5dAlfGw2UfWAqe2FbMPPiLtYFxhk0XIyeHhICJRPeK7UxdjFwcQgJHGCUeTf/G ApIQEljCKDF/uXUXIwcHm4CFRPc/bZCwiICjxIJHm5lB6pkF7jNKLPx/nx0kISyQI7H88EEW iKJciZsbZkLZYRKHG46D1bAIqEo0zN/PAjKTV8BX4tBBKYi9b5kk3q+6CVbPKWAl0f1gL1g9 o4CYxPdTa5hAbGYBcYlbT+YzQRwtILFkz3lmCFtU4uXjf6wQtpJE45InrCDzmQU0Jdbv0odo VZSY0v0QbCSvgKDEyZlPWCYwis5CMnUWQscsJB2zkHQsYGRZxShanFqclJtuZKyXWpSZXFyc n6eXl1qyiREYZwe3/FbdwXj5jeMhRgEORiUe3gcLxCKFWBPLiitzDzFKcDArifAybAcK8aYk VlalFuXHF5XmpBYfYpTmYFES53XcdyFCSCA9sSQ1OzW1ILUIJsvEwSnVwKjuHDlbf+1cwUCB PWv3Peb7O4G1Wun/Na8T9uEJ+Z921vqsf1u/TeLFN7MnO9scnnvGfy182Gz7p8U6Nmg1d+Qt YZ0lGR1XW96v9ix2NnfyvPd1c8jtN2vWdnNf9zpafZg//G9hek3q+iMH9s7weLHZbEPMTKcb k49/L5XovNjPvvLG+d+BT6YpsRRnJBpqMRcVJwIAfBm7Kq8CAAA= Archived-At: Subject: Re: [rtcweb] Eric Rescorla's Discuss on draft-ietf-rtcweb-overview-18: (with DISCUSS and COMMENT) 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, 13 May 2017 07:56:29 -0000 SGksDQoNCkFzIGNvLWNoYWlyIG9mIGEgbnVtYmVyIG9mIHRoZSBkZXBlbmRlbmNpZXMsIHdlIGhh dmUgYmVlbiBkaXNjdXNzaW5nIHdoYXQgdG8gcmVmZXJlbmNlIGEgbnVtYmVyIG9mIHRpbWVzLCBh bmQgd2UgaGF2ZSBhbHNvIGNoYW5nZWQgdGhlIHJlZmVyZW5jZXMuIFdlIGNhbid0IGtlZXAgY2hh bmdpbmcgYmFjayBhbmQgZm9ydGguIA0KDQpJbiBhZGRpdGlvbiwgSSBkb24ndCB0aGluayBXRyBY IGNhbiBkZWNpZGUgd2hhdCB0aGUgZHJhZnRzIG9mIFdHIFkgcmVmZXJlbmNlLiBUaGVyZSBuZWVk cyB0byBiZSBhIGNvbGxhYm9yYXRpdmUgZGVjaXNpb24uDQoNCiJXZSBhbHNvIGFzc3VtZWQgdGhh dCBzb21lIG5ldyB3b3JrIHdhcyBnb2luZyB0byByZXF1aXJlIGNoYW5nZXMgaW4gSUNFIGJ1dCBh cyB0aGF0IHdvcmsgd2VudCBwcm9ncmVzc2VkLCB3ZSBsYXJnZWx5IGZpZ3VyZWQgb3V0IHdheXMg dG8gbWFrZSBpdCB3b3JrIHdpdGggZXhpc3RpbmcgSUNFIGltcGxlbWVudGF0aW9ucy4iDQoNCklz IHRoaXMgImRpc2NvdmVyeSIgZG9jdW1lbnRlZCBzb21ld2hlcmU/DQoNCiJJZiB0cmlja2xlIGlj ZSBhY3R1YWxseSBnZXRzIGRvbmUgYmVmb3JlIDUyNDViaXMsIGFuZCBpdCBkb2VzIG5vdCBkZXBl bmQgb24gYW55IDUyNDViaXMgZmVhdHVyZXMsIHRoZW4gY2xlYXJseSBpcyBzaG91bGQgYmUgY2hh bmdlZCB0byBqdXN0IGRlcGVuZCBvbiA1MjQ1LiINCg0KRmlyc3QsIHdlIG5lZWQgdG8gYWdyZWUg b24gd2hldGhlciB0cmlja2xlIGRlcGVuZHMgb24gNTI0NWJpcyBmZWF0dXJlcyBvciBub3QuDQoN ClNlY29uZCwgYXMgY28tYXV0aG9yIG9mIDUyNDViaXMsIEkgaGF2ZSBhc2tlZCB0aGUgY2hhaXJz IHRvIGluaXRpYXRlIHRoZSByb2FkIHRvd2FyZHMgV0dMQywgc28gSSB3b3VsZCBob3BlIGJvdGgg NTI0NWJpcyBhbmQgdHJpY2tsZS1pY2UgY291bGQgYmUgZG9uZSBtb3JlIG9yIGxlc3MgYXQgdGhl IHNhbWUgdGltZS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogQ3VsbGVuIEplbm5pbmdzIFttYWlsdG86Zmx1ZmZ5QGlpaS5jYV0g DQpTZW50OiAxMyBNYXkgMjAxNyAwMTo1NQ0KVG86IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNv bT47IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpD YzogU2VhbiBUdXJuZXIgPHNlYW5Ac24zcmQuY29tPjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+ OyBydGN3ZWItY2hhaXJzQGlldGYub3JnOyBSVENXZWIgSUVURiA8cnRjd2ViQGlldGYub3JnPjsg ZHJhZnQtaWV0Zi1ydGN3ZWItb3ZlcnZpZXdAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRjd2Vi XSBFcmljIFJlc2NvcmxhJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmlldy0x ODogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCg0KDQpMZXQgbWUgdHJ5IGFuZCBhbnN3ZXIg d2l0aCB0aGUgY2F2ZWF0IHRoYXQgSSBtYXkgZ2V0IHRoaXMgd3JvbmcgYW5kIG5lZWQgdG8gYmUg Y29ycmVjdGVkIGJ5IG15IGNvLWNoYWlycy4uLg0KDQpUTDtEUiAtIFRoZSBjaGFpcnMgcmVjb21t ZW5kIGNoYW5naW5nIHRoZSByZWYgaW4gb3ZlcnZpZXcgdG8gcG9pbnQgYXQgNTI0NSBpbnN0ZWFk IG9mIDUyNDUtYmlzDQoNCg0KaGVyZSBpcyB0aGUgbG9uZ2VyIHZlcnNpb24uLi4uIA0KDQpGaXJz dCBhIHNpZGUgbm90ZSBvbiBob3cgd2UgZ290IGhlcmUuIFNvbWUgb2YgdGhlIHJlYXNvbnMgd2Ug c2V0IHVwIGRlcGVuZGVuY2llcyAgbGlrZSB0aGV5IGFyZSBpcyB0aGF0IG1hbnkgeWVhcnMgYWdv IHdlIG1hZGUgZ3Vlc3MgYWJvdXQgd2hhdCBvcmRlciB3b3JrIHdvdWxkIGdldCBjb21wbGV0ZWQg b24gYW5kLCBzaG9ja2luZ2x5LCBzb21lIHByZWRpY3Rpb25zIG9mIHN0YW5kYXJkcyBkZXZlbG9w bWVudHMgdGltZWxpbmVzIHdlcmUgbGVzcyB0aGFuIHBlcmZlY3QuIFdlIGFsc28gYXNzdW1lZCB0 aGF0IHNvbWUgbmV3IHdvcmsgd2FzIGdvaW5nIHRvIHJlcXVpcmUgY2hhbmdlcyBpbiBJQ0UgYnV0 IGFzIHRoYXQgd29yayB3ZW50IHByb2dyZXNzZWQsIHdlIGxhcmdlbHkgZmlndXJlZCBvdXQgd2F5 cyB0byBtYWtlIGl0IHdvcmsgd2l0aCBleGlzdGluZyBJQ0UgaW1wbGVtZW50YXRpb25zLiANCg0K V2UgYXJlIGNvbmZpZGVudCB0aGF0IG92ZXJ2aWV3IGRvZXMgbm90IGFjdHVhbGx5IGRlcGVuZCBv biBhbnl0aGluZyBpbiA1MjQ1LWJpcyBidXQgaW5zdGVhZCBqdXN0IGRlcGVuZHMgb24gNTI0NS4g DQoNCk5leHQgbGV0cyBkaXNjdXNzIHRyaWNrbGUtaWNlLiBUaGUgV2ViUlRDIHNldCBvZiBzcGVj cyBjdXJyZW50bHkgbm9ybWF0aXZlbHkgZGVwZW5kcyBvbiB0cmlja2xlIElDRS4gVGhlcmUgaXMg c29tZSBxdWVzdGlvbnMgaWYgdHJpY2tsZSBJQ0UgbWlnaHQgZGVwZW5kIG9uIDUyNDUtYmlzLiBT b21lIG9mIHRoZSB0cmlja2xlIElDRSAgYXV0aG9ycyBkbyBub3QgdGhpbmsgaXQgZG9lcy4gT25l IG9mIHRoZSBhdXRob3JzIHNhaWQgdGhlIGNoYWlycyBhc2tlZCB0aGVtIHRvIHJlZiA1MjQ1IGlu c3RlYWQgb2YgNTI0NWJpcyBhcyBib3RoIHRpY2tsZSBJQ0UgYW5kIDUyNDViaXMgd291bGQgYmUg ZG9uZSBhcm91bmQgdGhlIHNhbWUgdGltZS4gSW4gZ2VuZXJhbCwgdGhlIHdlYnJ0YyBjaGFpcnMg d291bGQgcHJlZmVyIHRvIG1ha2UgdGhlIFdlYlJUQyBkZXBlbmRlbmN5IGNsdXN0ZXIgYXMgc21h bGwgYXMgcG9zc2libGUuIElmIHRyaWNrbGUgaWNlIGFjdHVhbGx5IGdldHMgZG9uZSBiZWZvcmUg NTI0NWJpcywgYW5kIGl0IGRvZXMgbm90IGRlcGVuZCBvbiBhbnkgNTI0NWJpcyBmZWF0dXJlcywg dGhlbiBjbGVhcmx5IGlzIHNob3VsZCBiZSBjaGFuZ2VkIHRvIGp1c3QgZGVwZW5kIG9uIDUyNDUu IFRoZSBXRyByZXNwb25zaWJsZSBmb3IgNTI0NWJpcyBhbmQgdHJpY2tsZSBJQ0UgY2FuIGZpZ3Vy ZSBvdXQgd2hhdCB0aGV5IHdhbnQgdG8gZG8gYXMgYm90aCB0aGVzZXMgZHJhZnRzIHByb2dyZXNz LiBHaXZlbiB0aGVyZSBpcyBhIHN0cm9uZyBwb3NzaWJpbGl0eSB0aGF0IHRyaWNrbGUgaWNlIHdp bGwgb25seSByZWZlcmVuY2UgNTI0NSwgd2UgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIGlmIG92 ZXJ2aWV3IGRpZCBub3QgYnJpbmcgNTI0NWJpcyBpbnRvIHRoZSBXZWJSVEMgZGVwZW5kZW5jeSBj bHVzdGVyLiBJZiBvbiB0aGUgb3RoZXIgaGFuZCwgdHJpY2tsZSBJQ0UgZG9lcyBlbmQgdXAgZGVw ZW5kaW5nIG9uIDUyNDViaXMsIHRoZXJlIGlzIG5vIGhhcm0sIGFuZCBubyBuZWVkIHRvIGNoYW5n ZSBvdmVydmlldyB0byBwb2ludCBhdCA1MjQ1LiANCg0KVGhlcmUgYXJlIG90aGVyIGRyYWZ0cyB0 aGF0IGFyZSBub3JtYXRpdmUgZGVwZW5kZW5jaWVzIG9mIEpTRVAgYW5kIHRoZSBXZWJSVEMgY2x1 c3RlciB0aGF0IGFsc28gcG9pbnQgYXQgNTI0NWJpcy4gV2hlbiB3ZSBjb25zaWRlciB0aGUgdGVj aG5pY2FsIHRoaW5ncyB0aGVzZSBkcmFmdHMgbmVlZCwgaXQgc2VlbXMgbGlrZWx5IHRoZXkgY2Fu IGFsc28gcmVmZXJlbmNlIDUyNDUgaW5zdGVhZCBvZiA1MjQ1YmlzLiBGb3IgZXhhbXBsZSBkcmFm dC1pZXRmLWljZS1kdWFsc3RhY2stZmFpcm5lc3MsIGRyYWZ0LWlldGYtbW11c2ljLWljZS1zaXAt c2RwLCBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtYnVuZGxlLW5lZ290aWF0aW9uLCBhbmQgZHJhZnQt aWV0Zi1ydGN3ZWItdHJhbnNwb3J0cyAod2hpY2ggaXMgd2l0aCB0aGUgUkZDIEVkaXRvcikuIFRo ZSBhcmd1bWVudCBmb3IgdGhlIG90aGVycyBpcyByb3VnaGx5IHRoZSBzYW1lIGFzIGl0IGlzIHdp dGggdHJpY2tsZSBJQ0UuIA0KDQpDdWxsZW4gKHdpdGhvdXQgcmV2aWV3IGZyb20gbXkgY28tY2hh aXJzIGJ1dCB0cnlpbmcgdG8gcmVwcmVzZW50IHdoYXQgd2UgZGlzY3Vzc2VkIG9uIG91ciBjaGFp ciBjYWxsKQ0KDQoNClBTIC0gaWYgeW91IGFyZSB0cnlpbmcgdG8gZmlndXJlIG91dCBzb21lIG9m IHRoZSBkZXBlbmRlbmNpZXMgZm9yIHRoZSBXZWJSVEMgY2x1c3RlciwgeW91IG1pZ2h0IGZpbmQg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtamVubmluZ3MtcnRjd2ViLWRl cHMvP2luY2x1ZGVfdGV4dD0xIHVzZWZ1bCBidXQgaXQgaXMgbm90IDEwMCUgYWNjdXJhdGUuIA0K DQoNCg0KPiBPbiBNYXkgMTEsIDIwMTcsIGF0IDc6NDMgQU0sIEVyaWMgUmVzY29ybGEgPGVrckBy dGZtLmNvbT4gd3JvdGU6DQo+IA0KPiBRdWVzdGlvbiBmb3IgdGhlIGNoYWlycy4NCj4gDQo+IE9u IFRodSwgTWF5IDExLCAyMDE3IGF0IDEyOjQ0IEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gSGksDQo+IA0KPiBXaGF0IGlzIHRo ZSBzdGF0dXMgcmVnYXJkaW5nIHRoaXM/DQo+IA0KPiBSZWdhcmRzLA0KPiANCj4gQ2hyaXN0ZXIN Cj4gDQo+IE9uIDI2LzA0LzE3IDA2OjAyLCAiU2VhbiBUdXJuZXIiIDxzZWFuQHNuM3JkLmNvbT4g d3JvdGU6DQo+IA0KPiA+DQo+ID4+IE9uIEFwciAyMywgMjAxNywgYXQgMTQ6NDQsIENocmlzdGVy IEhvbG1iZXJnIA0KPiA+PjxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0K PiA+Pg0KPiA+PiBIaSwNCj4gPj4NCj4gPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4gLS0tLQ0KPiA+Pj4g RElTQ1VTUzoNCj4gPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4gLS0tLQ0KPiA+Pj4NCj4gPj4+IFlvdXIg Y2l0YXRpb24gdG8gSUNFIGlzIHRvIDUyNDUtYmlzLCBidXQgYXQgbGVhc3QgdGhlIEpTRVAgZWRp dG9yIA0KPiA+Pj5jb25zZW5zdXMgd2FzIHRoYXQgV2ViUlRDIGRlcGVuZGVkIG9uIDUyNDUsIHNv IHRoaXMgbmVlZHMgdG8gYmUgDQo+ID4+PnJlc29sdmVkIG9uZSB3YXkgb3IgdGhlIG90aGVyLg0K PiA+Pg0KPiA+PiBLZWVwIGluIG1pbmQgdGhhdCwgbm8gbWF0dGVyIHdoYXQgZHJhZnQtcnRjd2Vi LW92ZXJ2aWV3IGFuZCANCj4gPj5kcmFmdC1ydGN3ZWItanNlcCBleHBsaWNpdGx5IHNheSwgYm90 aCBzcGVjcyByZWZlcmVuY2UgNTI0NWJpcyANCj4gPj4qSU1QTElDSVRMWSosIGUuZy4sIHZpYSBk cmFmdC1tbXVzaWMtYnVuZGxlLCBkcmFmdC1pY2UtdHJpY2tsZSANCj4gPj5ldGMuLi4gQXMgSSBo YXZlIGluZGljYXRlZCBpbiB0aGUgcGFzdCwgaXQgd291bGQgY2F1c2UgY29uZnVzaW9uIHRvIHJl ZmVyZW5jZSBib3RoLg0KPiA+Pg0KPiA+PiBTbywgSSB0aGluayB3ZSBzaGFsbCByZWZlcmVuY2Ug NTI0NS1iaXMgZXZlcnl3aGVyZSAoSSBhbHNvIHRob3VnaHQgDQo+ID4+d2UgYWxyZWFkeSBkZWNp ZGVkIG5vIHRoYXQgaW4gdGhlIHBhc3QpLQ0KPiA+Pg0KPiA+PiBSZWdhcmRzLA0KPiA+Pg0KPiA+ PiBDaHJpc3Rlcg0KPiA+DQo+ID4vKiBiaWtlIHNoZWQgYWxlcnQ6DQo+ID4vKg0KPiA+LyogQXNz dW1pbmcgeW91wrlyZSBvZiB0aGUgbWluZCB0aGF0IGEgYmlzL3VwZGF0ZXMgZHJhZnQgaXMNCj4g Pi8qIHNpZ25hbGluZyB0byBhbGwgaW1wbGVtZW50b3JzIG9mIHRoZSBvcmlnaW5hbCBSRkMgdGhh dCB0aGUNCj4gPi8qIGludGVudGlvbiBpcyB0aGF0IGFsbCBpbXBsZW1lbnRhdGlvbnMgYmUgdXBk YXRlZCB0aGVuIGl0wrlzDQo+ID4vKiBhIGJpdCBtb3JlIHRoYW4gaW1wbGljaXQuDQo+ID4NCj4g PnNwdA0KPiA+DQo+IA0KPiANCg0K From nobody Sat May 13 06:44:39 2017 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 28B8D129494; Sat, 13 May 2017 06:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=unavailable 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 JXLVfJ6Cz2rZ; Sat, 13 May 2017 06:44:35 -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 A8552129C09; Sat, 13 May 2017 06:42:17 -0700 (PDT) Received: from smtp35.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp35.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id DD655598C; Sat, 13 May 2017 09:42:06 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp35.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 0A1685988; Sat, 13 May 2017 09:42:05 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.67] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Sat, 13 May 2017 09:42:06 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CBA05BC@ESESSMB109.ericsson.se> Date: Sat, 13 May 2017 07:42:04 -0600 Cc: Eric Rescorla , Sean Turner , The IESG , "rtcweb-chairs@ietf.org" , RTCWeb IETF , "draft-ietf-rtcweb-overview@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <149285978295.25905.7347383325486705546.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CB805F3@ESESSMB109.ericsson.se> <15D737F9-2F65-45C5-AA26-946910B4030F@sn3rd.com> <7594FB04B1934943A5C02806D1A2204B4CBA05BC@ESESSMB109.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [rtcweb] Eric Rescorla's Discuss on draft-ietf-rtcweb-overview-18: (with DISCUSS and COMMENT) 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, 13 May 2017 13:44:37 -0000 OK, so let me try to give some really clear guidance here ... if you are = writing a draft that does not need to normatively depend on another = draft, it should not normatively depended on that draft.=20 I really doubt anyone is going to argue with that so lets make it so.=20 > On May 13, 2017, at 1:54 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 > As co-chair of a number of the dependencies, we have been discussing = what to reference a number of times, and we have also changed the = references. We can't keep changing back and forth.=20 >=20 > In addition, I don't think WG X can decide what the drafts of WG Y = reference. There needs to be a collaborative decision. >=20 > "We also assumed that some new work was going to require changes in = ICE but as that work went progressed, we largely figured out ways to = make it work with existing ICE implementations." >=20 > Is this "discovery" documented somewhere? >=20 > "If trickle ice actually gets done before 5245bis, and it does not = depend on any 5245bis features, then clearly is should be changed to = just depend on 5245." >=20 > First, we need to agree on whether trickle depends on 5245bis features = or not. >=20 > Second, as co-author of 5245bis, I have asked the chairs to initiate = the road towards WGLC, so I would hope both 5245bis and trickle-ice = could be done more or less at the same time. >=20 > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@iii.ca]=20 > Sent: 13 May 2017 01:55 > To: Eric Rescorla ; Christer Holmberg = > Cc: Sean Turner ; The IESG ; = rtcweb-chairs@ietf.org; RTCWeb IETF ; = draft-ietf-rtcweb-overview@ietf.org > Subject: Re: [rtcweb] Eric Rescorla's Discuss on = draft-ietf-rtcweb-overview-18: (with DISCUSS and COMMENT) >=20 >=20 > Let me try and answer with the caveat that I may get this wrong and = need to be corrected by my co-chairs... >=20 > TL;DR - The chairs recommend changing the ref in overview to point at = 5245 instead of 5245-bis >=20 >=20 > here is the longer version....=20 >=20 > First a side note on how we got here. Some of the reasons we set up = dependencies like they are is that many years ago we made guess about = what order work would get completed on and, shockingly, some predictions = of standards developments timelines were less than perfect. We also = assumed that some new work was going to require changes in ICE but as = that work went progressed, we largely figured out ways to make it work = with existing ICE implementations.=20 >=20 > We are confident that overview does not actually depend on anything in = 5245-bis but instead just depends on 5245.=20 >=20 > Next lets discuss trickle-ice. The WebRTC set of specs currently = normatively depends on trickle ICE. There is some questions if trickle = ICE might depend on 5245-bis. Some of the trickle ICE authors do not = think it does. One of the authors said the chairs asked them to ref 5245 = instead of 5245bis as both tickle ICE and 5245bis would be done around = the same time. In general, the webrtc chairs would prefer to make the = WebRTC dependency cluster as small as possible. If trickle ice actually = gets done before 5245bis, and it does not depend on any 5245bis = features, then clearly is should be changed to just depend on 5245. The = WG responsible for 5245bis and trickle ICE can figure out what they want = to do as both theses drafts progress. Given there is a strong = possibility that trickle ice will only reference 5245, we think it would = be better if overview did not bring 5245bis into the WebRTC dependency = cluster. If on the other hand, trickle ICE does end up depending on = 5245bis, there is no harm, and no need to change overview to point at = 5245.=20 >=20 > There are other drafts that are normative dependencies of JSEP and the = WebRTC cluster that also point at 5245bis. When we consider the = technical things these drafts need, it seems likely they can also = reference 5245 instead of 5245bis. For example = draft-ietf-ice-dualstack-fairness, draft-ietf-mmusic-ice-sip-sdp, = draft-ietf-mmusic-sdp-bundle-negotiation, and = draft-ietf-rtcweb-transports (which is with the RFC Editor). The = argument for the others is roughly the same as it is with trickle ICE.=20= >=20 > Cullen (without review from my co-chairs but trying to represent what = we discussed on our chair call) >=20 >=20 > PS - if you are trying to figure out some of the dependencies for the = WebRTC cluster, you might find = https://datatracker.ietf.org/doc/draft-jennings-rtcweb-deps/?include_text=3D= 1 useful but it is not 100% accurate.=20 >=20 >=20 >=20 >> On May 11, 2017, at 7:43 AM, Eric Rescorla wrote: >>=20 >> Question for the chairs. >>=20 >> On Thu, May 11, 2017 at 12:44 AM, Christer Holmberg = wrote: >> Hi, >>=20 >> What is the status regarding this? >>=20 >> Regards, >>=20 >> Christer >>=20 >> On 26/04/17 06:02, "Sean Turner" wrote: >>=20 >>>=20 >>>> On Apr 23, 2017, at 14:44, Christer Holmberg=20 >>>> wrote: >>>>=20 >>>> Hi, >>>>=20 >>>>> ------------------------------------------------------------------ >>>>> ---- >>>>> DISCUSS: >>>>> ------------------------------------------------------------------ >>>>> ---- >>>>>=20 >>>>> Your citation to ICE is to 5245-bis, but at least the JSEP editor=20= >>>>> consensus was that WebRTC depended on 5245, so this needs to be=20 >>>>> resolved one way or the other. >>>>=20 >>>> Keep in mind that, no matter what draft-rtcweb-overview and=20 >>>> draft-rtcweb-jsep explicitly say, both specs reference 5245bis=20 >>>> *IMPLICITLY*, e.g., via draft-mmusic-bundle, draft-ice-trickle=20 >>>> etc... As I have indicated in the past, it would cause confusion to = reference both. >>>>=20 >>>> So, I think we shall reference 5245-bis everywhere (I also thought=20= >>>> we already decided no that in the past)- >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>=20 >>> /* bike shed alert: >>> /* >>> /* Assuming you=C2=B9re of the mind that a bis/updates draft is >>> /* signaling to all implementors of the original RFC that the >>> /* intention is that all implementations be updated then it=C2=B9s >>> /* a bit more than implicit. >>>=20 >>> spt >>>=20 >>=20 >>=20 >=20 From nobody Sat May 13 10:34:26 2017 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 169E9129C1D; Sat, 13 May 2017 10:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 HW-fH1f4iDIv; Sat, 13 May 2017 10:34:14 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 AC2B0129BBF; Sat, 13 May 2017 10:31:39 -0700 (PDT) X-AuditID: c1b4fb30-29dff7000000015f-d7-591742f8978e Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FA.06.00351.8F247195; Sat, 13 May 2017 19:31:37 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0339.000; Sat, 13 May 2017 19:31:35 +0200 From: Christer Holmberg To: Cullen Jennings CC: Eric Rescorla , Sean Turner , The IESG , "rtcweb-chairs@ietf.org" , "RTCWeb IETF" , "draft-ietf-rtcweb-overview@ietf.org" Thread-Topic: [rtcweb] Eric Rescorla's Discuss on draft-ietf-rtcweb-overview-18: (with DISCUSS and COMMENT) Thread-Index: AQHSu1nlcZL8BStkfUysDoOyMAqI5qHTV0EQgAODp4CAGBVbgIAAMMGAgAI9D4CAAKUNEIAAQg4AgABAHwA= Date: Sat, 13 May 2017 17:31:35 +0000 Message-ID: <225E4246-AB30-4877-9DCF-D5D2A8ABDF18@ericsson.com> References: <149285978295.25905.7347383325486705546.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CB805F3@ESESSMB109.ericsson.se> <15D737F9-2F65-45C5-AA26-946910B4030F@sn3rd.com> <7594FB04B1934943A5C02806D1A2204B4CBA05BC@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-A22EA840-D19E-48F6-81FC-77B7503CE841"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsUyM2K7se5PJ/FIg99XVSy2vD7BZrHi9Tl2 iw/rfzBazPgzkdmi5+0NFou1/9rZLa6samR2YPdYsuQnk8fl8x8ZPSY/bmP2OHiQMYAlissm JTUnsyy1SN8ugSvj2o7d7AVnmhkrDmw8xtbA2NTA2MXIySEhYCLR+/gfaxcjF4eQwBFGiU9N P5kgnCWMEsffbAHKcHCwCVhIdP/TBmkQEVCWOLfjLjNIDbPAf0aJ//s/g9UIC+RIPDzGAlGT K3Fzw0woO0ni9YffzCA2i4CqRNua80wgNq+AvcT7aZvYIXY9ZJa48nE6G0iCU8BKYtLn86wg NqOAmMT3U2vAGpgFxCVuPZnPBHG1iMTDi6fZIGxRiZdQHzALTGaUODO7jRVig6DEyZlPWCYw Cs9C0j8LWd0sJHUQRZoS+7uXQ9mKElO6H7JD2NYSM34dZIOwTSVeH/3IiKxmASPHKkbR4tTi pNx0IyO91KLM5OLi/Dy9vNSSTYzAKD245bfBDsaXzx0PMQpwMCrx8D5YIBYpxJpYVlyZe4hR BWjOow2rLzBKseTl56UqifAesBKPFOJNSaysSi3Kjy8qzUktPsQozcGiJM7ruO9ChJBAemJJ anZqakFqEUyWiYNTqoFxQ4rlRdUM58sPOH8vfhatzZu64vlNje9L5yutMPVnZWxOd6lfvv6/ 7abMSeqMU9z2btk4pet2ua7V6x3rps+snWSZynj7VPOvc0rG1pFcN4r1O/c+4D2QvNfoQhiD D6v3t0SZh+YXNpUu3BmXcf6QlsnfZcuYzNcsvpho3a7es0m++s6cS2tvKbEUZyQaajEXFScC AP89PXXaAgAA Archived-At: Subject: Re: [rtcweb] Eric Rescorla's Discuss on draft-ietf-rtcweb-overview-18: (with DISCUSS and COMMENT) 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, 13 May 2017 17:34:17 -0000 --Apple-Mail-A22EA840-D19E-48F6-81FC-77B7503CE841 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGksDQoNClNvLCBpZiB0aGUgY2hhbmdlcyBkb25lIGluIDUyNDViaXMgYXJlbid0IG5lZWRlZCwg d2h5IGFyZSB3ZSB3b3JraW5nIG9uIDUyNDViaXMgdG8gYmVnaW4gd2l0aD8/PyBXZSBkaWQgd2Ug c3BlbmQgYWxsIHRoYXQgdGltZSBvbiBtb2RpZnlpbmcgVGEgZXRjPz8/DQoNClJlZ2FyZHMsDQoN CkNocmlzdGVyDQoNCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQo+IE9uIDEzIE1heSAyMDE3LCBh dCAxNi40MiwgQ3VsbGVuIEplbm5pbmdzIDxmbHVmZnlAaWlpLmNhPiB3cm90ZToNCj4gDQo+IA0K PiBPSywgc28gbGV0IG1lIHRyeSB0byBnaXZlIHNvbWUgcmVhbGx5IGNsZWFyIGd1aWRhbmNlIGhl cmUgLi4uIGlmIHlvdSBhcmUgd3JpdGluZyBhIGRyYWZ0IHRoYXQgZG9lcyBub3QgbmVlZCB0byBu b3JtYXRpdmVseSBkZXBlbmQgb24gYW5vdGhlciBkcmFmdCwgaXQgc2hvdWxkIG5vdCBub3JtYXRp dmVseSBkZXBlbmRlZCBvbiB0aGF0IGRyYWZ0LiANCj4gDQo+IEkgcmVhbGx5IGRvdWJ0IGFueW9u ZSBpcyBnb2luZyB0byBhcmd1ZSB3aXRoIHRoYXQgc28gbGV0cyBtYWtlIGl0IHNvLiANCj4gDQo+ PiBPbiBNYXkgMTMsIDIwMTcsIGF0IDE6NTQgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPj4gDQo+PiBIaSwNCj4+IA0KPj4gQXMg Y28tY2hhaXIgb2YgYSBudW1iZXIgb2YgdGhlIGRlcGVuZGVuY2llcywgd2UgaGF2ZSBiZWVuIGRp c2N1c3Npbmcgd2hhdCB0byByZWZlcmVuY2UgYSBudW1iZXIgb2YgdGltZXMsIGFuZCB3ZSBoYXZl IGFsc28gY2hhbmdlZCB0aGUgcmVmZXJlbmNlcy4gV2UgY2FuJ3Qga2VlcCBjaGFuZ2luZyBiYWNr IGFuZCBmb3J0aC4gDQo+PiANCj4+IEluIGFkZGl0aW9uLCBJIGRvbid0IHRoaW5rIFdHIFggY2Fu IGRlY2lkZSB3aGF0IHRoZSBkcmFmdHMgb2YgV0cgWSByZWZlcmVuY2UuIFRoZXJlIG5lZWRzIHRv IGJlIGEgY29sbGFib3JhdGl2ZSBkZWNpc2lvbi4NCj4+IA0KPj4gIldlIGFsc28gYXNzdW1lZCB0 aGF0IHNvbWUgbmV3IHdvcmsgd2FzIGdvaW5nIHRvIHJlcXVpcmUgY2hhbmdlcyBpbiBJQ0UgYnV0 IGFzIHRoYXQgd29yayB3ZW50IHByb2dyZXNzZWQsIHdlIGxhcmdlbHkgZmlndXJlZCBvdXQgd2F5 cyB0byBtYWtlIGl0IHdvcmsgd2l0aCBleGlzdGluZyBJQ0UgaW1wbGVtZW50YXRpb25zLiINCj4+ IA0KPj4gSXMgdGhpcyAiZGlzY292ZXJ5IiBkb2N1bWVudGVkIHNvbWV3aGVyZT8NCj4+IA0KPj4g IklmIHRyaWNrbGUgaWNlIGFjdHVhbGx5IGdldHMgZG9uZSBiZWZvcmUgNTI0NWJpcywgYW5kIGl0 IGRvZXMgbm90IGRlcGVuZCBvbiBhbnkgNTI0NWJpcyBmZWF0dXJlcywgdGhlbiBjbGVhcmx5IGlz IHNob3VsZCBiZSBjaGFuZ2VkIHRvIGp1c3QgZGVwZW5kIG9uIDUyNDUuIg0KPj4gDQo+PiBGaXJz dCwgd2UgbmVlZCB0byBhZ3JlZSBvbiB3aGV0aGVyIHRyaWNrbGUgZGVwZW5kcyBvbiA1MjQ1Ymlz IGZlYXR1cmVzIG9yIG5vdC4NCj4+IA0KPj4gU2Vjb25kLCBhcyBjby1hdXRob3Igb2YgNTI0NWJp cywgSSBoYXZlIGFza2VkIHRoZSBjaGFpcnMgdG8gaW5pdGlhdGUgdGhlIHJvYWQgdG93YXJkcyBX R0xDLCBzbyBJIHdvdWxkIGhvcGUgYm90aCA1MjQ1YmlzIGFuZCB0cmlja2xlLWljZSBjb3VsZCBi ZSBkb25lIG1vcmUgb3IgbGVzcyBhdCB0aGUgc2FtZSB0aW1lLg0KPj4gDQo+PiBSZWdhcmRzLA0K Pj4gDQo+PiBDaHJpc3Rlcg0KPj4gDQo+PiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+PiBGcm9tOiBDdWxsZW4gSmVubmluZ3MgW21haWx0bzpmbHVmZnlAaWlpLmNhXSANCj4+IFNl bnQ6IDEzIE1heSAyMDE3IDAxOjU1DQo+PiBUbzogRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29t PjsgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCj4+ IENjOiBTZWFuIFR1cm5lciA8c2VhbkBzbjNyZC5jb20+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9y Zz47IHJ0Y3dlYi1jaGFpcnNAaWV0Zi5vcmc7IFJUQ1dlYiBJRVRGIDxydGN3ZWJAaWV0Zi5vcmc+ OyBkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmlld0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFty dGN3ZWJdIEVyaWMgUmVzY29ybGEncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtcnRjd2ViLW92ZXJ2 aWV3LTE4OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPj4gDQo+PiANCj4+IExldCBtZSB0 cnkgYW5kIGFuc3dlciB3aXRoIHRoZSBjYXZlYXQgdGhhdCBJIG1heSBnZXQgdGhpcyB3cm9uZyBh bmQgbmVlZCB0byBiZSBjb3JyZWN0ZWQgYnkgbXkgY28tY2hhaXJzLi4uDQo+PiANCj4+IFRMO0RS IC0gVGhlIGNoYWlycyByZWNvbW1lbmQgY2hhbmdpbmcgdGhlIHJlZiBpbiBvdmVydmlldyB0byBw b2ludCBhdCA1MjQ1IGluc3RlYWQgb2YgNTI0NS1iaXMNCj4+IA0KPj4gDQo+PiBoZXJlIGlzIHRo ZSBsb25nZXIgdmVyc2lvbi4uLi4gDQo+PiANCj4+IEZpcnN0IGEgc2lkZSBub3RlIG9uIGhvdyB3 ZSBnb3QgaGVyZS4gU29tZSBvZiB0aGUgcmVhc29ucyB3ZSBzZXQgdXAgZGVwZW5kZW5jaWVzICBs aWtlIHRoZXkgYXJlIGlzIHRoYXQgbWFueSB5ZWFycyBhZ28gd2UgbWFkZSBndWVzcyBhYm91dCB3 aGF0IG9yZGVyIHdvcmsgd291bGQgZ2V0IGNvbXBsZXRlZCBvbiBhbmQsIHNob2NraW5nbHksIHNv bWUgcHJlZGljdGlvbnMgb2Ygc3RhbmRhcmRzIGRldmVsb3BtZW50cyB0aW1lbGluZXMgd2VyZSBs ZXNzIHRoYW4gcGVyZmVjdC4gV2UgYWxzbyBhc3N1bWVkIHRoYXQgc29tZSBuZXcgd29yayB3YXMg Z29pbmcgdG8gcmVxdWlyZSBjaGFuZ2VzIGluIElDRSBidXQgYXMgdGhhdCB3b3JrIHdlbnQgcHJv Z3Jlc3NlZCwgd2UgbGFyZ2VseSBmaWd1cmVkIG91dCB3YXlzIHRvIG1ha2UgaXQgd29yayB3aXRo IGV4aXN0aW5nIElDRSBpbXBsZW1lbnRhdGlvbnMuIA0KPj4gDQo+PiBXZSBhcmUgY29uZmlkZW50 IHRoYXQgb3ZlcnZpZXcgZG9lcyBub3QgYWN0dWFsbHkgZGVwZW5kIG9uIGFueXRoaW5nIGluIDUy NDUtYmlzIGJ1dCBpbnN0ZWFkIGp1c3QgZGVwZW5kcyBvbiA1MjQ1LiANCj4+IA0KPj4gTmV4dCBs ZXRzIGRpc2N1c3MgdHJpY2tsZS1pY2UuIFRoZSBXZWJSVEMgc2V0IG9mIHNwZWNzIGN1cnJlbnRs eSBub3JtYXRpdmVseSBkZXBlbmRzIG9uIHRyaWNrbGUgSUNFLiBUaGVyZSBpcyBzb21lIHF1ZXN0 aW9ucyBpZiB0cmlja2xlIElDRSBtaWdodCBkZXBlbmQgb24gNTI0NS1iaXMuIFNvbWUgb2YgdGhl IHRyaWNrbGUgSUNFICBhdXRob3JzIGRvIG5vdCB0aGluayBpdCBkb2VzLiBPbmUgb2YgdGhlIGF1 dGhvcnMgc2FpZCB0aGUgY2hhaXJzIGFza2VkIHRoZW0gdG8gcmVmIDUyNDUgaW5zdGVhZCBvZiA1 MjQ1YmlzIGFzIGJvdGggdGlja2xlIElDRSBhbmQgNTI0NWJpcyB3b3VsZCBiZSBkb25lIGFyb3Vu ZCB0aGUgc2FtZSB0aW1lLiBJbiBnZW5lcmFsLCB0aGUgd2VicnRjIGNoYWlycyB3b3VsZCBwcmVm ZXIgdG8gbWFrZSB0aGUgV2ViUlRDIGRlcGVuZGVuY3kgY2x1c3RlciBhcyBzbWFsbCBhcyBwb3Nz aWJsZS4gSWYgdHJpY2tsZSBpY2UgYWN0dWFsbHkgZ2V0cyBkb25lIGJlZm9yZSA1MjQ1YmlzLCBh bmQgaXQgZG9lcyBub3QgZGVwZW5kIG9uIGFueSA1MjQ1YmlzIGZlYXR1cmVzLCB0aGVuIGNsZWFy bHkgaXMgc2hvdWxkIGJlIGNoYW5nZWQgdG8ganVzdCBkZXBlbmQgb24gNTI0NS4gVGhlIFdHIHJl c3BvbnNpYmxlIGZvciA1MjQ1YmlzIGFuZCB0cmlja2xlIElDRSBjYW4gZmlndXJlIG91dCB3aGF0 IHRoZXkgd2FudCB0byBkbyBhcyBib3RoIHRoZXNlcyBkcmFmdHMgcHJvZ3Jlc3MuIEdpdmVuIHRo ZXJlIGlzIGEgc3Ryb25nIHBvc3NpYmlsaXR5IHRoYXQgdHJpY2tsZSBpY2Ugd2lsbCBvbmx5IHJl ZmVyZW5jZSA1MjQ1LCB3ZSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgaWYgb3ZlcnZpZXcgZGlk IG5vdCBicmluZyA1MjQ1YmlzIGludG8gdGhlIFdlYlJUQyBkZXBlbmRlbmN5IGNsdXN0ZXIuIElm IG9uIHRoZSBvdGhlciBoYW5kLCB0cmlja2xlIElDRSBkb2VzIGVuZCB1cCBkZXBlbmRpbmcgb24g NTI0NWJpcywgdGhlcmUgaXMgbm8gaGFybSwgYW5kIG5vIG5lZWQgdG8gY2hhbmdlIG92ZXJ2aWV3 IHRvIHBvaW50IGF0IDUyNDUuIA0KPj4gDQo+PiBUaGVyZSBhcmUgb3RoZXIgZHJhZnRzIHRoYXQg YXJlIG5vcm1hdGl2ZSBkZXBlbmRlbmNpZXMgb2YgSlNFUCBhbmQgdGhlIFdlYlJUQyBjbHVzdGVy IHRoYXQgYWxzbyBwb2ludCBhdCA1MjQ1YmlzLiBXaGVuIHdlIGNvbnNpZGVyIHRoZSB0ZWNobmlj YWwgdGhpbmdzIHRoZXNlIGRyYWZ0cyBuZWVkLCBpdCBzZWVtcyBsaWtlbHkgdGhleSBjYW4gYWxz byByZWZlcmVuY2UgNTI0NSBpbnN0ZWFkIG9mIDUyNDViaXMuIEZvciBleGFtcGxlIGRyYWZ0LWll dGYtaWNlLWR1YWxzdGFjay1mYWlybmVzcywgZHJhZnQtaWV0Zi1tbXVzaWMtaWNlLXNpcC1zZHAs IGRyYWZ0LWlldGYtbW11c2ljLXNkcC1idW5kbGUtbmVnb3RpYXRpb24sIGFuZCBkcmFmdC1pZXRm LXJ0Y3dlYi10cmFuc3BvcnRzICh3aGljaCBpcyB3aXRoIHRoZSBSRkMgRWRpdG9yKS4gVGhlIGFy Z3VtZW50IGZvciB0aGUgb3RoZXJzIGlzIHJvdWdobHkgdGhlIHNhbWUgYXMgaXQgaXMgd2l0aCB0 cmlja2xlIElDRS4gDQo+PiANCj4+IEN1bGxlbiAod2l0aG91dCByZXZpZXcgZnJvbSBteSBjby1j aGFpcnMgYnV0IHRyeWluZyB0byByZXByZXNlbnQgd2hhdCB3ZSBkaXNjdXNzZWQgb24gb3VyIGNo YWlyIGNhbGwpDQo+PiANCj4+IA0KPj4gUFMgLSBpZiB5b3UgYXJlIHRyeWluZyB0byBmaWd1cmUg b3V0IHNvbWUgb2YgdGhlIGRlcGVuZGVuY2llcyBmb3IgdGhlIFdlYlJUQyBjbHVzdGVyLCB5b3Ug bWlnaHQgZmluZCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qZW5uaW5n cy1ydGN3ZWItZGVwcy8/aW5jbHVkZV90ZXh0PTEgdXNlZnVsIGJ1dCBpdCBpcyBub3QgMTAwJSBh Y2N1cmF0ZS4gDQo+PiANCj4+IA0KPj4gDQo+Pj4gT24gTWF5IDExLCAyMDE3LCBhdCA3OjQzIEFN LCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+IHdyb3RlOg0KPj4+IA0KPj4+IFF1ZXN0aW9u IGZvciB0aGUgY2hhaXJzLg0KPj4+IA0KPj4+IE9uIFRodSwgTWF5IDExLCAyMDE3IGF0IDEyOjQ0 IEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3 cm90ZToNCj4+PiBIaSwNCj4+PiANCj4+PiBXaGF0IGlzIHRoZSBzdGF0dXMgcmVnYXJkaW5nIHRo aXM/DQo+Pj4gDQo+Pj4gUmVnYXJkcywNCj4+PiANCj4+PiBDaHJpc3Rlcg0KPj4+IA0KPj4+PiBP biAyNi8wNC8xNyAwNjowMiwgIlNlYW4gVHVybmVyIiA8c2VhbkBzbjNyZC5jb20+IHdyb3RlOg0K Pj4+PiANCj4+Pj4gDQo+Pj4+PiBPbiBBcHIgMjMsIDIwMTcsIGF0IDE0OjQ0LCBDaHJpc3RlciBI b2xtYmVyZyANCj4+Pj4+IDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0K Pj4+Pj4gDQo+Pj4+PiBIaSwNCj4+Pj4+IA0KPj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4+IC0tLS0N Cj4+Pj4+PiBESVNDVVNTOg0KPj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4+IC0tLS0NCj4+Pj4+PiAN Cj4+Pj4+PiBZb3VyIGNpdGF0aW9uIHRvIElDRSBpcyB0byA1MjQ1LWJpcywgYnV0IGF0IGxlYXN0 IHRoZSBKU0VQIGVkaXRvciANCj4+Pj4+PiBjb25zZW5zdXMgd2FzIHRoYXQgV2ViUlRDIGRlcGVu ZGVkIG9uIDUyNDUsIHNvIHRoaXMgbmVlZHMgdG8gYmUgDQo+Pj4+Pj4gcmVzb2x2ZWQgb25lIHdh eSBvciB0aGUgb3RoZXIuDQo+Pj4+PiANCj4+Pj4+IEtlZXAgaW4gbWluZCB0aGF0LCBubyBtYXR0 ZXIgd2hhdCBkcmFmdC1ydGN3ZWItb3ZlcnZpZXcgYW5kIA0KPj4+Pj4gZHJhZnQtcnRjd2ViLWpz ZXAgZXhwbGljaXRseSBzYXksIGJvdGggc3BlY3MgcmVmZXJlbmNlIDUyNDViaXMgDQo+Pj4+PiAq SU1QTElDSVRMWSosIGUuZy4sIHZpYSBkcmFmdC1tbXVzaWMtYnVuZGxlLCBkcmFmdC1pY2UtdHJp Y2tsZSANCj4+Pj4+IGV0Yy4uLiBBcyBJIGhhdmUgaW5kaWNhdGVkIGluIHRoZSBwYXN0LCBpdCB3 b3VsZCBjYXVzZSBjb25mdXNpb24gdG8gcmVmZXJlbmNlIGJvdGguDQo+Pj4+PiANCj4+Pj4+IFNv LCBJIHRoaW5rIHdlIHNoYWxsIHJlZmVyZW5jZSA1MjQ1LWJpcyBldmVyeXdoZXJlIChJIGFsc28g dGhvdWdodCANCj4+Pj4+IHdlIGFscmVhZHkgZGVjaWRlZCBubyB0aGF0IGluIHRoZSBwYXN0KS0N Cj4+Pj4+IA0KPj4+Pj4gUmVnYXJkcywNCj4+Pj4+IA0KPj4+Pj4gQ2hyaXN0ZXINCj4+Pj4gDQo+ Pj4+IC8qIGJpa2Ugc2hlZCBhbGVydDoNCj4+Pj4gLyoNCj4+Pj4gLyogQXNzdW1pbmcgeW91wrly ZSBvZiB0aGUgbWluZCB0aGF0IGEgYmlzL3VwZGF0ZXMgZHJhZnQgaXMNCj4+Pj4gLyogc2lnbmFs aW5nIHRvIGFsbCBpbXBsZW1lbnRvcnMgb2YgdGhlIG9yaWdpbmFsIFJGQyB0aGF0IHRoZQ0KPj4+ PiAvKiBpbnRlbnRpb24gaXMgdGhhdCBhbGwgaW1wbGVtZW50YXRpb25zIGJlIHVwZGF0ZWQgdGhl biBpdMK5cw0KPj4+PiAvKiBhIGJpdCBtb3JlIHRoYW4gaW1wbGljaXQuDQo+Pj4+IA0KPj4+PiBz cHQNCj4+Pj4gDQo+Pj4gDQo+Pj4gDQo+PiANCj4gDQo= --Apple-Mail-A22EA840-D19E-48F6-81FC-77B7503CE841 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8zCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF+TCCA+GgAwIBAgIQMQ1yPcGTNYDzhYWhrkFQyDAN BgkqhkiG9w0BAQUFADA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MjAeFw0xNDExMDQxMjI4MTlaFw0xNzExMDQxMjI4MThaMG8xETAPBgNV BAoMCEVyaWNzc29uMRowGAYDVQQDDBFDaHJpc3RlciBIb2xtYmVyZzEtMCsGCSqGSIb3DQEJARYe Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tMQ8wDQYDVQQFEwZMTUZDSEgwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCMb7fHWIV9CIFYYov86NR/6ibdVV0I+ZqVLE21zQB7otFv 6DTKlVXE7iiC4HCvMhlGkg3/qFmAhAti5Z1Z7+5eEMEIP5JJEZ7fMm6BME33Bkdgg4EfJrq4FUG2 8Hw2//0qx3jZWvK2W751AmEuUJ5nkZ6F00GnzJmOhbveadC8E5keqwow9ria0/WazHiK3wxzjban oQaZIA+oCKj5YyCv8cCTaSk4pEAbXwxthJ97BaZPahsnb4EZEP08gxR5IE9NRi47Eqh6LtBjiWpa B42EmCEBxc2uIQ87tlJ0e2SvCo74rqxndXtUeaWauMjjt4DnhJdiXZY244D5J1gWssRFAgMBAAGj ggHEMIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmlj c3Nvbm5saW5kaXZpZHVhbGNhdjIuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNlcjApBgNVHREEIjAggR5j aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIw OjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9D UFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBRUo03/DrRAW2xpMmhN 2uGkvDgx6jAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAw DQYJKoZIhvcNAQEFBQADggIBALbwqG5inhl/xPxsuQWcH7GOUZIPAw0JlKltVQ/TlsF7ig0J1iyz ao6GsXItJ9H3WZPrCy5EQchJm7qcn2kKX8OGb+Yr53FisLR2gx+qkrQMDOdix9Was0cvIjDWjAQn EZbxz/a+dzdAP0TrwNvD8282bIy0fCt/3uoBfzMnvQG+4wG018bDunc+NCj1FkSKkSRb9fP2Z2li 65pfJcxtGIfb5zsXJZG4Gtbe0/hxlj3NccjB/zVPO7PQ+lnWmxtOiJQ2loA+62vQreUQr328XK4I HFnoU+zXiVfUN2urvvirQH7Ha70TBMa20J8Nn2aEvY6QYMEQJhAiVmNTiv4EGGv5heX5vb8yaj7p r4YIvb6D0r+pwpvfEE8YhAEWJgCZP7k5zQwhrpuSF/s+wEruXo59sq9bOCefghktc5fwDu8ved98 cifRPUnuT/c5slJJ8LjFn8d+LnGklUdFA9kLjIJVVx+TM4D/OTaRG+mPFbY2pTyR0V84PG7HLeku pNsFzcme7IBkQ+1zkb9hjz6pyiodf6rh7ph+8XHWNgzbC5PdGCANg8fVWrxqqOoEzvcUcPMy6XXJ s0JWhWas8mJdHq2kGDDEpA7BbBatmtEqziXRnYGJeQK3eMDXXtmOeBSA4y7YZ47y+CxvbknSQ5dy ghwkEq+a7ORPGVjsjtWJYJ6dMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZI hvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJv b3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmlj c3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcN AQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/yQori I+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8GoFOvtuV HNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAU bmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq5/yHaS48jCsOBAU0 TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9 dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpa mOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLxBiA141dhCy5EScOyNajrAXQupsDn vr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wjNnAA6MqeaTS9HchPtBvOrah/cTWzXzGj wMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUF BzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6 Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNl cjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYB BQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1Ud HwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25l cmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQE AwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+a lgzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUieg mAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGagdRc mH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/O zFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr /oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko 3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8 b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NY sjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+ 9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYICljCCApICAQEwTjA6MREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQMQ1yPcGTNYDz hYWhrkFQyDAJBgUrDgMCGgUAoIIBHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA1MTMxNzMxMzRaMCMGCSqGSIb3DQEJBDEWBBS00XemUrT7hNfeHQyFzlRgBorA 9jBdBgkrBgEEAYI3EAQxUDBOMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYyAhAxDXI9wZM1gPOFhaGuQVDIMF8GCyqGSIb3DQEJEAILMVCg TjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MgIQMQ1yPcGTNYDzhYWhrkFQyDANBgkqhkiG9w0BAQEFAASCAQBEGhTkJgmX2ruvMFxPY9aQ z2AXG37jB94iHV3eghq4oNPoGZtf7kyRNBxiWSw4KxfZck2Asj69s6VPxSralJIflcrm3CseqdES Tk6JP0laT1SCwXA8CJ1N7rjzNQMYtiRMydQlhLgx+O5YvE0TM3YiNxAG/fFJVX5isU5UqF7/qB98 R9YLoMmMwwHOH/tXbnhjq/4jWP907dZmUfv2IDBRYlxUQww4M0ryMo4whOCOK8NoCCFJefpkJcKQ 9NsrPcQCOBvyYSMjfTUZFgOqvPzPQvzVcjDpy4OOnh3wiewoaf4LA0WP0cQoQo7WPVlkqcd0y3sL U07vpIGgP3m9COLOAAAAAAAA --Apple-Mail-A22EA840-D19E-48F6-81FC-77B7503CE841-- From nobody Sat May 13 10:52:45 2017 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 BEE6712E046 for ; Sat, 13 May 2017 10:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 e7vzY_OX6nvx for ; Sat, 13 May 2017 10:52:37 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::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 DAA4E12EA52 for ; Sat, 13 May 2017 10:49:44 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id 132so1945097ybq.1 for ; Sat, 13 May 2017 10:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OwmdI0qKx2bUdwlIh+nd1o+XjTeGQ4dAYweRalJoMlM=; b=dOCuQbx1MZDeA2ilueHvaw7EkQ8N6o1QMvVnlwISHCtlpjk0fo6TUgPf1YgZkFP5jk sMArW+DgvSwFP+kNEYeHpFs8M++b0vIZhmtn9+K5c9iydHr8+GSmacKXCHkLLIisDw+l nc52qXD+YSN0SXcaYNrYkqAyKwXLJrP+dXiQ6aCjeNjmGxmFIasZDdvvuwYXzyn5vhlj tV1rsA2/JRtdb3Je6RSwrjJhQ0p6E3oVmCf0Odl2wixftQGsr6DPrgY2EzfPFpYcMk94 SsuJsOG/Iwzte5+b1Hr8Hj1jwdyc4dfJ76ehqq6fNCnF91YTcCVicvMolHqcOJ6pgaXp lguw== 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=OwmdI0qKx2bUdwlIh+nd1o+XjTeGQ4dAYweRalJoMlM=; b=Wb73z+tyUWAeXB40BddYTSw5A7mf85g0h9rqPSIVcSKSpg9xZNVJKvPdFWEWAIlRFv KLkEezC8jHbSWozksmq9gOryHfTeo0y//FVmBwCgsx0TVN/bDLqOuaYaWtWGvDiCPaMl JyR0FVY+ug9PtT2g+MuhXzgICmyc2IkfsZetPNpxbANMjDyaMh8lPY3znc0RntEtuKF3 BWt498rX7VEIVJUyNh9OAngOp8Waw5hbBEu74lOrJC1DFC549h7pwAJUHoggYg83Yj23 E7MzqwJqOc7hbM3/ZBgZZ62VCnmV/JeUTIegkH3ytqzcZOh32ltXUVSdMOmOu+zUZU36 dmEg== X-Gm-Message-State: AODbwcDrsvIjZdlb+n9qXnl08RnVuPsNNosYGM0Vbci0ZFjudWiROwsN QsHTSrr8W5FT6agCjNv/jipLXqzfVA== X-Received: by 10.37.161.196 with SMTP id a62mr8297634ybi.9.1494697784090; Sat, 13 May 2017 10:49:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Sat, 13 May 2017 10:49:03 -0700 (PDT) In-Reply-To: <225E4246-AB30-4877-9DCF-D5D2A8ABDF18@ericsson.com> References: <149285978295.25905.7347383325486705546.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CB805F3@ESESSMB109.ericsson.se> <15D737F9-2F65-45C5-AA26-946910B4030F@sn3rd.com> <7594FB04B1934943A5C02806D1A2204B4CBA05BC@ESESSMB109.ericsson.se> <225E4246-AB30-4877-9DCF-D5D2A8ABDF18@ericsson.com> From: Eric Rescorla Date: Sat, 13 May 2017 10:49:03 -0700 Message-ID: To: Christer Holmberg Cc: Cullen Jennings , Sean Turner , The IESG , "rtcweb-chairs@ietf.org" , RTCWeb IETF , "draft-ietf-rtcweb-overview@ietf.org" Content-Type: multipart/alternative; boundary="f403045c563277d578054f6b7287" Archived-At: Subject: Re: [rtcweb] Eric Rescorla's Discuss on draft-ietf-rtcweb-overview-18: (with DISCUSS and COMMENT) 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, 13 May 2017 17:52:40 -0000 --f403045c563277d578054f6b7287 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, May 13, 2017 at 10:31 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > So, if the changes done in 5245bis aren't needed, why are we working on > 5245bis to begin with??? We did we spend all that time on modifying Ta > etc??? > I don't think anyone is saying that 5245 bis isn't a good thing, merely that one can implement JSEP and trickle without reading it. -Ekr > > Regards, > > Christer > > > Sent from my iPhone > > > On 13 May 2017, at 16.42, Cullen Jennings wrote: > > > > > > OK, so let me try to give some really clear guidance here ... if you ar= e > writing a draft that does not need to normatively depend on another draft= , > it should not normatively depended on that draft. > > > > I really doubt anyone is going to argue with that so lets make it so. > > > >> On May 13, 2017, at 1:54 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> > >> Hi, > >> > >> As co-chair of a number of the dependencies, we have been discussing > what to reference a number of times, and we have also changed the > references. We can't keep changing back and forth. > >> > >> In addition, I don't think WG X can decide what the drafts of WG Y > reference. There needs to be a collaborative decision. > >> > >> "We also assumed that some new work was going to require changes in IC= E > but as that work went progressed, we largely figured out ways to make it > work with existing ICE implementations." > >> > >> Is this "discovery" documented somewhere? > >> > >> "If trickle ice actually gets done before 5245bis, and it does not > depend on any 5245bis features, then clearly is should be changed to just > depend on 5245." > >> > >> First, we need to agree on whether trickle depends on 5245bis features > or not. > >> > >> Second, as co-author of 5245bis, I have asked the chairs to initiate > the road towards WGLC, so I would hope both 5245bis and trickle-ice could > be done more or less at the same time. > >> > >> Regards, > >> > >> Christer > >> > >> > >> -----Original Message----- > >> From: Cullen Jennings [mailto:fluffy@iii.ca] > >> Sent: 13 May 2017 01:55 > >> To: Eric Rescorla ; Christer Holmberg < > christer.holmberg@ericsson.com> > >> Cc: Sean Turner ; The IESG ; > rtcweb-chairs@ietf.org; RTCWeb IETF ; > draft-ietf-rtcweb-overview@ietf.org > >> Subject: Re: [rtcweb] Eric Rescorla's Discuss on > draft-ietf-rtcweb-overview-18: (with DISCUSS and COMMENT) > >> > >> > >> Let me try and answer with the caveat that I may get this wrong and > need to be corrected by my co-chairs... > >> > >> TL;DR - The chairs recommend changing the ref in overview to point at > 5245 instead of 5245-bis > >> > >> > >> here is the longer version.... > >> > >> First a side note on how we got here. Some of the reasons we set up > dependencies like they are is that many years ago we made guess about wh= at > order work would get completed on and, shockingly, some predictions of > standards developments timelines were less than perfect. We also assumed > that some new work was going to require changes in ICE but as that work > went progressed, we largely figured out ways to make it work with existin= g > ICE implementations. > >> > >> We are confident that overview does not actually depend on anything in > 5245-bis but instead just depends on 5245. > >> > >> Next lets discuss trickle-ice. The WebRTC set of specs currently > normatively depends on trickle ICE. There is some questions if trickle IC= E > might depend on 5245-bis. Some of the trickle ICE authors do not think i= t > does. One of the authors said the chairs asked them to ref 5245 instead o= f > 5245bis as both tickle ICE and 5245bis would be done around the same time= . > In general, the webrtc chairs would prefer to make the WebRTC dependency > cluster as small as possible. If trickle ice actually gets done before > 5245bis, and it does not depend on any 5245bis features, then clearly is > should be changed to just depend on 5245. The WG responsible for 5245bis > and trickle ICE can figure out what they want to do as both theses drafts > progress. Given there is a strong possibility that trickle ice will only > reference 5245, we think it would be better if overview did not bring > 5245bis into the WebRTC dependency cluster. If on the other hand, trickle > ICE does end up depending on 5245bis, there is no harm, and no need to > change overview to point at 5245. > >> > >> There are other drafts that are normative dependencies of JSEP and the > WebRTC cluster that also point at 5245bis. When we consider the technical > things these drafts need, it seems likely they can also reference 5245 > instead of 5245bis. For example draft-ietf-ice-dualstack-fairness, > draft-ietf-mmusic-ice-sip-sdp, draft-ietf-mmusic-sdp-bundle-negotiation, > and draft-ietf-rtcweb-transports (which is with the RFC Editor). The > argument for the others is roughly the same as it is with trickle ICE. > >> > >> Cullen (without review from my co-chairs but trying to represent what > we discussed on our chair call) > >> > >> > >> PS - if you are trying to figure out some of the dependencies for the > WebRTC cluster, you might find https://datatracker.ietf.org/ > doc/draft-jennings-rtcweb-deps/?include_text=3D1 useful but it is not 100= % > accurate. > >> > >> > >> > >>> On May 11, 2017, at 7:43 AM, Eric Rescorla wrote: > >>> > >>> Question for the chairs. > >>> > >>> On Thu, May 11, 2017 at 12:44 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >>> Hi, > >>> > >>> What is the status regarding this? > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>>> On 26/04/17 06:02, "Sean Turner" wrote: > >>>> > >>>> > >>>>> On Apr 23, 2017, at 14:44, Christer Holmberg > >>>>> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>>> ------------------------------------------------------------------ > >>>>>> ---- > >>>>>> DISCUSS: > >>>>>> ------------------------------------------------------------------ > >>>>>> ---- > >>>>>> > >>>>>> Your citation to ICE is to 5245-bis, but at least the JSEP editor > >>>>>> consensus was that WebRTC depended on 5245, so this needs to be > >>>>>> resolved one way or the other. > >>>>> > >>>>> Keep in mind that, no matter what draft-rtcweb-overview and > >>>>> draft-rtcweb-jsep explicitly say, both specs reference 5245bis > >>>>> *IMPLICITLY*, e.g., via draft-mmusic-bundle, draft-ice-trickle > >>>>> etc... As I have indicated in the past, it would cause confusion to > reference both. > >>>>> > >>>>> So, I think we shall reference 5245-bis everywhere (I also thought > >>>>> we already decided no that in the past)- > >>>>> > >>>>> Regards, > >>>>> > >>>>> Christer > >>>> > >>>> /* bike shed alert: > >>>> /* > >>>> /* Assuming you=C2=B9re of the mind that a bis/updates draft is > >>>> /* signaling to all implementors of the original RFC that the > >>>> /* intention is that all implementations be updated then it=C2=B9s > >>>> /* a bit more than implicit. > >>>> > >>>> spt > >>>> > >>> > >>> > >> > > > --f403045c563277d578054f6b7287 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, May 13, 2017 at 10:31 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:
Hi,

So, if the changes done in 5245bis aren't needed, why are we working on= 5245bis to begin with??? We did we spend all that time on modifying Ta etc= ???

I don't think anyone is saying = that 5245 bis isn't a good thing, merely that one can implement JSEP an= d trickle without reading it.

-Ekr
=C2= =A0

Regards,

Christer


Sent from my iPhone

> On 13 May 2017, at 16.42, Cullen Jennings <fluffy@iii.ca> wrote:
>
>
> OK, so let me try to give some really clear guidance here ... if you a= re writing a draft that does not need to normatively depend on another draf= t, it should not normatively depended on that draft.
>
> I really doubt anyone is going to argue with that so lets make it so.<= br> >
>> On May 13, 2017, at 1:54 AM, Christer Holmberg <christer.holmberg@ericsson.com&= gt; wrote:
>>
>> Hi,
>>
>> As co-chair of a number of the dependencies, we have been discussi= ng what to reference a number of times, and we have also changed the refere= nces. We can't keep changing back and forth.
>>
>> In addition, I don't think WG X can decide what the drafts of = WG Y reference. There needs to be a collaborative decision.
>>
>> "We also assumed that some new work was going to require chan= ges in ICE but as that work went progressed, we largely figured out ways to= make it work with existing ICE implementations."
>>
>> Is this "discovery" documented somewhere?
>>
>> "If trickle ice actually gets done before 5245bis, and it doe= s not depend on any 5245bis features, then clearly is should be changed to = just depend on 5245."
>>
>> First, we need to agree on whether trickle depends on 5245bis feat= ures or not.
>>
>> Second, as co-author of 5245bis, I have asked the chairs to initia= te the road towards WGLC, so I would hope both 5245bis and trickle-ice coul= d be done more or less at the same time.
>>
>> Regards,
>>
>> Christer
>>
>>
>> -----Original Message-----
>> From: Cullen Jennings [mailto:flu= ffy@iii.ca]
>> Sent: 13 May 2017 01:55
>> To: Eric Rescorla <ekr@rtfm.com= >; Christer Holmberg <christer.holmberg@ericsson.com>
>> Cc: Sean Turner <sean@sn3rd.c= om>; The IESG <iesg@ietf.org= >; rtcweb-chairs@ietf.org;= RTCWeb IETF <rtcweb@ietf.org>= ; draft-ietf-rtcweb-= overview@ietf.org
>> Subject: Re: [rtcweb] Eric Rescorla's Discuss on draft-ietf-rt= cweb-overview-18: (with DISCUSS and COMMENT)
>>
>>
>> Let me try and answer with the caveat that I may get this wrong an= d need to be corrected by my co-chairs...
>>
>> TL;DR - The chairs recommend changing the ref in overview to point= at 5245 instead of 5245-bis
>>
>>
>> here is the longer version....
>>
>> First a side note on how we got here. Some of the reasons we set u= p dependencies=C2=A0 like they are is that many years ago we made guess abo= ut what order work would get completed on and, shockingly, some predictions= of standards developments timelines were less than perfect. We also assume= d that some new work was going to require changes in ICE but as that work w= ent progressed, we largely figured out ways to make it work with existing I= CE implementations.
>>
>> We are confident that overview does not actually depend on anythin= g in 5245-bis but instead just depends on 5245.
>>
>> Next lets discuss trickle-ice. The WebRTC set of specs currently n= ormatively depends on trickle ICE. There is some questions if trickle ICE m= ight depend on 5245-bis. Some of the trickle ICE=C2=A0 authors do not think= it does. One of the authors said the chairs asked them to ref 5245 instead= of 5245bis as both tickle ICE and 5245bis would be done around the same ti= me. In general, the webrtc chairs would prefer to make the WebRTC dependenc= y cluster as small as possible. If trickle ice actually gets done before 52= 45bis, and it does not depend on any 5245bis features, then clearly is shou= ld be changed to just depend on 5245. The WG responsible for 5245bis and tr= ickle ICE can figure out what they want to do as both theses drafts progres= s. Given there is a strong possibility that trickle ice will only reference= 5245, we think it would be better if overview did not bring 5245bis into t= he WebRTC dependency cluster. If on the other hand, trickle ICE does end up= depending on 5245bis, there is no harm, and no need to change overview to = point at 5245.
>>
>> There are other drafts that are normative dependencies of JSEP and= the WebRTC cluster that also point at 5245bis. When we consider the techni= cal things these drafts need, it seems likely they can also reference 5245 = instead of 5245bis. For example draft-ietf-ice-dualstack-fairness, dra= ft-ietf-mmusic-ice-sip-sdp, draft-ietf-mmusic-sdp-bundle-negotiation, = and draft-ietf-rtcweb-transports (which is with the RFC Editor). The argume= nt for the others is roughly the same as it is with trickle ICE.
>>
>> Cullen (without review from my co-chairs but trying to represent w= hat we discussed on our chair call)
>>
>>
>> PS - if you are trying to figure out some of the dependencies for = the WebRTC cluster, you might find https://datatracker.ietf.org/doc/draft-jennings-rtcweb-deps/?include_text=3D1 useful but it is not 100% accurate.
>>
>>
>>
>>> On May 11, 2017, at 7:43 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>>>
>>> Question for the chairs.
>>>
>>> On Thu, May 11, 2017 at 12:44 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
>>> Hi,
>>>
>>> What is the status regarding this?
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>> On 26/04/17 06:02, "Sean Turner" <sean@sn3rd.com> wrote:
>>>>
>>>>
>>>>> On Apr 23, 2017, at 14:44, Christer Holmberg
>>>>> <= christer.holmberg@ericsson.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>> ---------------------------------------------= ---------------------
>>>>>> ----
>>>>>> DISCUSS:
>>>>>> ---------------------------------------------= ---------------------
>>>>>> ----
>>>>>>
>>>>>> Your citation to ICE is to 5245-bis, but at least = the JSEP editor
>>>>>> consensus was that WebRTC depended on 5245, so thi= s needs to be
>>>>>> resolved one way or the other.
>>>>>
>>>>> Keep in mind that, no matter what draft-rtcweb-overvie= w and
>>>>> draft-rtcweb-jsep explicitly say, both specs reference= 5245bis
>>>>> *IMPLICITLY*, e.g., via draft-mmusic-bundle, draft-ice= -trickle
>>>>> etc... As I have indicated in the past, it would cause= confusion to reference both.
>>>>>
>>>>> So, I think we shall reference 5245-bis everywhere (I = also thought
>>>>> we already decided no that in the past)-
>>>>>
>>>>> Regards,
>>>>>
>>>>> Christer
>>>>
>>>> /* bike shed alert:
>>>> /*
>>>> /* Assuming you=C2=B9re of the mind that a bis/updates dra= ft is
>>>> /* signaling to all implementors of the original RFC that = the
>>>> /* intention is that all implementations be updated then i= t=C2=B9s
>>>> /* a bit more than implicit.
>>>>
>>>> spt
>>>>
>>>
>>>
>>
>

--f403045c563277d578054f6b7287-- From nobody Sat May 13 10:59:43 2017 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 023A6129B28; Sat, 13 May 2017 10:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 xVhcl-EqkSmZ; Sat, 13 May 2017 10:59:39 -0700 (PDT) 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 D41BF129B9A; Sat, 13 May 2017 10:57:06 -0700 (PDT) X-AuditID: c1b4fb25-466159a000006049-c3-591748f06203 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 19.5C.24649.0F847195; Sat, 13 May 2017 19:57:05 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0339.000; Sat, 13 May 2017 19:57:04 +0200 From: Christer Holmberg To: Eric Rescorla CC: Cullen Jennings , Sean Turner , The IESG , "rtcweb-chairs@ietf.org" , "RTCWeb IETF" , "draft-ietf-rtcweb-overview@ietf.org" Thread-Topic: [rtcweb] Eric Rescorla's Discuss on draft-ietf-rtcweb-overview-18: (with DISCUSS and COMMENT) Thread-Index: AQHSu1nlcZL8BStkfUysDoOyMAqI5qHTV0EQgAODp4CAGBVbgIAAMMGAgAI9D4CAAKUNEIAAQg4AgABAHwCAAATigIAAIjZA Date: Sat, 13 May 2017 17:57:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CBA0B12@ESESSMB109.ericsson.se> References: <149285978295.25905.7347383325486705546.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CB805F3@ESESSMB109.ericsson.se> <15D737F9-2F65-45C5-AA26-946910B4030F@sn3rd.com> <7594FB04B1934943A5C02806D1A2204B4CBA05BC@ESESSMB109.ericsson.se> <225E4246-AB30-4877-9DCF-D5D2A8ABDF18@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7n+5HD/FIg337OSy2vD7BZrHi9Tl2 iw/rfzBazPgzkdmi5+0NFou1/9rZLa6samR2YPdYsuQnk8fl8x8ZPSY/bmP2OHiQMYAlissm JTUnsyy1SN8ugSuj8cJPloJFvhWLrgo0MC7x7mLk5JAQMJHYdmw7axcjF4eQwBFGiTMbN7NA OEsYJaZ2rgZyODjYBCwkuv9pgzSICChI/PpzAqyGWaCJSeLS3FdsIAlhgRyJ5YcPskAU5Urc 3DATys6TaFq1iBXEZhFQlTi5/TwjyExeAV+JHxuNIXbdY5F493kuM0gNp0CgxJ7ld8BsRgEx ie+n1jCB2MwC4hK3nsxngrhaQGLJnvPMELaoxMvH/1ghbCWJRbc/M4HMZxbQlFi/Sx+iVVFi SvdDdhCbV0BQ4uTMJywTGEVnIZk6C6FjFpKOWUg6FjCyrGIULU4tTspNNzLWSy3KTC4uzs/T y0st2cQIjLODW36r7mC8/MbxEKMAB6MSD++DBWKRQqyJZcWVuYcYJTiYlUR4D1iJRwrxpiRW VqUW5ccXleakFh9ilOZgURLnddx3IUJIID2xJDU7NbUgtQgmy8TBKdXAKHGlLFjrTUFVMb/A xH9HqmZvSCjO6JnaWdvmfMqvd8X/908yv4vsK/DkbBN8Zc11IclRq9fkTtrhyznnzLX+JbaK Zs/7Y8ZdtrHr0H/d4pomrgAdvtuv252ulGbN/e3F76uXMs21nuFZzoIMtWdtTovdPc/ZC558 Y3zaxUXjQE9qz2UL3kVKLMUZiYZazEXFiQAXpgQWrwIAAA== Archived-At: Subject: Re: [rtcweb] Eric Rescorla's Discuss on draft-ietf-rtcweb-overview-18: (with DISCUSS and COMMENT) 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, 13 May 2017 17:59:41 -0000 SGksDQoNCj4+U28sIGlmIHRoZSBjaGFuZ2VzIGRvbmUgaW4gNTI0NWJpcyBhcmVuJ3QgbmVlZGVk LCB3aHkgYXJlIHdlIHdvcmtpbmcgb24gNTI0NWJpcyB0byBiZWdpbiB3aXRoPz8/IFdlIGRpZCB3 ZSBzcGVuZCBhbGwgdGhhdCB0aW1lIG9uIG1vZGlmeWluZyBUYSBldGM/Pz8NCj4NCj5JIGRvbid0 IHRoaW5rIGFueW9uZSBpcyBzYXlpbmcgdGhhdCA1MjQ1IGJpcyBpc24ndCBhIGdvb2QgdGhpbmcs IG1lcmVseSB0aGF0IG9uZSBjYW4gaW1wbGVtZW50IEpTRVAgYW5kIHRyaWNrbGUgd2l0aG91dCBy ZWFkaW5nIGl0Lg0KDQpUaGlzIGlzbid0IGFib3V0IEpTRVAgYW5kIHRyaWNrbGUsIGl0J3MgYWJv dXQgcnRjd2ViLW92ZXJ2aWV3LSB3aGljaCBpcyBzdXBwb3NlZCB0byBnaXZlIHNvbWUgb3ZlcnZp ZXcgb2Ygd2hhdCBwZW9wbGUgbmVlZCB0byBpbXBsZW1lbnQuIA0KDQpTbywgKklGKiB3ZSBkZWNp ZGUgdG8gcmVmZXJlbmNlIFJGQyA1MjQ1IGluIHJ0Y3dlYi1vdmVydmlldywgSSB0aGluayB0aGF0 IHdlIGF0IGxlYXN0IHNob3VsZCBpbmRpY2F0ZSB0aGF0IHNvbWUgZGVwZW5kZW5jaWVzIG1pZ2h0 IHJlcXVpcmUgNTI0NWJpcywgYW5kIHJlZmVyIHRvIGluZGl2aWR1YWwgZGVwZW5kZW5jaWVzIGZv ciBkZXRhaWxzLiBUaGF0IHdheSB3ZSBjYW4gcHJvZ3Jlc3MgcnRjd2ViLW92ZXJ2aWV3LCBidXQg c3RpbGwga2VlcCB0aGUgZG9vciBvcGVuIGZvciA1MjQ1YmlzIHdoZXJlL2lmIGl0J3MgbmVlZGVk Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQrCoA0KDQoNClNlbnQgZnJvbSBteSBpUGhvbmUN Cg0KPiBPbiAxMyBNYXkgMjAxNywgYXQgMTYuNDIsIEN1bGxlbiBKZW5uaW5ncyA8Zmx1ZmZ5QGlp aS5jYT4gd3JvdGU6DQo+DQo+DQo+IE9LLCBzbyBsZXQgbWUgdHJ5IHRvIGdpdmUgc29tZSByZWFs bHkgY2xlYXIgZ3VpZGFuY2UgaGVyZSAuLi4gaWYgeW91IGFyZSB3cml0aW5nIGEgZHJhZnQgdGhh dCBkb2VzIG5vdCBuZWVkIHRvIG5vcm1hdGl2ZWx5IGRlcGVuZCBvbiBhbm90aGVyIGRyYWZ0LCBp dCBzaG91bGQgbm90IG5vcm1hdGl2ZWx5IGRlcGVuZGVkIG9uIHRoYXQgZHJhZnQuDQo+DQo+IEkg cmVhbGx5IGRvdWJ0IGFueW9uZSBpcyBnb2luZyB0byBhcmd1ZSB3aXRoIHRoYXQgc28gbGV0cyBt YWtlIGl0IHNvLg0KPg0KPj4gT24gTWF5IDEzLCAyMDE3LCBhdCAxOjU0IEFNLCBDaHJpc3RlciBI b2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+DQo+PiBI aSwNCj4+DQo+PiBBcyBjby1jaGFpciBvZiBhIG51bWJlciBvZiB0aGUgZGVwZW5kZW5jaWVzLCB3 ZSBoYXZlIGJlZW4gZGlzY3Vzc2luZyB3aGF0IHRvIHJlZmVyZW5jZSBhIG51bWJlciBvZiB0aW1l cywgYW5kIHdlIGhhdmUgYWxzbyBjaGFuZ2VkIHRoZSByZWZlcmVuY2VzLiBXZSBjYW4ndCBrZWVw IGNoYW5naW5nIGJhY2sgYW5kIGZvcnRoLg0KPj4NCj4+IEluIGFkZGl0aW9uLCBJIGRvbid0IHRo aW5rIFdHIFggY2FuIGRlY2lkZSB3aGF0IHRoZSBkcmFmdHMgb2YgV0cgWSByZWZlcmVuY2UuIFRo ZXJlIG5lZWRzIHRvIGJlIGEgY29sbGFib3JhdGl2ZSBkZWNpc2lvbi4NCj4+DQo+PiAiV2UgYWxz byBhc3N1bWVkIHRoYXQgc29tZSBuZXcgd29yayB3YXMgZ29pbmcgdG8gcmVxdWlyZSBjaGFuZ2Vz IGluIElDRSBidXQgYXMgdGhhdCB3b3JrIHdlbnQgcHJvZ3Jlc3NlZCwgd2UgbGFyZ2VseSBmaWd1 cmVkIG91dCB3YXlzIHRvIG1ha2UgaXQgd29yayB3aXRoIGV4aXN0aW5nIElDRSBpbXBsZW1lbnRh dGlvbnMuIg0KPj4NCj4+IElzIHRoaXMgImRpc2NvdmVyeSIgZG9jdW1lbnRlZCBzb21ld2hlcmU/ DQo+Pg0KPj4gIklmIHRyaWNrbGUgaWNlIGFjdHVhbGx5IGdldHMgZG9uZSBiZWZvcmUgNTI0NWJp cywgYW5kIGl0IGRvZXMgbm90IGRlcGVuZCBvbiBhbnkgNTI0NWJpcyBmZWF0dXJlcywgdGhlbiBj bGVhcmx5IGlzIHNob3VsZCBiZSBjaGFuZ2VkIHRvIGp1c3QgZGVwZW5kIG9uIDUyNDUuIg0KPj4N Cj4+IEZpcnN0LCB3ZSBuZWVkIHRvIGFncmVlIG9uIHdoZXRoZXIgdHJpY2tsZSBkZXBlbmRzIG9u IDUyNDViaXMgZmVhdHVyZXMgb3Igbm90Lg0KPj4NCj4+IFNlY29uZCwgYXMgY28tYXV0aG9yIG9m IDUyNDViaXMsIEkgaGF2ZSBhc2tlZCB0aGUgY2hhaXJzIHRvIGluaXRpYXRlIHRoZSByb2FkIHRv d2FyZHMgV0dMQywgc28gSSB3b3VsZCBob3BlIGJvdGggNTI0NWJpcyBhbmQgdHJpY2tsZS1pY2Ug Y291bGQgYmUgZG9uZSBtb3JlIG9yIGxlc3MgYXQgdGhlIHNhbWUgdGltZS4NCj4+DQo+PiBSZWdh cmRzLA0KPj4NCj4+IENocmlzdGVyDQo+Pg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+PiBGcm9tOiBDdWxsZW4gSmVubmluZ3MgW21haWx0bzpmbHVmZnlAaWlpLmNhXQ0KPj4g U2VudDogMTMgTWF5IDIwMTcgMDE6NTUNCj4+IFRvOiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5j b20+OyBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0K Pj4gQ2M6IFNlYW4gVHVybmVyIDxzZWFuQHNuM3JkLmNvbT47IFRoZSBJRVNHIDxpZXNnQGlldGYu b3JnPjsgcnRjd2ViLWNoYWlyc0BpZXRmLm9yZzsgUlRDV2ViIElFVEYgPHJ0Y3dlYkBpZXRmLm9y Zz47IGRyYWZ0LWlldGYtcnRjd2ViLW92ZXJ2aWV3QGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTog W3J0Y3dlYl0gRXJpYyBSZXNjb3JsYSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1ydGN3ZWItb3Zl cnZpZXctMTg6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+Pg0KPj4NCj4+IExldCBtZSB0 cnkgYW5kIGFuc3dlciB3aXRoIHRoZSBjYXZlYXQgdGhhdCBJIG1heSBnZXQgdGhpcyB3cm9uZyBh bmQgbmVlZCB0byBiZSBjb3JyZWN0ZWQgYnkgbXkgY28tY2hhaXJzLi4uDQo+Pg0KPj4gVEw7RFIg LSBUaGUgY2hhaXJzIHJlY29tbWVuZCBjaGFuZ2luZyB0aGUgcmVmIGluIG92ZXJ2aWV3IHRvIHBv aW50IGF0IDUyNDUgaW5zdGVhZCBvZiA1MjQ1LWJpcw0KPj4NCj4+DQo+PiBoZXJlIGlzIHRoZSBs b25nZXIgdmVyc2lvbi4uLi4NCj4+DQo+PiBGaXJzdCBhIHNpZGUgbm90ZSBvbiBob3cgd2UgZ290 IGhlcmUuIFNvbWUgb2YgdGhlIHJlYXNvbnMgd2Ugc2V0IHVwIGRlcGVuZGVuY2llc8KgIGxpa2Ug dGhleSBhcmUgaXMgdGhhdCBtYW55IHllYXJzIGFnbyB3ZSBtYWRlIGd1ZXNzIGFib3V0IHdoYXQg b3JkZXIgd29yayB3b3VsZCBnZXQgY29tcGxldGVkIG9uIGFuZCwgc2hvY2tpbmdseSwgc29tZSBw cmVkaWN0aW9ucyBvZiBzdGFuZGFyZHMgZGV2ZWxvcG1lbnRzIHRpbWVsaW5lcyB3ZXJlIGxlc3Mg dGhhbiBwZXJmZWN0LiBXZSBhbHNvIGFzc3VtZWQgdGhhdCBzb21lIG5ldyB3b3JrIHdhcyBnb2lu ZyB0byByZXF1aXJlIGNoYW5nZXMgaW4gSUNFIGJ1dCBhcyB0aGF0IHdvcmsgd2VudCBwcm9ncmVz c2VkLCB3ZSBsYXJnZWx5IGZpZ3VyZWQgb3V0IHdheXMgdG8gbWFrZSBpdCB3b3JrIHdpdGggZXhp c3RpbmcgSUNFIGltcGxlbWVudGF0aW9ucy4NCj4+DQo+PiBXZSBhcmUgY29uZmlkZW50IHRoYXQg b3ZlcnZpZXcgZG9lcyBub3QgYWN0dWFsbHkgZGVwZW5kIG9uIGFueXRoaW5nIGluIDUyNDUtYmlz IGJ1dCBpbnN0ZWFkIGp1c3QgZGVwZW5kcyBvbiA1MjQ1Lg0KPj4NCj4+IE5leHQgbGV0cyBkaXNj dXNzIHRyaWNrbGUtaWNlLiBUaGUgV2ViUlRDIHNldCBvZiBzcGVjcyBjdXJyZW50bHkgbm9ybWF0 aXZlbHkgZGVwZW5kcyBvbiB0cmlja2xlIElDRS4gVGhlcmUgaXMgc29tZSBxdWVzdGlvbnMgaWYg dHJpY2tsZSBJQ0UgbWlnaHQgZGVwZW5kIG9uIDUyNDUtYmlzLiBTb21lIG9mIHRoZSB0cmlja2xl IElDRcKgIGF1dGhvcnMgZG8gbm90IHRoaW5rIGl0IGRvZXMuIE9uZSBvZiB0aGUgYXV0aG9ycyBz YWlkIHRoZSBjaGFpcnMgYXNrZWQgdGhlbSB0byByZWYgNTI0NSBpbnN0ZWFkIG9mIDUyNDViaXMg YXMgYm90aCB0aWNrbGUgSUNFIGFuZCA1MjQ1YmlzIHdvdWxkIGJlIGRvbmUgYXJvdW5kIHRoZSBz YW1lIHRpbWUuIEluIGdlbmVyYWwsIHRoZSB3ZWJydGMgY2hhaXJzIHdvdWxkIHByZWZlciB0byBt YWtlIHRoZSBXZWJSVEMgZGVwZW5kZW5jeSBjbHVzdGVyIGFzIHNtYWxsIGFzIHBvc3NpYmxlLiBJ ZiB0cmlja2xlIGljZSBhY3R1YWxseSBnZXRzIGRvbmUgYmVmb3JlIDUyNDViaXMsIGFuZCBpdCBk b2VzIG5vdCBkZXBlbmQgb24gYW55IDUyNDViaXMgZmVhdHVyZXMsIHRoZW4gY2xlYXJseSBpcyBz aG91bGQgYmUgY2hhbmdlZCB0byBqdXN0IGRlcGVuZCBvbiA1MjQ1LiBUaGUgV0cgcmVzcG9uc2li bGUgZm9yIDUyNDViaXMgYW5kIHRyaWNrbGUgSUNFIGNhbiBmaWd1cmUgb3V0IHdoYXQgdGhleSB3 YW50IHRvIGRvIGFzIGJvdGggdGhlc2VzIGRyYWZ0cyBwcm9ncmVzcy4gR2l2ZW4gdGhlcmUgaXMg YSBzdHJvbmcgcG9zc2liaWxpdHkgdGhhdCB0cmlja2xlIGljZSB3aWxsIG9ubHkgcmVmZXJlbmNl IDUyNDUsIHdlIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciBpZiBvdmVydmlldyBkaWQgbm90IGJy aW5nIDUyNDViaXMgaW50byB0aGUgV2ViUlRDIGRlcGVuZGVuY3kgY2x1c3Rlci4gSWYgb24gdGhl IG90aGVyIGhhbmQsIHRyaWNrbGUgSUNFIGRvZXMgZW5kIHVwIGRlcGVuZGluZyBvbiA1MjQ1Ymlz LCB0aGVyZSBpcyBubyBoYXJtLCBhbmQgbm8gbmVlZCB0byBjaGFuZ2Ugb3ZlcnZpZXcgdG8gcG9p bnQgYXQgNTI0NS4NCj4+DQo+PiBUaGVyZSBhcmUgb3RoZXIgZHJhZnRzIHRoYXQgYXJlIG5vcm1h dGl2ZSBkZXBlbmRlbmNpZXMgb2YgSlNFUCBhbmQgdGhlIFdlYlJUQyBjbHVzdGVyIHRoYXQgYWxz byBwb2ludCBhdCA1MjQ1YmlzLiBXaGVuIHdlIGNvbnNpZGVyIHRoZSB0ZWNobmljYWwgdGhpbmdz IHRoZXNlIGRyYWZ0cyBuZWVkLCBpdCBzZWVtcyBsaWtlbHkgdGhleSBjYW4gYWxzbyByZWZlcmVu Y2UgNTI0NSBpbnN0ZWFkIG9mIDUyNDViaXMuIEZvciBleGFtcGxlIGRyYWZ0LWlldGYtaWNlLWR1 YWxzdGFjay1mYWlybmVzcywgZHJhZnQtaWV0Zi1tbXVzaWMtaWNlLXNpcC1zZHAsIGRyYWZ0LWll dGYtbW11c2ljLXNkcC1idW5kbGUtbmVnb3RpYXRpb24sIGFuZCBkcmFmdC1pZXRmLXJ0Y3dlYi10 cmFuc3BvcnRzICh3aGljaCBpcyB3aXRoIHRoZSBSRkMgRWRpdG9yKS4gVGhlIGFyZ3VtZW50IGZv ciB0aGUgb3RoZXJzIGlzIHJvdWdobHkgdGhlIHNhbWUgYXMgaXQgaXMgd2l0aCB0cmlja2xlIElD RS4NCj4+DQo+PiBDdWxsZW4gKHdpdGhvdXQgcmV2aWV3IGZyb20gbXkgY28tY2hhaXJzIGJ1dCB0 cnlpbmcgdG8gcmVwcmVzZW50IHdoYXQgd2UgZGlzY3Vzc2VkIG9uIG91ciBjaGFpciBjYWxsKQ0K Pj4NCj4+DQo+PiBQUyAtIGlmIHlvdSBhcmUgdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgc29tZSBvZiB0 aGUgZGVwZW5kZW5jaWVzIGZvciB0aGUgV2ViUlRDIGNsdXN0ZXIsIHlvdSBtaWdodCBmaW5kIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWplbm5pbmdzLXJ0Y3dlYi1kZXBz Lz9pbmNsdWRlX3RleHQ9MSB1c2VmdWwgYnV0IGl0IGlzIG5vdCAxMDAlIGFjY3VyYXRlLg0KPj4N Cj4+DQo+Pg0KPj4+IE9uIE1heSAxMSwgMjAxNywgYXQgNzo0MyBBTSwgRXJpYyBSZXNjb3JsYSA8 ZWtyQHJ0Zm0uY29tPiB3cm90ZToNCj4+Pg0KPj4+IFF1ZXN0aW9uIGZvciB0aGUgY2hhaXJzLg0K Pj4+DQo+Pj4gT24gVGh1LCBNYXkgMTEsIDIwMTcgYXQgMTI6NDQgQU0sIENocmlzdGVyIEhvbG1i ZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPj4+IEhpLA0KPj4+ DQo+Pj4gV2hhdCBpcyB0aGUgc3RhdHVzIHJlZ2FyZGluZyB0aGlzPw0KPj4+DQo+Pj4gUmVnYXJk cywNCj4+Pg0KPj4+IENocmlzdGVyDQo+Pj4NCj4+Pj4gT24gMjYvMDQvMTcgMDY6MDIsICJTZWFu IFR1cm5lciIgPHNlYW5Ac24zcmQuY29tPiB3cm90ZToNCj4+Pj4NCj4+Pj4NCj4+Pj4+IE9uIEFw ciAyMywgMjAxNywgYXQgMTQ6NDQsIENocmlzdGVyIEhvbG1iZXJnDQo+Pj4+PiA8Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+Pj4+DQo+Pj4+PiBIaSwNCj4+Pj4+DQo+ Pj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4gLS0tLQ0KPj4+Pj4+IERJU0NVU1M6DQo+Pj4+Pj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+Pj4+Pj4gLS0tLQ0KPj4+Pj4+DQo+Pj4+Pj4gWW91ciBjaXRhdGlvbiB0byBJQ0Ug aXMgdG8gNTI0NS1iaXMsIGJ1dCBhdCBsZWFzdCB0aGUgSlNFUCBlZGl0b3INCj4+Pj4+PiBjb25z ZW5zdXMgd2FzIHRoYXQgV2ViUlRDIGRlcGVuZGVkIG9uIDUyNDUsIHNvIHRoaXMgbmVlZHMgdG8g YmUNCj4+Pj4+PiByZXNvbHZlZCBvbmUgd2F5IG9yIHRoZSBvdGhlci4NCj4+Pj4+DQo+Pj4+PiBL ZWVwIGluIG1pbmQgdGhhdCwgbm8gbWF0dGVyIHdoYXQgZHJhZnQtcnRjd2ViLW92ZXJ2aWV3IGFu ZA0KPj4+Pj4gZHJhZnQtcnRjd2ViLWpzZXAgZXhwbGljaXRseSBzYXksIGJvdGggc3BlY3MgcmVm ZXJlbmNlIDUyNDViaXMNCj4+Pj4+ICpJTVBMSUNJVExZKiwgZS5nLiwgdmlhIGRyYWZ0LW1tdXNp Yy1idW5kbGUsIGRyYWZ0LWljZS10cmlja2xlDQo+Pj4+PiBldGMuLi4gQXMgSSBoYXZlIGluZGlj YXRlZCBpbiB0aGUgcGFzdCwgaXQgd291bGQgY2F1c2UgY29uZnVzaW9uIHRvIHJlZmVyZW5jZSBi b3RoLg0KPj4+Pj4NCj4+Pj4+IFNvLCBJIHRoaW5rIHdlIHNoYWxsIHJlZmVyZW5jZSA1MjQ1LWJp cyBldmVyeXdoZXJlIChJIGFsc28gdGhvdWdodA0KPj4+Pj4gd2UgYWxyZWFkeSBkZWNpZGVkIG5v IHRoYXQgaW4gdGhlIHBhc3QpLQ0KPj4+Pj4NCj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pg0KPj4+Pj4g Q2hyaXN0ZXINCj4+Pj4NCj4+Pj4gLyogYmlrZSBzaGVkIGFsZXJ0Og0KPj4+PiAvKg0KPj4+PiAv KiBBc3N1bWluZyB5b3XCuXJlIG9mIHRoZSBtaW5kIHRoYXQgYSBiaXMvdXBkYXRlcyBkcmFmdCBp cw0KPj4+PiAvKiBzaWduYWxpbmcgdG8gYWxsIGltcGxlbWVudG9ycyBvZiB0aGUgb3JpZ2luYWwg UkZDIHRoYXQgdGhlDQo+Pj4+IC8qIGludGVudGlvbiBpcyB0aGF0IGFsbCBpbXBsZW1lbnRhdGlv bnMgYmUgdXBkYXRlZCB0aGVuIGl0wrlzDQo+Pj4+IC8qIGEgYml0IG1vcmUgdGhhbiBpbXBsaWNp dC4NCj4+Pj4NCj4+Pj4gc3B0DQo+Pj4+DQo+Pj4NCj4+Pg0KPj4NCj4NCg0K From nobody Sat May 13 11:04:03 2017 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 AFB7512EA56 for ; Sat, 13 May 2017 11:04:02 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 XEBxqt9OF1K6 for ; Sat, 13 May 2017 11:03:59 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002: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 ECA2012EA74 for ; Sat, 13 May 2017 11:01:09 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id l14so23111268ywk.1 for ; Sat, 13 May 2017 11:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dyqUMBp+CmAxTuKFG98Wgpx4KTGFR7xeuqT4sLMDC+Q=; b=vKZKYKkw0yzjqeD7kXLtJ48RgafNf3GmSh7k7bHhxk53jE+JX3WVBw5uHMwVGPwIAK NvWhUOTfPztr8KaFc3fODsYEx46xJBn9sVcwNBefytPasxwEMbb0dMilUWCXkA8wRa1z ps5EnmigWcUkEHLrT0U/CcItxYzaBFbVzkeJA2wEcAI+T5ij4SxqHWuMLAc12qyTMqWV te0tqmf+AR+qH4ciT96OvLyThOQDMHDFoq4xUdoh3rFIWPIEKVHyFllGqVweR6jX1P2w QT7WPW9CILqXGGNCcZvneFsthHMVM2trZPIwRZb7EYyv+HiUcUfYoNadqecQFBAWZk6b Hlzg== 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=dyqUMBp+CmAxTuKFG98Wgpx4KTGFR7xeuqT4sLMDC+Q=; b=fWKsbmLNecRxOgKPr33lmyXvbgzu+I84bJW69ngH0Wveg3pTY7WHDl883klfc55LL6 8zWXv/I/GC5GuEUxT2iqw0bR4XQYC2vg5BqrPSYPqAp4iq7JfKvVEEAR+9UG5jsDeZNY A4ipXRkx784geWCk/AAgkKmH1brHRmUrYcSCJl5MWOmHuKRJIZ2lGOROJFrZYnzQTb9j gPJ5hEHS2mVRPT8mBDv1M+V6PghxSHyTDrzeNNNUvG8ZDzpLu5maVpuZ7PD8y8OU2uWE 6/Yn2zCBeOcGce9F/63Ke29p9iVPGh+1qslU72K00UYPtKlxkrjGe3p+TpaAUhrluqKY oAxw== X-Gm-Message-State: AODbwcDX/7HGUao027YyrGoolRL7N9awW0R3IqfIgqk17MarvhwnchI1 de92eJdfnSEyLzLhid5FtQ87nlZMcg== X-Received: by 10.129.147.134 with SMTP id k128mr3713530ywg.270.1494698469212; Sat, 13 May 2017 11:01:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Sat, 13 May 2017 11:00:28 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CBA0B12@ESESSMB109.ericsson.se> References: <149285978295.25905.7347383325486705546.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CB805F3@ESESSMB109.ericsson.se> <15D737F9-2F65-45C5-AA26-946910B4030F@sn3rd.com> <7594FB04B1934943A5C02806D1A2204B4CBA05BC@ESESSMB109.ericsson.se> <225E4246-AB30-4877-9DCF-D5D2A8ABDF18@ericsson.com> <7594FB04B1934943A5C02806D1A2204B4CBA0B12@ESESSMB109.ericsson.se> From: Eric Rescorla Date: Sat, 13 May 2017 11:00:28 -0700 Message-ID: To: Christer Holmberg Cc: Cullen Jennings , Sean Turner , The IESG , "rtcweb-chairs@ietf.org" , RTCWeb IETF , "draft-ietf-rtcweb-overview@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c08d3564dd71f054f6b9b97" Archived-At: Subject: Re: [rtcweb] Eric Rescorla's Discuss on draft-ietf-rtcweb-overview-18: (with DISCUSS and COMMENT) 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, 13 May 2017 18:04:03 -0000 --94eb2c08d3564dd71f054f6b9b97 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, May 13, 2017 at 10:57 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >>So, if the changes done in 5245bis aren't needed, why are we working on > 5245bis to begin with??? We did we spend all that time on modifying Ta > etc??? > > > >I don't think anyone is saying that 5245 bis isn't a good thing, merely > that one can implement JSEP and trickle without reading it. > > This isn't about JSEP and trickle, it's about rtcweb-overview- which is > supposed to give some overview of what people need to implement. > Yes, and rtcweb-overview references 5245-bis: 1. Directly 2. Transitively through other documents, which are primarily JSEP and trickle. And my point is that to implement those other documents, you need not implement 5245-bis. So, *IF* we decide to reference RFC 5245 in rtcweb-overview, I think that > we at least should indicate that some dependencies might require 5245bis, > and refer to individual dependencies for details. That way we can progres= s > rtcweb-overview, but still keep the door open for 5245bis where/if it's > needed. > That just seems like kicking the can down the road. To the best of my knowledge, there is no technical reason why an rtcweb implementation needs to know about 5245-bis (whatever the structure of the normative references in the documents happens to be). Are you aware of such a reason? -Ekr > Regards, > > Christer > > > > > Sent from my iPhone > > > On 13 May 2017, at 16.42, Cullen Jennings wrote: > > > > > > OK, so let me try to give some really clear guidance here ... if you ar= e > writing a draft that does not need to normatively depend on another draft= , > it should not normatively depended on that draft. > > > > I really doubt anyone is going to argue with that so lets make it so. > > > >> On May 13, 2017, at 1:54 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> > >> Hi, > >> > >> As co-chair of a number of the dependencies, we have been discussing > what to reference a number of times, and we have also changed the > references. We can't keep changing back and forth. > >> > >> In addition, I don't think WG X can decide what the drafts of WG Y > reference. There needs to be a collaborative decision. > >> > >> "We also assumed that some new work was going to require changes in IC= E > but as that work went progressed, we largely figured out ways to make it > work with existing ICE implementations." > >> > >> Is this "discovery" documented somewhere? > >> > >> "If trickle ice actually gets done before 5245bis, and it does not > depend on any 5245bis features, then clearly is should be changed to just > depend on 5245." > >> > >> First, we need to agree on whether trickle depends on 5245bis features > or not. > >> > >> Second, as co-author of 5245bis, I have asked the chairs to initiate > the road towards WGLC, so I would hope both 5245bis and trickle-ice could > be done more or less at the same time. > >> > >> Regards, > >> > >> Christer > >> > >> > >> -----Original Message----- > >> From: Cullen Jennings [mailto:fluffy@iii.ca] > >> Sent: 13 May 2017 01:55 > >> To: Eric Rescorla ; Christer Holmberg < > christer.holmberg@ericsson.com> > >> Cc: Sean Turner ; The IESG ; > rtcweb-chairs@ietf.org; RTCWeb IETF ; > draft-ietf-rtcweb-overview@ietf.org > >> Subject: Re: [rtcweb] Eric Rescorla's Discuss on > draft-ietf-rtcweb-overview-18: (with DISCUSS and COMMENT) > >> > >> > >> Let me try and answer with the caveat that I may get this wrong and > need to be corrected by my co-chairs... > >> > >> TL;DR - The chairs recommend changing the ref in overview to point at > 5245 instead of 5245-bis > >> > >> > >> here is the longer version.... > >> > >> First a side note on how we got here. Some of the reasons we set up > dependencies like they are is that many years ago we made guess about wh= at > order work would get completed on and, shockingly, some predictions of > standards developments timelines were less than perfect. We also assumed > that some new work was going to require changes in ICE but as that work > went progressed, we largely figured out ways to make it work with existin= g > ICE implementations. > >> > >> We are confident that overview does not actually depend on anything in > 5245-bis but instead just depends on 5245. > >> > >> Next lets discuss trickle-ice. The WebRTC set of specs currently > normatively depends on trickle ICE. There is some questions if trickle IC= E > might depend on 5245-bis. Some of the trickle ICE authors do not think i= t > does. One of the authors said the chairs asked them to ref 5245 instead o= f > 5245bis as both tickle ICE and 5245bis would be done around the same time= . > In general, the webrtc chairs would prefer to make the WebRTC dependency > cluster as small as possible. If trickle ice actually gets done before > 5245bis, and it does not depend on any 5245bis features, then clearly is > should be changed to just depend on 5245. The WG responsible for 5245bis > and trickle ICE can figure out what they want to do as both theses drafts > progress. Given there is a strong possibility that trickle ice will only > reference 5245, we think it would be better if overview did not bring > 5245bis into the WebRTC dependency cluster. If on the other hand, trickle > ICE does end up depending on 5245bis, there is no harm, and no need to > change overview to point at 5245. > >> > >> There are other drafts that are normative dependencies of JSEP and the > WebRTC cluster that also point at 5245bis. When we consider the technical > things these drafts need, it seems likely they can also reference 5245 > instead of 5245bis. For example draft-ietf-ice-dualstack-fairness, > draft-ietf-mmusic-ice-sip-sdp, draft-ietf-mmusic-sdp-bundle-negotiation, > and draft-ietf-rtcweb-transports (which is with the RFC Editor). The > argument for the others is roughly the same as it is with trickle ICE. > >> > >> Cullen (without review from my co-chairs but trying to represent what > we discussed on our chair call) > >> > >> > >> PS - if you are trying to figure out some of the dependencies for the > WebRTC cluster, you might find https://datatracker.ietf.org/ > doc/draft-jennings-rtcweb-deps/?include_text=3D1 useful but it is not 100= % > accurate. > >> > >> > >> > >>> On May 11, 2017, at 7:43 AM, Eric Rescorla wrote: > >>> > >>> Question for the chairs. > >>> > >>> On Thu, May 11, 2017 at 12:44 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >>> Hi, > >>> > >>> What is the status regarding this? > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>>> On 26/04/17 06:02, "Sean Turner" wrote: > >>>> > >>>> > >>>>> On Apr 23, 2017, at 14:44, Christer Holmberg > >>>>> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>>> ------------------------------------------------------------------ > >>>>>> ---- > >>>>>> DISCUSS: > >>>>>> ------------------------------------------------------------------ > >>>>>> ---- > >>>>>> > >>>>>> Your citation to ICE is to 5245-bis, but at least the JSEP editor > >>>>>> consensus was that WebRTC depended on 5245, so this needs to be > >>>>>> resolved one way or the other. > >>>>> > >>>>> Keep in mind that, no matter what draft-rtcweb-overview and > >>>>> draft-rtcweb-jsep explicitly say, both specs reference 5245bis > >>>>> *IMPLICITLY*, e.g., via draft-mmusic-bundle, draft-ice-trickle > >>>>> etc... As I have indicated in the past, it would cause confusion to > reference both. > >>>>> > >>>>> So, I think we shall reference 5245-bis everywhere (I also thought > >>>>> we already decided no that in the past)- > >>>>> > >>>>> Regards, > >>>>> > >>>>> Christer > >>>> > >>>> /* bike shed alert: > >>>> /* > >>>> /* Assuming you=C2=B9re of the mind that a bis/updates draft is > >>>> /* signaling to all implementors of the original RFC that the > >>>> /* intention is that all implementations be updated then it=C2=B9s > >>>> /* a bit more than implicit. > >>>> > >>>> spt > >>>> > >>> > >>> > >> > > > > --94eb2c08d3564dd71f054f6b9b97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, May 13, 2017 at 10:57 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:
Hi,

>>So, if the changes done in 5245bis aren't needed, why are we wo= rking on 5245bis to begin with??? We did we spend all that time on modifyin= g Ta etc???
>
>I don't think anyone is saying that 5245 bis isn't a good thing= , merely that one can implement JSEP and trickle without reading it.

This isn't about JSEP and trickle, it's about rtcweb-overvie= w- which is supposed to give some overview of what people need to implement= .

Yes, and rtcweb-overview references 5= 245-bis:

1. Directly
2. Transitively thr= ough other documents, which are primarily JSEP and trickle.

<= /div>
And my point is that to implement those other documents, you need= not implement
5245-bis.


So, *IF* we decide to reference RFC 5245 in rtcweb-overview, I think that w= e at least should indicate that some dependencies might require 5245bis, an= d refer to individual dependencies for details. That way we can progress rt= cweb-overview, but still keep the door open for 5245bis where/if it's n= eeded.

That just seems like kicking the= can down the road. To the best of my knowledge,
there is no tech= nical reason why an rtcweb implementation needs to know about
524= 5-bis (whatever the structure of the normative references in the documents<= /div>
happens to be). Are you aware of such a reason?

-Ekr


Regards,

Christer

=C2=A0


Sent from my iPhone

> On 13 May 2017, at 16.42, Cullen Jennings <fluffy@iii.ca> wrote:
>
>
> OK, so let me try to give some really clear guidance here ... if you a= re writing a draft that does not need to normatively depend on another draf= t, it should not normatively depended on that draft.
>
> I really doubt anyone is going to argue with that so lets make it so.<= br> >
>> On May 13, 2017, at 1:54 AM, Christer Holmberg <christer.holmberg@ericsson.com&= gt; wrote:
>>
>> Hi,
>>
>> As co-chair of a number of the dependencies, we have been discussi= ng what to reference a number of times, and we have also changed the refere= nces. We can't keep changing back and forth.
>>
>> In addition, I don't think WG X can decide what the drafts of = WG Y reference. There needs to be a collaborative decision.
>>
>> "We also assumed that some new work was going to require chan= ges in ICE but as that work went progressed, we largely figured out ways to= make it work with existing ICE implementations."
>>
>> Is this "discovery" documented somewhere?
>>
>> "If trickle ice actually gets done before 5245bis, and it doe= s not depend on any 5245bis features, then clearly is should be changed to = just depend on 5245."
>>
>> First, we need to agree on whether trickle depends on 5245bis feat= ures or not.
>>
>> Second, as co-author of 5245bis, I have asked the chairs to initia= te the road towards WGLC, so I would hope both 5245bis and trickle-ice coul= d be done more or less at the same time.
>>
>> Regards,
>>
>> Christer
>>
>>
>> -----Original Message-----
>> From: Cullen Jennings [mailto:flu= ffy@iii.ca]
>> Sent: 13 May 2017 01:55
>> To: Eric Rescorla <ekr@rtfm.com= >; Christer Holmberg <christer.holmberg@ericsson.com>
>> Cc: Sean Turner <sean@sn3rd.c= om>; The IESG <iesg@ietf.org= >; rtcweb-chairs@ietf.org;= RTCWeb IETF <rtcweb@ietf.org>= ; draft-ietf-rtcweb-= overview@ietf.org
>> Subject: Re: [rtcweb] Eric Rescorla's Discuss on draft-ietf-rt= cweb-overview-18: (with DISCUSS and COMMENT)
>>
>>
>> Let me try and answer with the caveat that I may get this wrong an= d need to be corrected by my co-chairs...
>>
>> TL;DR - The chairs recommend changing the ref in overview to point= at 5245 instead of 5245-bis
>>
>>
>> here is the longer version....
>>
>> First a side note on how we got here. Some of the reasons we set u= p dependencies=C2=A0 like they are is that many years ago we made guess abo= ut what order work would get completed on and, shockingly, some predictions= of standards developments timelines were less than perfect. We also assume= d that some new work was going to require changes in ICE but as that work w= ent progressed, we largely figured out ways to make it work with existing I= CE implementations.
>>
>> We are confident that overview does not actually depend on anythin= g in 5245-bis but instead just depends on 5245.
>>
>> Next lets discuss trickle-ice. The WebRTC set of specs currently n= ormatively depends on trickle ICE. There is some questions if trickle ICE m= ight depend on 5245-bis. Some of the trickle ICE=C2=A0 authors do not think= it does. One of the authors said the chairs asked them to ref 5245 instead= of 5245bis as both tickle ICE and 5245bis would be done around the same ti= me. In general, the webrtc chairs would prefer to make the WebRTC dependenc= y cluster as small as possible. If trickle ice actually gets done before 52= 45bis, and it does not depend on any 5245bis features, then clearly is shou= ld be changed to just depend on 5245. The WG responsible for 5245bis and tr= ickle ICE can figure out what they want to do as both theses drafts progres= s. Given there is a strong possibility that trickle ice will only reference= 5245, we think it would be better if overview did not bring 5245bis into t= he WebRTC dependency cluster. If on the other hand, trickle ICE does end up= depending on 5245bis, there is no harm, and no need to change overview to = point at 5245.
>>
>> There are other drafts that are normative dependencies of JSEP and= the WebRTC cluster that also point at 5245bis. When we consider the techni= cal things these drafts need, it seems likely they can also reference 5245 = instead of 5245bis. For example draft-ietf-ice-dualstack-fairness, dra= ft-ietf-mmusic-ice-sip-sdp, draft-ietf-mmusic-sdp-bundle-negotiation, = and draft-ietf-rtcweb-transports (which is with the RFC Editor). The argume= nt for the others is roughly the same as it is with trickle ICE.
>>
>> Cullen (without review from my co-chairs but trying to represent w= hat we discussed on our chair call)
>>
>>
>> PS - if you are trying to figure out some of the dependencies for = the WebRTC cluster, you might find https://datatracker.ietf.org/doc/draft-jennings-rtcweb-deps/?include_text=3D1 useful but it is not 100% accurate.
>>
>>
>>
>>> On May 11, 2017, at 7:43 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>>>
>>> Question for the chairs.
>>>
>>> On Thu, May 11, 2017 at 12:44 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
>>> Hi,
>>>
>>> What is the status regarding this?
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>> On 26/04/17 06:02, "Sean Turner" <sean@sn3rd.com> wrote:
>>>>
>>>>
>>>>> On Apr 23, 2017, at 14:44, Christer Holmberg
>>>>> <= christer.holmberg@ericsson.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>> ---------------------------------------------= ---------------------
>>>>>> ----
>>>>>> DISCUSS:
>>>>>> ---------------------------------------------= ---------------------
>>>>>> ----
>>>>>>
>>>>>> Your citation to ICE is to 5245-bis, but at least = the JSEP editor
>>>>>> consensus was that WebRTC depended on 5245, so thi= s needs to be
>>>>>> resolved one way or the other.
>>>>>
>>>>> Keep in mind that, no matter what draft-rtcweb-overvie= w and
>>>>> draft-rtcweb-jsep explicitly say, both specs reference= 5245bis
>>>>> *IMPLICITLY*, e.g., via draft-mmusic-bundle, draft-ice= -trickle
>>>>> etc... As I have indicated in the past, it would cause= confusion to reference both.
>>>>>
>>>>> So, I think we shall reference 5245-bis everywhere (I = also thought
>>>>> we already decided no that in the past)-
>>>>>
>>>>> Regards,
>>>>>
>>>>> Christer
>>>>
>>>> /* bike shed alert:
>>>> /*
>>>> /* Assuming you=C2=B9re of the mind that a bis/updates dra= ft is
>>>> /* signaling to all implementors of the original RFC that = the
>>>> /* intention is that all implementations be updated then i= t=C2=B9s
>>>> /* a bit more than implicit.
>>>>
>>>> spt
>>>>
>>>
>>>
>>
>


--94eb2c08d3564dd71f054f6b9b97-- From nobody Sat May 13 11:17:28 2017 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 9B64212947B; Sat, 13 May 2017 11:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 DCaGSoeCB38h; Sat, 13 May 2017 11:17:19 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 A2CBB129A9D; Sat, 13 May 2017 11:14:17 -0700 (PDT) X-AuditID: c1b4fb3a-b7dff70000005025-6b-59174cf56f14 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id EC.CA.20517.5FC47195; Sat, 13 May 2017 20:14:15 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0339.000; Sat, 13 May 2017 20:14:12 +0200 From: Christer Holmberg To: Eric Rescorla CC: Cullen Jennings , Sean Turner , The IESG , "rtcweb-chairs@ietf.org" , "RTCWeb IETF" , "draft-ietf-rtcweb-overview@ietf.org" Thread-Topic: [rtcweb] Eric Rescorla's Discuss on draft-ietf-rtcweb-overview-18: (with DISCUSS and COMMENT) Thread-Index: AQHSu1nlcZL8BStkfUysDoOyMAqI5qHTV0EQgAODp4CAGBVbgIAAMMGAgAI9D4CAAKUNEIAAQg4AgABAHwCAAATigIAAIjZA///g+wCAACNr0A== Date: Sat, 13 May 2017 18:14:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CBA0BF0@ESESSMB109.ericsson.se> References: <149285978295.25905.7347383325486705546.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CB805F3@ESESSMB109.ericsson.se> <15D737F9-2F65-45C5-AA26-946910B4030F@sn3rd.com> <7594FB04B1934943A5C02806D1A2204B4CBA05BC@ESESSMB109.ericsson.se> <225E4246-AB30-4877-9DCF-D5D2A8ABDF18@ericsson.com> <7594FB04B1934943A5C02806D1A2204B4CBA0B12@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7qO53H/FIg19/TC22vD7BZrHi9Tl2 iw/rfzBazPgzkdmi5+0NFou1/9rZLa6samR2YPdYsuQnk8fl8x8ZPSY/bmP2OHiQMYAlissm JTUnsyy1SN8ugSvj8atPbAVnIiqeLVnD1sC4IqyLkZNDQsBEYtuPM0xdjFwcQgJHGCVefdrH DOEsYZQ49nwvkMPBwSZgIdH9TxukQURAQeLXnxMsIDXMAk1MEpfmvmIDSQgL5EgsP3yQBaIo V+LmhplQdp1E76cNYDaLgKrEvL5b7CAzeQV8JQ43yUPseskqsfr5T1aQGk6BQIn5x8+CzWQU EJP4fmoNE4jNLCAucevJfCaIqwUkluw5zwxhi0q8fPyPFcJWklh0+zMTyHxmAU2J9bv0IVoV JaZ0P2QHsXkFBCVOznzCMoFRdBaSqbMQOmYh6ZiFpGMBI8sqRtHi1OLi3HQjI73Uoszk4uL8 PL281JJNjMBIO7jlt9UOxoPPHQ8xCnAwKvHwPlggFinEmlhWXJl7iFGCg1lJhPeAlXikEG9K YmVValF+fFFpTmrxIUZpDhYlcV6HfRcihATSE0tSs1NTC1KLYLJMHJxSDYyrZhy/u+TsY2O+ Ujf55imHIuPcPAVm5HJsv+vsZWl7oK7wZ+LEyviLMw5PClifwPT76Iv/j5fvWMpptvG6UU92 yr2/HAtvpUYV8XgUdtm9+h8XJ1ZZcMd+FevHTdc2i7Yo/Vxwa5Mef37ve3VurkqTvy+yHLds vBpvm/SQ4+IPXf4HEgprLZmUWIozEg21mIuKEwGXipX9sAIAAA== Archived-At: Subject: Re: [rtcweb] Eric Rescorla's Discuss on draft-ietf-rtcweb-overview-18: (with DISCUSS and COMMENT) 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, 13 May 2017 18:17:22 -0000 SGksDQoNCj4+PlNvLCBpZiB0aGUgY2hhbmdlcyBkb25lIGluIDUyNDViaXMgYXJlbid0IG5lZWRl ZCwgd2h5IGFyZSB3ZSB3b3JraW5nIG9uIDUyNDViaXMgdG8gYmVnaW4gd2l0aD8/PyBXZSBkaWQg d2Ugc3BlbmQgYWxsIHRoYXQgdGltZSBvbiBtb2RpZnlpbmcgVGEgZXRjPz8/DQo+Pg0KPj5JIGRv bid0IHRoaW5rIGFueW9uZSBpcyBzYXlpbmcgdGhhdCA1MjQ1IGJpcyBpc24ndCBhIGdvb2QgdGhp bmcsIG1lcmVseSB0aGF0IG9uZSBjYW4gaW1wbGVtZW50IEpTRVAgYW5kIHRyaWNrbGUgd2l0aG91 dCByZWFkaW5nIGl0Lg0KPg0KPlRoaXMgaXNuJ3QgYWJvdXQgSlNFUCBhbmQgdHJpY2tsZSwgaXQn cyBhYm91dCBydGN3ZWItb3ZlcnZpZXctIHdoaWNoIGlzIHN1cHBvc2VkIHRvIGdpdmUgc29tZSBv dmVydmlldyBvZiB3aGF0IHBlb3BsZSBuZWVkIHRvIGltcGxlbWVudC4NCj4NCj5ZZXMsIGFuZCBy dGN3ZWItb3ZlcnZpZXcgcmVmZXJlbmNlcyA1MjQ1LWJpczoNCj4NCj4xLiBEaXJlY3RseQ0KPjIu IFRyYW5zaXRpdmVseSB0aHJvdWdoIG90aGVyIGRvY3VtZW50cywgd2hpY2ggYXJlIHByaW1hcmls eSBKU0VQIGFuZCB0cmlja2xlLg0KPg0KPkFuZCBteSBwb2ludCBpcyB0aGF0IHRvIGltcGxlbWVu dCB0aG9zZSBvdGhlciBkb2N1bWVudHMsIHlvdSBuZWVkIG5vdCBpbXBsZW1lbnQNCj41MjQ1LWJp cy4NCg0KQW5kIGV2ZXJ5b25lIGFncmVlIG9uIHRoYXQgKGVzcGVjaWFsbHkgcmVnYXJkaW5nIHRy aWNrbGUpPw0KDQo+PlNvLCAqSUYqIHdlIGRlY2lkZSB0byByZWZlcmVuY2UgUkZDIDUyNDUgaW4g cnRjd2ViLW92ZXJ2aWV3LCBJIHRoaW5rIHRoYXQgd2UgYXQgbGVhc3Qgc2hvdWxkDQo+PmluZGlj YXRlIHRoYXQgc29tZSBkZXBlbmRlbmNpZXMgbWlnaHQgcmVxdWlyZSA1MjQ1YmlzLCBhbmQgcmVm ZXIgdG8gaW5kaXZpZHVhbCBkZXBlbmRlbmNpZXMgDQo+PmZvciBkZXRhaWxzLiBUaGF0IHdheSB3 ZSBjYW4gcHJvZ3Jlc3MgcnRjd2ViLW92ZXJ2aWV3LCBidXQgc3RpbGwga2VlcCB0aGUgZG9vciBv cGVuIGZvciA1MjQ1YmlzIA0KPj53aGVyZS9pZiBpdCdzIG5lZWRlZC4NCj4NCj5UaGF0IGp1c3Qg c2VlbXMgbGlrZSBraWNraW5nIHRoZSBjYW4gZG93biB0aGUgcm9hZC4gVG8gdGhlIGJlc3Qgb2Yg bXkga25vd2xlZGdlLA0KPnRoZXJlIGlzIG5vIHRlY2huaWNhbCByZWFzb24gd2h5IGFuIHJ0Y3dl YiBpbXBsZW1lbnRhdGlvbiBuZWVkcyB0byBrbm93IGFib3V0DQo+NTI0NS1iaXMgKHdoYXRldmVy IHRoZSBzdHJ1Y3R1cmUgb2YgdGhlIG5vcm1hdGl2ZSByZWZlcmVuY2VzIGluIHRoZSBkb2N1bWVu dHMNCj5oYXBwZW5zIHRvIGJlKS4gQXJlIHlvdSBhd2FyZSBvZiBzdWNoIGEgcmVhc29uPw0KDQpV bmxlc3MgdHJpY2tsZSByZXF1aXJlcyA1MjQ1YmlzLCB0aGVuIG5vLg0KDQpJIGFtLCBob3dldmVy LCBhd2FyZSB0aGF0IGEgbnVtYmVyIG9mIGRlcGVuZGVuY2llcyBkbyByZWZlciA1MjQ1YmlzLiBN YXliZSB0aGV5IGRvbid0IG5lZWQgdG8sIGJ1dCBteSBwb2ludCBpcyB0aGF0IEkgdGhpbmsgYWxs IGRlcGVuZGVuY2llcyBzaG91bGQgcmVmZXJlbmNlIHRoZSBzYW1lIElDRSBzcGVjIC0gUkZDIDUy NDUgKk9SKiA1MjQ1YmlzLiBBbmQgSSB0aGluayBSVENXRUIsIE1NVVNJQyBhbmQgSUNFIHNob3Vs ZCBhZ3JlZSBvbiB3aGljaCBzcGVjLiBTaW5jZSBtb3JlIG9yIGxlc3MgdGhlIHNhbWUgcGVvcGxl IHBhcnRpY2lwYXRlIGluIGFsbCB0aG9zZSBncm91cHMsIEkgZG9uJ3QgdGhpbmsgaXQgc2hvdWxk IGJlIGEgZGlmZmljdWx0IHRoaW5nIHRvIGFjaGlldmUuIA0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl cg0KDQrCoA0KDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KPiBPbiAxMyBNYXkgMjAxNywgYXQg MTYuNDIsIEN1bGxlbiBKZW5uaW5ncyA8Zmx1ZmZ5QGlpaS5jYT4gd3JvdGU6DQo+DQo+DQo+IE9L LCBzbyBsZXQgbWUgdHJ5IHRvIGdpdmUgc29tZSByZWFsbHkgY2xlYXIgZ3VpZGFuY2UgaGVyZSAu Li4gaWYgeW91IGFyZSB3cml0aW5nIGEgZHJhZnQgdGhhdCBkb2VzIG5vdCBuZWVkIHRvIG5vcm1h dGl2ZWx5IGRlcGVuZCBvbiBhbm90aGVyIGRyYWZ0LCBpdCBzaG91bGQgbm90IG5vcm1hdGl2ZWx5 IGRlcGVuZGVkIG9uIHRoYXQgZHJhZnQuDQo+DQo+IEkgcmVhbGx5IGRvdWJ0IGFueW9uZSBpcyBn b2luZyB0byBhcmd1ZSB3aXRoIHRoYXQgc28gbGV0cyBtYWtlIGl0IHNvLg0KPg0KPj4gT24gTWF5 IDEzLCAyMDE3LCBhdCAxOjU0IEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+DQo+PiBIaSwNCj4+DQo+PiBBcyBjby1jaGFpciBv ZiBhIG51bWJlciBvZiB0aGUgZGVwZW5kZW5jaWVzLCB3ZSBoYXZlIGJlZW4gZGlzY3Vzc2luZyB3 aGF0IHRvIHJlZmVyZW5jZSBhIG51bWJlciBvZiB0aW1lcywgYW5kIHdlIGhhdmUgYWxzbyBjaGFu Z2VkIHRoZSByZWZlcmVuY2VzLiBXZSBjYW4ndCBrZWVwIGNoYW5naW5nIGJhY2sgYW5kIGZvcnRo Lg0KPj4NCj4+IEluIGFkZGl0aW9uLCBJIGRvbid0IHRoaW5rIFdHIFggY2FuIGRlY2lkZSB3aGF0 IHRoZSBkcmFmdHMgb2YgV0cgWSByZWZlcmVuY2UuIFRoZXJlIG5lZWRzIHRvIGJlIGEgY29sbGFi b3JhdGl2ZSBkZWNpc2lvbi4NCj4+DQo+PiAiV2UgYWxzbyBhc3N1bWVkIHRoYXQgc29tZSBuZXcg d29yayB3YXMgZ29pbmcgdG8gcmVxdWlyZSBjaGFuZ2VzIGluIElDRSBidXQgYXMgdGhhdCB3b3Jr IHdlbnQgcHJvZ3Jlc3NlZCwgd2UgbGFyZ2VseSBmaWd1cmVkIG91dCB3YXlzIHRvIG1ha2UgaXQg d29yayB3aXRoIGV4aXN0aW5nIElDRSBpbXBsZW1lbnRhdGlvbnMuIg0KPj4NCj4+IElzIHRoaXMg ImRpc2NvdmVyeSIgZG9jdW1lbnRlZCBzb21ld2hlcmU/DQo+Pg0KPj4gIklmIHRyaWNrbGUgaWNl IGFjdHVhbGx5IGdldHMgZG9uZSBiZWZvcmUgNTI0NWJpcywgYW5kIGl0IGRvZXMgbm90IGRlcGVu ZCBvbiBhbnkgNTI0NWJpcyBmZWF0dXJlcywgdGhlbiBjbGVhcmx5IGlzIHNob3VsZCBiZSBjaGFu Z2VkIHRvIGp1c3QgZGVwZW5kIG9uIDUyNDUuIg0KPj4NCj4+IEZpcnN0LCB3ZSBuZWVkIHRvIGFn cmVlIG9uIHdoZXRoZXIgdHJpY2tsZSBkZXBlbmRzIG9uIDUyNDViaXMgZmVhdHVyZXMgb3Igbm90 Lg0KPj4NCj4+IFNlY29uZCwgYXMgY28tYXV0aG9yIG9mIDUyNDViaXMsIEkgaGF2ZSBhc2tlZCB0 aGUgY2hhaXJzIHRvIGluaXRpYXRlIHRoZSByb2FkIHRvd2FyZHMgV0dMQywgc28gSSB3b3VsZCBo b3BlIGJvdGggNTI0NWJpcyBhbmQgdHJpY2tsZS1pY2UgY291bGQgYmUgZG9uZSBtb3JlIG9yIGxl c3MgYXQgdGhlIHNhbWUgdGltZS4NCj4+DQo+PiBSZWdhcmRzLA0KPj4NCj4+IENocmlzdGVyDQo+ Pg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBDdWxsZW4gSmVu bmluZ3MgW21haWx0bzpmbHVmZnlAaWlpLmNhXQ0KPj4gU2VudDogMTMgTWF5IDIwMTcgMDE6NTUN Cj4+IFRvOiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+OyBDaHJpc3RlciBIb2xtYmVyZyA8 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KPj4gQ2M6IFNlYW4gVHVybmVyIDxzZWFu QHNuM3JkLmNvbT47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPjsgcnRjd2ViLWNoYWlyc0BpZXRm Lm9yZzsgUlRDV2ViIElFVEYgPHJ0Y3dlYkBpZXRmLm9yZz47IGRyYWZ0LWlldGYtcnRjd2ViLW92 ZXJ2aWV3QGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW3J0Y3dlYl0gRXJpYyBSZXNjb3JsYSdz IERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1ydGN3ZWItb3ZlcnZpZXctMTg6ICh3aXRoIERJU0NVU1Mg YW5kIENPTU1FTlQpDQo+Pg0KPj4NCj4+IExldCBtZSB0cnkgYW5kIGFuc3dlciB3aXRoIHRoZSBj YXZlYXQgdGhhdCBJIG1heSBnZXQgdGhpcyB3cm9uZyBhbmQgbmVlZCB0byBiZSBjb3JyZWN0ZWQg YnkgbXkgY28tY2hhaXJzLi4uDQo+Pg0KPj4gVEw7RFIgLSBUaGUgY2hhaXJzIHJlY29tbWVuZCBj aGFuZ2luZyB0aGUgcmVmIGluIG92ZXJ2aWV3IHRvIHBvaW50IGF0IDUyNDUgaW5zdGVhZCBvZiA1 MjQ1LWJpcw0KPj4NCj4+DQo+PiBoZXJlIGlzIHRoZSBsb25nZXIgdmVyc2lvbi4uLi4NCj4+DQo+ PiBGaXJzdCBhIHNpZGUgbm90ZSBvbiBob3cgd2UgZ290IGhlcmUuIFNvbWUgb2YgdGhlIHJlYXNv bnMgd2Ugc2V0IHVwIGRlcGVuZGVuY2llc8KgIGxpa2UgdGhleSBhcmUgaXMgdGhhdCBtYW55IHll YXJzIGFnbyB3ZSBtYWRlIGd1ZXNzIGFib3V0IHdoYXQgb3JkZXIgd29yayB3b3VsZCBnZXQgY29t cGxldGVkIG9uIGFuZCwgc2hvY2tpbmdseSwgc29tZSBwcmVkaWN0aW9ucyBvZiBzdGFuZGFyZHMg ZGV2ZWxvcG1lbnRzIHRpbWVsaW5lcyB3ZXJlIGxlc3MgdGhhbiBwZXJmZWN0LiBXZSBhbHNvIGFz c3VtZWQgdGhhdCBzb21lIG5ldyB3b3JrIHdhcyBnb2luZyB0byByZXF1aXJlIGNoYW5nZXMgaW4g SUNFIGJ1dCBhcyB0aGF0IHdvcmsgd2VudCBwcm9ncmVzc2VkLCB3ZSBsYXJnZWx5IGZpZ3VyZWQg b3V0IHdheXMgdG8gbWFrZSBpdCB3b3JrIHdpdGggZXhpc3RpbmcgSUNFIGltcGxlbWVudGF0aW9u cy4NCj4+DQo+PiBXZSBhcmUgY29uZmlkZW50IHRoYXQgb3ZlcnZpZXcgZG9lcyBub3QgYWN0dWFs bHkgZGVwZW5kIG9uIGFueXRoaW5nIGluIDUyNDUtYmlzIGJ1dCBpbnN0ZWFkIGp1c3QgZGVwZW5k cyBvbiA1MjQ1Lg0KPj4NCj4+IE5leHQgbGV0cyBkaXNjdXNzIHRyaWNrbGUtaWNlLiBUaGUgV2Vi UlRDIHNldCBvZiBzcGVjcyBjdXJyZW50bHkgbm9ybWF0aXZlbHkgZGVwZW5kcyBvbiB0cmlja2xl IElDRS4gVGhlcmUgaXMgc29tZSBxdWVzdGlvbnMgaWYgdHJpY2tsZSBJQ0UgbWlnaHQgZGVwZW5k IG9uIDUyNDUtYmlzLiBTb21lIG9mIHRoZSB0cmlja2xlIElDRcKgIGF1dGhvcnMgZG8gbm90IHRo aW5rIGl0IGRvZXMuIE9uZSBvZiB0aGUgYXV0aG9ycyBzYWlkIHRoZSBjaGFpcnMgYXNrZWQgdGhl bSB0byByZWYgNTI0NSBpbnN0ZWFkIG9mIDUyNDViaXMgYXMgYm90aCB0aWNrbGUgSUNFIGFuZCA1 MjQ1YmlzIHdvdWxkIGJlIGRvbmUgYXJvdW5kIHRoZSBzYW1lIHRpbWUuIEluIGdlbmVyYWwsIHRo ZSB3ZWJydGMgY2hhaXJzIHdvdWxkIHByZWZlciB0byBtYWtlIHRoZSBXZWJSVEMgZGVwZW5kZW5j eSBjbHVzdGVyIGFzIHNtYWxsIGFzIHBvc3NpYmxlLiBJZiB0cmlja2xlIGljZSBhY3R1YWxseSBn ZXRzIGRvbmUgYmVmb3JlIDUyNDViaXMsIGFuZCBpdCBkb2VzIG5vdCBkZXBlbmQgb24gYW55IDUy NDViaXMgZmVhdHVyZXMsIHRoZW4gY2xlYXJseSBpcyBzaG91bGQgYmUgY2hhbmdlZCB0byBqdXN0 IGRlcGVuZCBvbiA1MjQ1LiBUaGUgV0cgcmVzcG9uc2libGUgZm9yIDUyNDViaXMgYW5kIHRyaWNr bGUgSUNFIGNhbiBmaWd1cmUgb3V0IHdoYXQgdGhleSB3YW50IHRvIGRvIGFzIGJvdGggdGhlc2Vz IGRyYWZ0cyBwcm9ncmVzcy4gR2l2ZW4gdGhlcmUgaXMgYSBzdHJvbmcgcG9zc2liaWxpdHkgdGhh dCB0cmlja2xlIGljZSB3aWxsIG9ubHkgcmVmZXJlbmNlIDUyNDUsIHdlIHRoaW5rIGl0IHdvdWxk IGJlIGJldHRlciBpZiBvdmVydmlldyBkaWQgbm90IGJyaW5nIDUyNDViaXMgaW50byB0aGUgV2Vi UlRDIGRlcGVuZGVuY3kgY2x1c3Rlci4gSWYgb24gdGhlIG90aGVyIGhhbmQsIHRyaWNrbGUgSUNF IGRvZXMgZW5kIHVwIGRlcGVuZGluZyBvbiA1MjQ1YmlzLCB0aGVyZSBpcyBubyBoYXJtLCBhbmQg bm8gbmVlZCB0byBjaGFuZ2Ugb3ZlcnZpZXcgdG8gcG9pbnQgYXQgNTI0NS4NCj4+DQo+PiBUaGVy ZSBhcmUgb3RoZXIgZHJhZnRzIHRoYXQgYXJlIG5vcm1hdGl2ZSBkZXBlbmRlbmNpZXMgb2YgSlNF UCBhbmQgdGhlIFdlYlJUQyBjbHVzdGVyIHRoYXQgYWxzbyBwb2ludCBhdCA1MjQ1YmlzLiBXaGVu IHdlIGNvbnNpZGVyIHRoZSB0ZWNobmljYWwgdGhpbmdzIHRoZXNlIGRyYWZ0cyBuZWVkLCBpdCBz ZWVtcyBsaWtlbHkgdGhleSBjYW4gYWxzbyByZWZlcmVuY2UgNTI0NSBpbnN0ZWFkIG9mIDUyNDVi aXMuIEZvciBleGFtcGxlIGRyYWZ0LWlldGYtaWNlLWR1YWxzdGFjay1mYWlybmVzcywgZHJhZnQt aWV0Zi1tbXVzaWMtaWNlLXNpcC1zZHAsIGRyYWZ0LWlldGYtbW11c2ljLXNkcC1idW5kbGUtbmVn b3RpYXRpb24sIGFuZCBkcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzICh3aGljaCBpcyB3aXRo IHRoZSBSRkMgRWRpdG9yKS4gVGhlIGFyZ3VtZW50IGZvciB0aGUgb3RoZXJzIGlzIHJvdWdobHkg dGhlIHNhbWUgYXMgaXQgaXMgd2l0aCB0cmlja2xlIElDRS4NCj4+DQo+PiBDdWxsZW4gKHdpdGhv dXQgcmV2aWV3IGZyb20gbXkgY28tY2hhaXJzIGJ1dCB0cnlpbmcgdG8gcmVwcmVzZW50IHdoYXQg d2UgZGlzY3Vzc2VkIG9uIG91ciBjaGFpciBjYWxsKQ0KPj4NCj4+DQo+PiBQUyAtIGlmIHlvdSBh cmUgdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgc29tZSBvZiB0aGUgZGVwZW5kZW5jaWVzIGZvciB0aGUg V2ViUlRDIGNsdXN0ZXIsIHlvdSBtaWdodCBmaW5kIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWplbm5pbmdzLXJ0Y3dlYi1kZXBzLz9pbmNsdWRlX3RleHQ9MSB1c2VmdWwg YnV0IGl0IGlzIG5vdCAxMDAlIGFjY3VyYXRlLg0KPj4NCj4+DQo+Pg0KPj4+IE9uIE1heSAxMSwg MjAxNywgYXQgNzo0MyBBTSwgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPiB3cm90ZToNCj4+ Pg0KPj4+IFF1ZXN0aW9uIGZvciB0aGUgY2hhaXJzLg0KPj4+DQo+Pj4gT24gVGh1LCBNYXkgMTEs IDIwMTcgYXQgMTI6NDQgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20+IHdyb3RlOg0KPj4+IEhpLA0KPj4+DQo+Pj4gV2hhdCBpcyB0aGUgc3RhdHVz IHJlZ2FyZGluZyB0aGlzPw0KPj4+DQo+Pj4gUmVnYXJkcywNCj4+Pg0KPj4+IENocmlzdGVyDQo+ Pj4NCj4+Pj4gT24gMjYvMDQvMTcgMDY6MDIsICJTZWFuIFR1cm5lciIgPHNlYW5Ac24zcmQuY29t PiB3cm90ZToNCj4+Pj4NCj4+Pj4NCj4+Pj4+IE9uIEFwciAyMywgMjAxNywgYXQgMTQ6NDQsIENo cmlzdGVyIEhvbG1iZXJnDQo+Pj4+PiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3 cm90ZToNCj4+Pj4+DQo+Pj4+PiBIaSwNCj4+Pj4+DQo+Pj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4g LS0tLQ0KPj4+Pj4+IERJU0NVU1M6DQo+Pj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4gLS0tLQ0KPj4+ Pj4+DQo+Pj4+Pj4gWW91ciBjaXRhdGlvbiB0byBJQ0UgaXMgdG8gNTI0NS1iaXMsIGJ1dCBhdCBs ZWFzdCB0aGUgSlNFUCBlZGl0b3INCj4+Pj4+PiBjb25zZW5zdXMgd2FzIHRoYXQgV2ViUlRDIGRl cGVuZGVkIG9uIDUyNDUsIHNvIHRoaXMgbmVlZHMgdG8gYmUNCj4+Pj4+PiByZXNvbHZlZCBvbmUg d2F5IG9yIHRoZSBvdGhlci4NCj4+Pj4+DQo+Pj4+PiBLZWVwIGluIG1pbmQgdGhhdCwgbm8gbWF0 dGVyIHdoYXQgZHJhZnQtcnRjd2ViLW92ZXJ2aWV3IGFuZA0KPj4+Pj4gZHJhZnQtcnRjd2ViLWpz ZXAgZXhwbGljaXRseSBzYXksIGJvdGggc3BlY3MgcmVmZXJlbmNlIDUyNDViaXMNCj4+Pj4+ICpJ TVBMSUNJVExZKiwgZS5nLiwgdmlhIGRyYWZ0LW1tdXNpYy1idW5kbGUsIGRyYWZ0LWljZS10cmlj a2xlDQo+Pj4+PiBldGMuLi4gQXMgSSBoYXZlIGluZGljYXRlZCBpbiB0aGUgcGFzdCwgaXQgd291 bGQgY2F1c2UgY29uZnVzaW9uIHRvIHJlZmVyZW5jZSBib3RoLg0KPj4+Pj4NCj4+Pj4+IFNvLCBJ IHRoaW5rIHdlIHNoYWxsIHJlZmVyZW5jZSA1MjQ1LWJpcyBldmVyeXdoZXJlIChJIGFsc28gdGhv dWdodA0KPj4+Pj4gd2UgYWxyZWFkeSBkZWNpZGVkIG5vIHRoYXQgaW4gdGhlIHBhc3QpLQ0KPj4+ Pj4NCj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pg0KPj4+Pj4gQ2hyaXN0ZXINCj4+Pj4NCj4+Pj4gLyog YmlrZSBzaGVkIGFsZXJ0Og0KPj4+PiAvKg0KPj4+PiAvKiBBc3N1bWluZyB5b3XCuXJlIG9mIHRo ZSBtaW5kIHRoYXQgYSBiaXMvdXBkYXRlcyBkcmFmdCBpcw0KPj4+PiAvKiBzaWduYWxpbmcgdG8g YWxsIGltcGxlbWVudG9ycyBvZiB0aGUgb3JpZ2luYWwgUkZDIHRoYXQgdGhlDQo+Pj4+IC8qIGlu dGVudGlvbiBpcyB0aGF0IGFsbCBpbXBsZW1lbnRhdGlvbnMgYmUgdXBkYXRlZCB0aGVuIGl0wrlz DQo+Pj4+IC8qIGEgYml0IG1vcmUgdGhhbiBpbXBsaWNpdC4NCj4+Pj4NCj4+Pj4gc3B0DQo+Pj4+ DQo+Pj4NCj4+Pg0KPj4NCj4NCg0K From nobody Mon May 15 09:52:22 2017 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 1BC7512946D; Mon, 15 May 2017 09:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=unavailable 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 obETfNPrmqu0; Mon, 15 May 2017 09:52:08 -0700 (PDT) Received: from smtp105.iad3a.emailsrvr.com (smtp105.iad3a.emailsrvr.com [173.203.187.105]) (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 34ACC12EA8C; Mon, 15 May 2017 09:48:45 -0700 (PDT) Received: from smtp6.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp6.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 54A595431; Mon, 15 May 2017 12:48:44 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp6.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id F1AFF54DE; Mon, 15 May 2017 12:48:42 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.200.189] (mystydragon.com [72.253.150.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Mon, 15 May 2017 12:48:44 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_6B1D4260-62AF-4B42-9143-3BA8C72DB2AC" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CBA0BF0@ESESSMB109.ericsson.se> Date: Mon, 15 May 2017 06:48:40 -1000 Cc: Eric Rescorla , Sean Turner , The IESG , "rtcweb-chairs@ietf.org" , RTCWeb IETF , "draft-ietf-rtcweb-overview@ietf.org" Message-Id: References: <149285978295.25905.7347383325486705546.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CB805F3@ESESSMB109.ericsson.se> <15D737F9-2F65-45C5-AA26-946910B4030F@sn3rd.com> <7594FB04B1934943A5C02806D1A2204B4CBA05BC@ESESSMB109.ericsson.se> <225E4246-AB30-4877-9DCF-D5D2A8ABDF18@ericsson.com> <7594FB04B1934943A5C02806D1A2204B4CBA0B12@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CBA0BF0@ESESSMB109.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [rtcweb] Eric Rescorla's Discuss on draft-ietf-rtcweb-overview-18: (with DISCUSS and COMMENT) 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, 15 May 2017 16:52:09 -0000 --Apple-Mail=_6B1D4260-62AF-4B42-9143-3BA8C72DB2AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 13, 2017, at 8:14 AM, Christer Holmberg = wrote: >=20 >=20 > I am, however, aware that a number of dependencies do refer 5245bis. = Maybe they don't need to, but my point is that I think all dependencies = should reference the same ICE spec - RFC 5245 *OR* 5245bis. And I think = RTCWEB, MMUSIC and ICE should agree on which spec. Since more or less = the same people participate in all those groups, I don't think it should = be a difficult thing to achieve.=20 I feel very strongly that unless one can show there is technical part of = draft X you need to read to implement draft Y, then Y should not = normatively reference X.=20 Perhaps there is something in ICEbis that is needed by one of the RTCweb = specs and if so, we should discuss this but so far I'm not aware of any.=20= --Apple-Mail=_6B1D4260-62AF-4B42-9143-3BA8C72DB2AC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On May 13, 2017, at 8:14 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:


I am, however, = aware that a number of dependencies do refer 5245bis. Maybe they don't = need to, but my point is that I think all dependencies should reference = the same ICE spec - RFC 5245 *OR* 5245bis. And I think RTCWEB, MMUSIC = and ICE should agree on which spec. Since more or less the same people = participate in all those groups, I don't think it should be a difficult = thing to achieve. 

I feel very strongly that unless one can show = there is technical part of draft X you need to read to implement draft = Y, then Y should not normatively reference X. 

Perhaps there is = something in ICEbis that is needed by one of the RTCweb specs and if so, = we should discuss this but so far I'm not aware of any. 


= --Apple-Mail=_6B1D4260-62AF-4B42-9143-3BA8C72DB2AC-- From nobody Mon May 15 11:28:11 2017 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 689151293FD; Mon, 15 May 2017 11:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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] 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 P6Mf--6JCoZV; Mon, 15 May 2017 11:28:07 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 009E1127867; Mon, 15 May 2017 11:24:59 -0700 (PDT) X-AuditID: c1b4fb30-29dff7000000015f-28-5919f278770e Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 91.AB.00351.872F9195; Mon, 15 May 2017 20:24:58 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0339.000; Mon, 15 May 2017 20:24:56 +0200 From: Christer Holmberg To: Cullen Jennings CC: Eric Rescorla , Sean Turner , The IESG , "rtcweb-chairs@ietf.org" , "RTCWeb IETF" , "draft-ietf-rtcweb-overview@ietf.org" Thread-Topic: [rtcweb] Eric Rescorla's Discuss on draft-ietf-rtcweb-overview-18: (with DISCUSS and COMMENT) Thread-Index: AQHSu1nlcZL8BStkfUysDoOyMAqI5qHTV0EQgAODp4CAGBVbgIAAMMGAgAI9D4CAAKUNEIAAQg4AgABAHwCAAATigIAAIjZA///g+wCAACNr0IAC7S8AgAA7+LA= Date: Mon, 15 May 2017 18:24:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CBA36E6@ESESSMB109.ericsson.se> References: <149285978295.25905.7347383325486705546.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CB805F3@ESESSMB109.ericsson.se> <15D737F9-2F65-45C5-AA26-946910B4030F@sn3rd.com> <7594FB04B1934943A5C02806D1A2204B4CBA05BC@ESESSMB109.ericsson.se> <225E4246-AB30-4877-9DCF-D5D2A8ABDF18@ericsson.com> <7594FB04B1934943A5C02806D1A2204B4CBA0B12@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CBA0BF0@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CBA36E6ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGIsWRmVeSWpSXmKPExsUyM2K7lm7VJ8lIgx+3eC22vD7BZrHi9Tl2 iw/rfzBazPgzkdmi5+0NFou1/9rZLa6samR2YPdYsuQnk8fl8x8ZPSY/bmP2OHiQMYAlissm JTUnsyy1SN8ugStj/+JPzAUfbSvW3gtoYDxi1sXIwSEhYCLxqyevi5GLQ0jgCKNE84dFLBDO EkaJVw0bmUCK2AQsJLr/aXcxcnKICChLnNtxlxmkhlngP6PE//2fWUESwgI5EssPH2SBKMqV uLlhJtggEYEuRomby3+zgQxiEVCV+PBUAaSGV8BXomXCcahld9kkPr7cxQ6S4BSwkpg1oRHM ZhQQk/h+ag0TiM0sIC5x68l8MFtCQEBiyZ7zzBC2qMTLx/9YIWwlicYlT1gh6vMlTv5oYYJY JihxcuYTlgmMIrOQjJqFpGwWkjKIuI7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ilG0OLU4 KTfdyEgvtSgzubg4P08vL7VkEyMwNg9u+W2wg/Hlc8dDjAIcjEo8vN2PJSOFWBPLiitzDzFK cDArifB2vAQK8aYkVlalFuXHF5XmpBYfYpTmYFES53XcdyFCSCA9sSQ1OzW1ILUIJsvEwSnV wMi33NVWpmDVfLFLtpsyA6e2Flma2QsvNA3ZsVlwW4HJrBex0/5ITbdmq9obufRBgp3q06fF nBM5ps5OWapvK9y4Q2pi5Dzb2E/+MxwceZ6yWkvMqr3flWq2oehlw8WDr3VvKJ3/0qzh+eGz wf1fhV+4ym0l1ksFCC5fLz11Y/CRtf+8LAve+SuxFGckGmoxFxUnAgC1WkBKyQIAAA== Archived-At: Subject: Re: [rtcweb] Eric Rescorla's Discuss on draft-ietf-rtcweb-overview-18: (with DISCUSS and COMMENT) 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, 15 May 2017 18:28:09 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CBA36E6ESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, So, we should check and confirm with the affected WGs whether 5245bis is re= quired within the RTCWEB dependencies that currently reference 5245bis. Regards, Christer From: Cullen Jennings [mailto:fluffy@iii.ca] Sent: 15 May 2017 18:49 To: Christer Holmberg Cc: Eric Rescorla ; Sean Turner ; The IESG ; rtcweb-chairs@ietf.org; RTCWeb IETF ; draft= -ietf-rtcweb-overview@ietf.org Subject: Re: [rtcweb] Eric Rescorla's Discuss on draft-ietf-rtcweb-overview= -18: (with DISCUSS and COMMENT) On May 13, 2017, at 8:14 AM, Christer Holmberg > wrote: I am, however, aware that a number of dependencies do refer 5245bis. Maybe = they don't need to, but my point is that I think all dependencies should re= ference the same ICE spec - RFC 5245 *OR* 5245bis. And I think RTCWEB, MMUS= IC and ICE should agree on which spec. Since more or less the same people p= articipate in all those groups, I don't think it should be a difficult thin= g to achieve. I feel very strongly that unless one can show there is technical part of dr= aft X you need to read to implement draft Y, then Y should not normatively = reference X. Perhaps there is something in ICEbis that is needed by one of the RTCweb sp= ecs and if so, we should discuss this but so far I'm not aware of any. --_000_7594FB04B1934943A5C02806D1A2204B4CBA36E6ESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

So, we sho= uld check and confirm with the affected WGs whether 5245bis is required wit= hin the RTCWEB dependencies that currently reference 5245bis.

 = ;

Regards,

 = ;

Christer

 

From: = Cullen Jennings [mailto:fluffy@iii.ca]
Sent: 15 May 2017 18:49
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Eric Rescorla <ekr@rtfm.com>; Sean Turner <sean@sn3rd.c= om>; The IESG <iesg@ietf.org>; rtcweb-chairs@ietf.org; RTCWeb IETF= <rtcweb@ietf.org>; draft-ietf-rtcweb-overview@ietf.org
Subject: Re: [rtcweb] Eric Rescorla's Discuss on draft-ietf-rtcweb-o= verview-18: (with DISCUSS and COMMENT)

 

 

On May 13, 2017, at 8:14 AM, Christer Holmberg <<= a href=3D"mailto:christer.holmberg@ericsson.com">christer.holmberg@ericsson= .com> wrote:

 


I am, however, aware that a number of dependencies do refer 5245bis. Maybe = they don't need to, but my point is that I think all dependencies should re= ference the same ICE spec - RFC 5245 *OR* 5245bis. And I think RTCWEB, MMUS= IC and ICE should agree on which spec. Since more or less the same people participate in all those groups, = I don't think it should be a difficult thing to achieve. 

 

I feel very strongly that unless one can show there = is technical part of draft X you need to read to implement draft Y, then Y = should not normatively reference X. 

 

Perhaps there is something in ICEbis that is needed = by one of the RTCweb specs and if so, we should discuss this but so far I'm= not aware of any. 

 

 

--_000_7594FB04B1934943A5C02806D1A2204B4CBA36E6ESESSMB109erics_-- From nobody Tue May 16 09:41:19 2017 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 678B4129B9C for ; Tue, 16 May 2017 09:41:11 -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=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 hH-ggO82bmv7 for ; Tue, 16 May 2017 09:41:09 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 2C67812EB6E for ; Tue, 16 May 2017 09:36:38 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id e65so91227073ita.1 for ; Tue, 16 May 2017 09:36:38 -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=IQ7XRo8jh9bpgbCSOvruKby0zSnBfy4xmjRieSjUxY4=; b=VHowDCfT2OdtWmafbIGWGBxDVCD1dNI2YurYiZ8IAa7RREPX+et5UfawKfkFFA0hzh 579H56HfLzRLyY9PR57tdzr7N36TTddLRjdsJ9qskr3ds0+SkSay2SnBk0Ig8TwGjV5Y ZPc4EqArdrUwu+dZqqBx9zFk6V6rpPYtA335I= 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=IQ7XRo8jh9bpgbCSOvruKby0zSnBfy4xmjRieSjUxY4=; b=DpXSlcRJN26jVOiGNjtyci0bf84IgrF1JciXR5Og+tcTQTXZGkOo1tUagIPmc7oI3l Vf6rKBCCAUErRrYwhk1xzz2rBKXrDLwjAv9qXC93EQ04vFQdp16d/B6jnLL8tBaDrj/J 2EIBB1CzFmvkBCeBUqeyyopX7eiCSsZme2oa6bGDtU1zkZ1KC8TIJHwBBc/ndQwHR56Q h9KmwFyU+p5bss6AqExyjG1cXye/c1IIVEff8DpbYaf7GxiDXUQaQ5u3XxQ0mNC/+e3+ 7V+XCw8mcmPss/pHUWc4AIbLbtQTwKdjdcWHb5BPa2JRrJck7GY9oXZfkj8nmcOS/NlU fKLw== X-Gm-Message-State: AODbwcD9fUitiom61hbrMJ7rRm6Bg4XzK8qDrcR8anDUvVhr0KaKKGhr hv6F6lSNzn3qUWSj X-Received: by 10.36.73.131 with SMTP id e3mr11646727itd.0.1494952597408; Tue, 16 May 2017 09:36:37 -0700 (PDT) Received: from [5.5.33.114] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id p77sm5211912ioe.3.2017.05.16.09.36.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 May 2017 09:36:36 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: <149308787999.21838.15962349444845062362.idtracker@ietfa.amsl.com> Date: Tue, 16 May 2017 12:36:31 -0400 Cc: The IESG , draft-ietf-rtcweb-overview@ietf.org, rtcweb-chairs@ietf.org, rtcweb@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <84AF0527-287F-475C-9EE0-56DE0F5EA4B2@sn3rd.com> References: <149308787999.21838.15962349444845062362.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-overview-18: (with COMMENT) 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, 16 May 2017 16:41:11 -0000 > On Apr 24, 2017, at 22:37, Ben Campbell wrote: >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I am balloting "yes", but I have a few minor comments: >=20 > Substantive Comments: >=20 > -2.2 :=20 > -- Why is a WebRTC gateway assumed to be a "compatible" endpoint = rather > than a full endpoint? I recognize a gateway is different from a = typical > end-user endpoint, but are there specific endpoint requirements that a > gateway is not likely to meet? (Feel free to say "it's documented in = the > gateway draft...." :-) ) It=E2=80=99s documented in the (cough) now expired gateways draft: https://www.ietf.org/archive/id/draft-ietf-rtcweb-gateways-02.txt Ted=E2=80=99s pinged Harald to revive this one. > -- "In this case, similar security considerations as for Javascript = may > be needed; however, since such APIs are not defined or referenced = here, > this document cannot give any specific rules for those interfaces." > I am confused by this sentence, since I don't see any security > considerations specific to Javascript in this draft, either. RTCweb Javascript-related security considerations are addressed in the = (cough) now expired security drafts: https://www.ietf.org/archive/id/draft-ietf-rtcweb-security-arch-12.txt https://www.ietf.org/archive/id/draft-ietf-rtcweb-security-08.txt The Security Considerations points to draft-ietf-rtcweb-security, which = will get you to the other draft as well. > -7 > -- list item 2: Is it an open question whether a signaling gateway is > needed for interacting with SIP devices? I do not believe that item #2 (copied below) is an open question, it=E2=80= =99s just pointing out that if you are going try to interoperate with = legacy SIP devices you=E2=80=99re going to have to do more work. 2. It will be possible to gateway between legacy SIP devices that support ICE and appropriate RTP / SDP mechanisms, codecs and security mechanisms without using a media gateway. A signaling gateway to convert between the signaling on the web side to the SIP signaling may be needed. > -- Last paragraph: This is specifically about non-browser endpoints, > right? As written, it seems to weaken the previous paragraph about > browser endpoints, since the draft previously said the term "endpoint" > includes both browsers and non-browsers. Nope, it=E2=80=99s about all endpoints. Look at it this way the = penultimate paragraph says WebRTC browser implement the API and all = WebRTC endpoints implement the protocols. That=E2=80=99s in-line with = the definitions defined earlier in s2.2 > -9, 2nd bullet: "Privacy concerns MUST be satisfied..." > Is that MAY really intended as normative, or is a statement of fact? = If > normative, what actor(s) does it constrain? Also, if it is normative, = the > clause "the APIs should be available" seems to weaken the MUST.=20 This is supposed to be normative. It=E2=80=99s constraining the = =E2=80=9Clocal system=E2=80=9D :). I=E2=80=99m not sure it weakens it = because it=E2=80=99s a should not a SHOULD. But, since this draft also = addresses endpoints that don=E2=80=99t have to have an API, we can=E2=80=99= t really make it a SHOULD. > Editorial Comments: >=20 > -2.3, last paragraph: The paragraph is a single, convoluted sentence = that > is hard to parse. (It's also a comma splice). Please consider breaking > into multiple simpler sentences. https://github.com/rtcweb-wg/rtcweb-overview/pull/19 > -3, first paragraph: This is also convoluted and hard to parse. https://github.com/rtcweb-wg/rtcweb-overview/pull/21 > -7, list item 1: The citiation to [3264] seems misplaced. It describes > the offer/answer model, not SIP in general. I suggest moving the = citation > to after the word "semantics=E2=80=9D. https://github.com/rtcweb-wg/rtcweb-overview/pull/35/files spt From nobody Tue May 16 09:41:30 2017 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 915D912EC19 for ; Tue, 16 May 2017 09:41:15 -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=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 ZrVS_Z_lgjod for ; Tue, 16 May 2017 09:41:13 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 3D83612EBB7 for ; Tue, 16 May 2017 09:36:40 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id f102so96982593ioi.2 for ; Tue, 16 May 2017 09:36:40 -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=O4SNuvpnkrsQsHOY98kLrA1dvqsV9M+haXt3Z6R2nFY=; b=fIJLw1T6UQRt03gazRPogKz8oExiJlZGznv2q3AQl1ZDgiN+JUvzhhfen0jhfAr8V2 Rfr73mIX5g3DhyeppXbiqIcTK4SYW5OdBvGN3beSwdYs5blUr7SFi0mFZtP+VxoUgPFn IU1K2b07z8MdBJds2UTnj7WahJd1gTRHNzMLM= 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=O4SNuvpnkrsQsHOY98kLrA1dvqsV9M+haXt3Z6R2nFY=; b=sywpAPHwBaUOt/T0cj2FBEpS5Mv/zaM+HK0PAD/av5aikS5CBchiP3Ml4WJRLIBYiP qBNdlW3LJ2oeI59dJYGMLY0sUeWdmR46kdAja50gfjyaCtO4Tf9egB4SN+YwEgIoz4te ZnfBDBX+cAbBVctqAEM0n8ZzyXkV/1hfELavt9EV+dOAy/Wg6cpzC5BUOp5daOc4yIz6 WJ8VbF/ntql/wGFHVurGBBZNkkHjZMkqfGCgqE0lNrLmQEDxgYASpv22k/7x+Z3WJRDe D10BPtn2gGY9rTAogPy7Vy3/9Jc8LDhHT2QbfwFzHGAKnwx16ZfX1gLBddODSF8T/laz RP/g== X-Gm-Message-State: AODbwcD6OUBG32RKjohCcpxaS1I5oi855pQnoskIAGgbG9WFMteLOofp OlghktcxDNO3+w== X-Received: by 10.107.18.203 with SMTP id 72mr11601793ios.149.1494952599564; Tue, 16 May 2017 09:36:39 -0700 (PDT) Received: from [5.5.33.114] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id p77sm5211912ioe.3.2017.05.16.09.36.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 May 2017 09:36:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: <149323455621.2873.875476556259905398.idtracker@ietfa.amsl.com> Date: Tue, 16 May 2017 12:36:37 -0400 Cc: The IESG , draft-ietf-rtcweb-overview@ietf.org, rtcweb-chairs@ietf.org, rtcweb@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <32069FF1-F9D4-453E-BE9C-2341E71B21D9@sn3rd.com> References: <149323455621.2873.875476556259905398.idtracker@ietfa.amsl.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [rtcweb] Spencer Dawkins' Yes on draft-ietf-rtcweb-overview-18: (with COMMENT) 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, 16 May 2017 16:41:16 -0000 > On Apr 26, 2017, at 15:22, Spencer Dawkins = wrote: >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I've been waiting for this one, for a while. Thanks for finishing it. = I'm > a Yes, with comments. >=20 > I agree with EKR that there's a lot of general philosophy in this = draft. > I wouldn't ask that you pull all of it, but perhaps it could be = trimmed > down a bit. The chairs discussed this and we=E2=80=99re going to not make a change = here primarily because I fear we might go to far the other way and then = we=E2=80=99re playing bring me rock. > This is a nit, but in this text, >=20 > Other efforts, for instance the W3C WEBRTC, Web Applications and > Device API working groups, focus on making standardized APIs and > interfaces available, within or alongside the HTML5 effort, >=20 > it would be nice to have the names here match what's on the W3C = website. > So, "Web Real-Time Communication", "Web Application Security", and > "Device and Sensors", unless I'm guessing at the mapping wrong. It's = also > easy to read that text with "Web Applications and Device API" as a = single > working group, so using a comma after "Web Application Security" would = be > helpful. I pulled the named from here: https://www.w3.org/TR/tr-groups-all The PR can be found here: https://github.com/rtcweb-wg/rtcweb-overview/pull/23 > The term of art "floor control" is likely to be new to many readers in > the future. Since it appears in a list of non-niche examples, maybe = you > don't need it at all? I=E2=80=99m hoping people know how to google :) The wikipedia definition = that popped up as the 1st result pretty much covers it. > I'm not sure whether "let a thousand flowers bloom" is a reference to = the > Hundred Flowers campaign in 1956, but (1) that ended very badly for = the > bloomers, and (2) I could easily imagine the phrase tripping DPI > filtering for a specific part of the Internet community. Maybe there's = a > better phrase? There might be but that the phrase I=E2=80=99ve often heard to refer to = =E2=80=9Clet the market sort it out". > I'm not sure how tutorial you want section 4 to be, but I'd at least > mention appropriate retransmission and in-order delivery, in addition = to > congestion control, since you get that with SCTP on the data channel. >=20 > 4. Data transport >=20 > Data transport refers to the sending and receiving of data over the > network interfaces, the choice of network-layer addresses at each > end > of the communication, and the interaction with any intermediate > entities that handle the data, but do not modify it (such as TURN > relays). >=20 > It includes necessary functions for congestion control: When not to > send data. >=20 > Or maybe you can just chop that sentence, because the next paragraph > points to https://tools.ietf.org/html/draft-ietf-rtcweb-transports-06, > anyway? I just listed the additional SCTP functions: https://github.com/rtcweb-wg/rtcweb-overview/pull/25/files > I found the reference to MMUSIC WG in >=20 > 3. When a new codec is specified, and the SDP for the new codec is > specified in the MMUSIC WG, no other standardization should be > required for it to be possible to use that in the web browsers. >=20 > to be odd. MMUSIC may be around forever, but this work might be > refactored at some point in the future. Is the point that=20 >=20 > 3. When SDP for a new codec is specified,=20 > no other standardization should be > required for it to be used in the web browsers. >=20 > Or is there another way to say this? Fair enough, we can future proof the document with this change: https://github.com/rtcweb-wg/rtcweb-overview/pull/27 > I'm also wondering if the statement is true for any WebRTC endpoint, = not > just browsers. I=E2=80=99m not sure, but the main point of that entire bullet is that = there=E2=80=99s no changes necessary to the API an not all endpoints = need to implement the API on the browser does. > In this text, >=20 > WebRTC endpoints MUST implement the functions described in that > document that relate to the network layer (for example Bundle > [I-D.ietf-mmusic-sdp-bundle-negotiation], RTCP-mux [RFC5761] and > Trickle ICE [I-D.ietf-ice-trickle]), but do not need to support the > API functionality described there. >=20 > I would have thought these were related to the transport layer. No? Maybe, but since these drafts/RFCs are about setting up the connection = they do seem to fit in the =E2=80=9CConnection Management=E2=80=9D = section ;) spt From nobody Tue May 16 09:41:54 2017 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 DAD2912EC49 for ; Tue, 16 May 2017 09:41:41 -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=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 Tqc8hn2e3HR5 for ; Tue, 16 May 2017 09:41:36 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 30ADD12EC1C for ; Tue, 16 May 2017 09:36:45 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id o12so97361050iod.3 for ; Tue, 16 May 2017 09:36:45 -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=DkyoHgNfvEwPln1PPwTbjWgmYt7YJWnzhE56jJPcso4=; b=R97Y4qwdJ5dBbhPwouPaMCsDSg/DDPd1uxfto5P3l+ItEZphsIKU91Jo8+j1x6EVYq hyNGLZ0vQLCS+jlKGBdSohgrCLFB09flfS61OqcXxGpZzeNVuMLjRnCtZibG2+WIXtw1 la45RA9rzqSDVLRD7jN/nyKJBH0gBb9ncdxBo= 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=DkyoHgNfvEwPln1PPwTbjWgmYt7YJWnzhE56jJPcso4=; b=boLvdoWbgD74vfRL59pIvXWRkNfxHu/wD2+4d1X4nkrwZx1l78QuHTa7UVp7W0H9aW tnioCMsPaJSP7BFPRPON0eGORnBWLl6YLYZiSfQwJByDvEiyg8yW7qO1Ww/Esu35e2pY x2Or73+pko9W38JTEcuY6/JWEAlyFnjLbILI00HY30bIwoNR3j/6XxPee4CXAOZJQ6RG U5llG2IjqNOaObPZgjr28/l/Y8nTzK1vE9XVwnKqqlkzpU/8i6wY5o76bGpljKoUKkFm t+ZRDJSoelD0GFXuCv4eM4OSUInSGW8/yi8Wj3BqN39EGSKr50A9FI0I+OjWTJXa6EqR bd+g== X-Gm-Message-State: AODbwcDIFZD+6d9YqTXVhKcIRBI+LXIDEq8IaqoGAPz1kAp5W//2t9TH vi6E2aDG75elYg== X-Received: by 10.107.161.19 with SMTP id k19mr11981960ioe.204.1494952604507; Tue, 16 May 2017 09:36:44 -0700 (PDT) Received: from [5.5.33.114] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id p77sm5211912ioe.3.2017.05.16.09.36.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 May 2017 09:36:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: <149303566483.25889.317046108892686691.idtracker@ietfa.amsl.com> Date: Tue, 16 May 2017 12:36:42 -0400 Cc: The IESG , draft-ietf-rtcweb-overview@ietf.org, rtcweb-chairs@ietf.org, rtcweb@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <149303566483.25889.317046108892686691.idtracker@ietfa.amsl.com> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [rtcweb] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-rtcweb-overview-18=3A_=28with_COMMENT=29?= 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, 16 May 2017 16:41:42 -0000 > On Apr 24, 2017, at 08:07, Mirja K=C3=BChlewind = wrote: >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > One high level comments on normative language: > While I think this document is very useful to explain the relationship > between the other webrtc documents and serves a a good starting point = for > an implementor, I'm not sure if the use of normative language is = actually > helpful. Most of the language is used to say that a webrtc endpoint = MUST > implement a certain other document. However, I believe this is = inherently > necessary to achieve interoperability. So I don't see a need to = specify > this normatively. I can see that but I also think that as a =E2=80=9Ctreasure map=E2=80=9D = document pointing normatively could work, i.e., it=E2=80=99s a style = thing. > In regard to the shepherd write-up, I just want to note that using > normative language does not automatically make the document Standards > Track; there are many informational docs that use normative language. = As > such, I don't want raise a big discussion on status now, but this > document sounds more informational to me (giving pointers to other > document). However, I don't object to publication on Standards Track. Addressed via Ben=E2=80=99s response. > minor comments: > 1) I would not need all the text on the history of Internet = communication > in this doc (especially all text on page 3 in the intro as well as > section 2.3 and the second to last paragraph in 3)... however, I guess = it > doesn't hurt It is wordy, but I think Harald=E2=80=99s just providing background for = folks who might note be so in the know. > 2) Agree with Warren that 'Protocol' probably doesn't need to be > (re)defined in this doc I waffled around with deleting, but since this is a comment I=E2=80=99m = leaning towards just leaving it based on the principle that it doesn=E2=80= =99t really do any harm leaving it in. > 3) section 3:=20 > "Data transport: TCP, UDP and the means to securely set up > connections between entities, as well as the functions for > deciding when to send data: Congestion management, bandwidth > estimation and so on." > This seems to implicitly assume that only TCP or something = encapsulated > over UDP can be used. Even though that might be true, I assume this = was > not intentionally, maybe: > NEW > "Data transport: such as TCP or UDP and the means to securely set up > connections between entities, as well as the functions for > deciding when to send data: Congestion management, bandwidth > estimation and so on.=E2=80=9D Fixed via PR: https://github.com/rtcweb-wg/rtcweb-overview/pull/29 > nit: > -"massage the signals": not sure if "massage" is actually a meaningful > word here=E2=80=A6 manipulate might be a better word. Fixed via PR: https://github.com/rtcweb-wg/rtcweb-overview/pull/31 spt= From nobody Tue May 16 09:42:15 2017 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 5133812EC22 for ; Tue, 16 May 2017 09:41:56 -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=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 yJdHYjCGYGjN for ; Tue, 16 May 2017 09:41:55 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 BB6C112EC24 for ; Tue, 16 May 2017 09:36:50 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id f102so96985979ioi.2 for ; Tue, 16 May 2017 09:36:50 -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=rzZ8gF/UwfKlRx0Fz8zQLnrPT41vzg0pMovNOBLLXnM=; b=Zhkt06pTmQ6DSrk2ABugBIbsSvGzH8RONZMbZa3dAWSdL8bwW9Y9zpIeDDuzTqTkZJ 1nyNpCJXH3BH3Jo0xo1kiHt8Kw5ijR4e+uGdxkWdGlp1UCyUypfWlPHIossyGNhvMBoq Au5VAxXE+WoNXX+eu4wmZW/epcmXA8d9/twLc= 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=rzZ8gF/UwfKlRx0Fz8zQLnrPT41vzg0pMovNOBLLXnM=; b=ZN7UdlMBmCN6lKIw2+dX+KK2aiK7L6TyBSEN/jADGheyVqU1m7X6/Hcv9EoZ0uKXf6 tBeblvfkWKASHDpurkjsA/Lql9USaxOyQ7Cl0TAifMdECywnGUcZ1Aot+6i9cH1ad35P 6zmX6Vm6Znq42gMnlOy3tgURp3XYKp5NkeWy2KpqS1niEL+ikJYId+JVid46GpsB3EDk bAmnAz4HtwPp3Kemqgs0KV7yLkyzVpWruKL+66p+QgCuFdVy6X6U5taVT8QynXiPVbfS jbfAZeBzzPm7Y+0KUrcEaaH90wQD4J2KDW1IDj7bhcY1M209N/7ZXJ5pkroT7HTc7MvC UIvg== X-Gm-Message-State: AODbwcDATAWx6xneo5XT5Xeiv7Rq6vS3wFZKZIt0H2P1YUWMqTgoB0iq kZjUPLUMuoS16A== X-Received: by 10.107.23.66 with SMTP id 63mr6846340iox.184.1494952610007; Tue, 16 May 2017 09:36:50 -0700 (PDT) Received: from [5.5.33.114] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id p77sm5211912ioe.3.2017.05.16.09.36.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 May 2017 09:36:49 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: <149330304139.2869.18368236668622249540.idtracker@ietfa.amsl.com> Date: Tue, 16 May 2017 12:36:47 -0400 Cc: The IESG , draft-ietf-rtcweb-overview@ietf.org, rtcweb-chairs@ietf.org, rtcweb@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3D82CEB3-F405-412A-8F2D-6C2A199D06AC@sn3rd.com> References: <149330304139.2869.18368236668622249540.idtracker@ietfa.amsl.com> To: Benoit Claise X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [rtcweb] Benoit Claise's No Objection on draft-ietf-rtcweb-overview-18: (with COMMENT) 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, 16 May 2017 16:41:56 -0000 > On Apr 27, 2017, at 10:24, Benoit Claise wrote: >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > This topic below was discussed during the IESG telechat: >=20 > Reading from the document objectives, from the abstract: >=20 > This document gives an overview and context of a protocol suite > intended for use with real-time applications that can be deployed in > browsers - "real time communication on the Web". >=20 > It intends to serve as a starting and coordination point to make > sure > all the parts that are needed to achieve this goal are findable, and > that the parts that belong in the Internet protocol suite are fully > specified and on the right publication track. >=20 > Reading this, I was thinking: great, I will have the full overview. > With "deployed", "starting and coordination point to make sure that = all > the parts ..." I will have some focus on the operational aspects, > basically, how should operators operate theses browser-embedded > applications. > Now, reading further ... >=20 > This document is intended to serve as the roadmap to the WebRTC > specifications. It defines terms used by other parts of the WebRTC > protocol specifications, lists references to other specifications > that don't need further elaboration in the WebRTC context, and gives > pointers to other documents that form part of the WebRTC suite. >=20 > ... I thought: Ok, if not covered here, at least I will have a pointer = to > another operational document. > But wait: >=20 > By reading this document and the documents it refers to, it should > be > possible to have all information needed to implement an WebRTC > compatible implementation. >=20 > So is this only about implementation? >=20 > I like this document very much as it explains all the RTCWEB pieces in > one location. However, there is one important piece missing: the = network > management considerations. See > https://datatracker.ietf.org/doc/html/rfc5706#appendix-A > This is where I'm coming from, discussing some more with Warren (this = a > cut and past from this ballot): >=20 > [ Edit: So, after more thought (and some discussion) I think that = it > would be useful for the document to at least note the fact that > technologies like this mean that some of the existing operational > practices may need to change. For example, many enterprises perform = QoS > based upon the fact that certain types of devices live in certain = subnets > (e.g many phones get placed in a specific VLAN using LLDP or CDP). = With > more real time content coming from browsers, these matching practices > break, and so operators may not be able to QoS mark / prioritize = traffic > accordingly. Perhaps something like: "One of the implications of a > solution like WebRTC is that more real-time traffic will be sourced = from > computers (and not dedicated devices like telephones or = videoconferencing > devices). This may have implications for operators performing QoS = marking > and prioritization" ? This isn't really specific to webrtc, but rather = to > a more general set of solutions like softphones and the like, but is > accelerated by WebRTC. ] >=20 > In light of the previous discussions about = draft-mm-wg-effect-encrypt-11, > the operators are used to manage voice, video, gaming a certain way, = with > their operational current practices. Now, their current practices = might > not work any longer. What should they do now in term of monitoring, > troubleshooting, QoS, SLA monitoring, etc these days with WebRTC? > While we should add this note (or a similar one) in the doc, I'm > wondering: where are (should be) those operational aspects discussed, = if > not here? > I've seen https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-18, = not > sure it's appropriate. Anyway, it's now in a RFC-editor state. > I could have requested a specific manageability doc in the charter. = Too > late now. To address Benoit/Warren/Kathleen=E2=80=99s comments on this, I=E2=80=99ve= submitted the following PR: https://github.com/rtcweb-wg/rtcweb-overview/pull/15 spt= From nobody Tue May 16 09:42:37 2017 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 B494912EC4C for ; Tue, 16 May 2017 09:42:08 -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=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 NPWD-e_-q9bq for ; Tue, 16 May 2017 09:42:07 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 93C5612EC27 for ; Tue, 16 May 2017 09:36:53 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id o12so97363777iod.3 for ; Tue, 16 May 2017 09:36:53 -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=079clCvfhsEjg+F8O8I1VtDia2CujDUCBvxScrs7KyU=; b=YrLEiKV/w4W6RMnlS2WZp9WL8BpejaDwF0zUNZSvkXrqCfsWecqfoPB8yfFeOw4yur GjdqsSxVA0FGC2IUqFQk9VFGK5SLJZyFbWqX3NPS+tZEtMtjzicH3zIRfaG1FIwEGDqM 5/YkFqJMmEVsT4ppdKZM5/04AzoMxjo9lEjY4= 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=079clCvfhsEjg+F8O8I1VtDia2CujDUCBvxScrs7KyU=; b=VQedWIXpavaPcujD3apU1ufCz8NRmGR+32OURdY/Om+qrDO3+2cOY7rILy3upyB1vf 0yAJjZko0m1Ab6N1B8O6wdE0qo7QkvON1T3TRNi1d5Qz5ddG6i5MfD8kWgM/7gdDljll gU1466Pbhej5OzrnPM/O9I7TAejICV5GmazPa5QTr6UCyydUXgVm3+Tvysw6n+wIkd+K eP+ePsMzcYld479FTkbrAeEpYj0eKMgPaIZWzgQIqB0DF/JZFlzRCW5rCfakUl9zIdif +/4u6TD/8p/VxV8UFGPch3VOZIZ4GSlQ8FBGUx07yjNdoP9CSsEeumO9PMR2u/NaH6H4 k6tg== X-Gm-Message-State: AODbwcCi9QKP4M/YHAqfn8NumrEdl+QETHRgLMHIuOuEXOiHxOK3aXva ofA8xZ3+QK05Yw== X-Received: by 10.107.173.155 with SMTP id m27mr8924629ioo.52.1494952612874; Tue, 16 May 2017 09:36:52 -0700 (PDT) Received: from [5.5.33.114] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id p77sm5211912ioe.3.2017.05.16.09.36.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 May 2017 09:36:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: <149314689247.17908.12182134468119701573.idtracker@ietfa.amsl.com> Date: Tue, 16 May 2017 12:36:50 -0400 Cc: The IESG , draft-ietf-rtcweb-overview@ietf.org, rtcweb-chairs@ietf.org, rtcweb@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5989F802-F407-4213-B4CC-82F6346FE9F5@sn3rd.com> References: <149314689247.17908.12182134468119701573.idtracker@ietfa.amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [rtcweb] Kathleen Moriarty's No Objection on draft-ietf-rtcweb-overview-18: (with COMMENT) 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, 16 May 2017 16:42:09 -0000 > On Apr 25, 2017, at 15:01, Kathleen Moriarty = wrote: >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for your work on this draft, it's a helpful overview. I see = the > reasoning in the shepherd report for informational, but am curious if = the > standards track status is needed for other SDOs that might reference = this > document? =20 Addressed via discussions with Ben/Adam. > In reading sections 8 & 9, I would think the presentation and control = in > section 8 would have the privacy implications of the second bullet in > section 9. As such, it seems odd that normative language is used in = this > bullet and not in section 8. I'd be fine with no normative language = in > either as long as the protocol drafts cover that appropriately. Some > mention of privacy in section 8 could be helpful since it covers more > ground than the example in section 9. I=E2=80=99m looking at it this way: s8 is really also about local system = support functions too. We could reorder s8 and s9, but I=E2=80=99m = hoping that thinking about s8 as a local support functions is = sufficient. > Security considerations: I don't see anything listed for security or > privacy considerations in respect to the signaling channel to the > web/application server. Should there be considerations listed? = Security > of the actual server and content on the server as well as = vulnerabilities > in listening protocols are just a few of the questions that come to = mind. > If it doesn't matter, please let me know. I appreciate the comment on > the browser being target rich as they have been in many attacks to = gain > entry into networks leveraging established outbound sessions. Maybe = this > is covered in I-D.ietf-rtcweb-security and if so (have not had a = chance > to review it yet), a high-level mention of gateway security here might = be > helpful. The security considerations and privacy considerations are addressed the = two (cough) now expired security drafts: (cough) now expired security drafts: https://www.ietf.org/archive/id/draft-ietf-rtcweb-security-arch-12.txt https://www.ietf.org/archive/id/draft-ietf-rtcweb-security-08.txt The Security Considerations points to draft-ietf-rtcweb-security, which = will get you to the other draft. Instead of recreating all of that here, = I=E2=80=99m basically asking for your patience until these drafts make = it to the IESG in the next couple of months. There=E2=80=99s a huge, = and I mean Donald Trump =E2=80=9Cyugeee=E2=80=9D, cluster of drafts that = can=E2=80=99t go anywhere until those the security drafts get through = the process so I hoping until then you=E2=80=99ll be satisfied = sharpening your weapons of mass DISCUSSion until then ;) > I agree with Warren's comment about the management aspects being = covered > here since it is an overview document. It could be a very helpful > consideration for protocol developers that may devise new ways to = enable > management as a result of understanding the issues. Addressed via PR: https://github.com/rtcweb-wg/rtcweb-overview/pull/15 > I had to look up jingle and BOSH, you may want to consider adding > references to the XMPP specifications. Hmm there are references to XMPP and Jingle in the draft. BOSH, I had = to look up too ;). Added a reference via the following PR: https://github.com/rtcweb-wg/rtcweb-overview/pull/33 spt From nobody Tue May 16 09:42:49 2017 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 A26CE12EC23 for ; Tue, 16 May 2017 09:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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=-2.8, RCVD_IN_SORBS_SPAM=0.5, 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=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 XaZaXMK2oRFk for ; Tue, 16 May 2017 09:42:26 -0700 (PDT) Received: from mail-io0-f176.google.com (mail-io0-f176.google.com [209.85.223.176]) (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 0EE5512EBFF for ; Tue, 16 May 2017 09:36:57 -0700 (PDT) Received: by mail-io0-f176.google.com with SMTP id o12so97364938iod.3 for ; Tue, 16 May 2017 09:36:57 -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=Xzn8EvJAXImml7nhbxPmRu8omtlIiQIyPiR6RFsKHeA=; b=dl49YCjjXid2MaIlJHYzWYBa4Eyimle2P+pemb+EMBj9BzE5yR7kmb4sG3EzJjmNAm VhOuExBLcxp+fBDEZN9smDqrC5tePSk8NjIU3hEx4QQD4ABpP1hSfRDeqPWGkjAMBSPK YhG1CmtZj0Mq3hetUTf20VtTT3+8MblCWnpUg= 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=Xzn8EvJAXImml7nhbxPmRu8omtlIiQIyPiR6RFsKHeA=; b=V00CsRysGh+BzVwOWeZpN3o+h9SdiyhOCblzFRcZyoixfrMAOe2Vfw/Nklu5xR7BR8 M/tvajTVVXtZGs/zDXMSL70Azi/3EhU3YHpdU1S3MeXe0KTnLLLlabEWs7hJvabkQfJz l0RHQBO4A6O31Rtf8O354a9ZiwfzhgSyrMSJ/b7K4d/TB6lXLRNQ8qlbB9W5K0njYL+U 75OyhKfs0IlRC+GKlFW2OOwItgAKUXn+Ki6Rojb4BVexCxQplhrxRWAp9sKL4EpqbRjP 10+pwwg5ji+GzvcX/B1oZrzvWarrn19YIIuf23+wGcM0fayff5jPauqc199cpUDays0u mPoQ== X-Gm-Message-State: AODbwcBt0j65PVKADn3/fwAeWYcIcm6ccLOXq4Vl5q4MohQPy9g5+J7S us4UETYeAhOU6g== X-Received: by 10.107.170.16 with SMTP id t16mr11397566ioe.113.1494952616279; Tue, 16 May 2017 09:36:56 -0700 (PDT) Received: from [5.5.33.114] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id p77sm5211912ioe.3.2017.05.16.09.36.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 May 2017 09:36:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: <149313309242.25495.7497824051996027302.idtracker@ietfa.amsl.com> Date: Tue, 16 May 2017 12:36:54 -0400 Cc: The IESG , draft-ietf-rtcweb-overview@ietf.org, rtcweb-chairs@ietf.org, rtcweb@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6A958EF5-4C21-4AA8-8FE0-E69A369211B5@sn3rd.com> References: <149313309242.25495.7497824051996027302.idtracker@ietfa.amsl.com> To: Warren Kumari X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [rtcweb] Warren Kumari's No Objection on draft-ietf-rtcweb-overview-18: (with COMMENT) 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, 16 May 2017 16:42:28 -0000 > On Apr 25, 2017, at 11:11, Warren Kumari wrote: >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thank you -- I like these sort of overview documents for complex = things > like WebRTC - they provide a newcomer to the technology a good place = to > start, and help describe some of the reasons why things look the way = they > do. >=20 > [ Edit: So, after more thought (and some discussion) I think that it > would be useful for the document to at least note the fact that > technologies like this mean that some of the existing operational > practices may need to change. For example, many enterprises perform = QoS > based upon the fact that certain types of devices live in certain = subnets > (e.g many phones get placed in a specific VLAN using LLDP or CDP). = With > more real time content coming from browsers, these matching practices > break, and so operators may not be able to QoS mark / prioritize = traffic > accordingly. Perhaps something like: "One of the implications of a > solution like WebRTC is that more real-time traffic will be sourced = from > computers (and not dedicated devices like telephones or=20 > videoconferencing devices). This may have implications for operators > performing QoS marking and prioritization" ? This isn't really = specific > to webrtc, but rather to a more general set of solutions like = softphones > and the like, but is accelerated by WebRTC. ]=20 To address Benoit, Kathleen, and Warren=E2=80=99s concerns here=E2=80=99s = a PR: https://github.com/rtcweb-wg/rtcweb-overview/pull/15 > I do have a few comments on the document itself - there are all minor = / > bikeshedding and can be ignored if you choose: > 1: "Development of The Universal Solution has proved hard, however, = for > all the usual reasons." > -- this is cute, but leaves people wondering what "all the usual = reasons > are". Perhaps just "Development of The Universal Solution has, = however,=20 > proved hard." (or just cut after the "however in the original"). >=20 > 2: I'm not sure why you have "Protocol" in the terminology section. It > doesn't seem like it is useful for the document, and this document > doesn't seem like the right place to (re) define it. >=20 > 3: Acknowledgements:=20 > Funny spacing in "Olle E. Johansson=E2=80=9D To address #1 and #3, here=E2=80=99s a PR: https://github.com/rtcweb-wg/rtcweb-overview/pull/17/files Note I=E2=80=99m going to leave protocol in because I don=E2=80=99t = think it really hurts to leave it in. spt= From nobody Tue May 16 09:43:28 2017 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 98EA712EC51 for ; Tue, 16 May 2017 09:43: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=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 vNgyO7_gPNPm for ; Tue, 16 May 2017 09:43:11 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 D0A8712EC33 for ; Tue, 16 May 2017 09:37:05 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id c15so65688770ith.0 for ; Tue, 16 May 2017 09:37:05 -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=Z7qEL5CJg0aPT3fSpJvfOmbH1OwKOn8xu1PVBVBZ4pQ=; b=CH7WKDN/VslRelRb9XKJuwIe3CymFHkAJIbh+OurS9QX/G+iFkWwgEkdpM5vPze8cK B3RdJL2CRQJZOmoh9KRlhq7gtcGuv8fcY7xBcRdgvcIkobQuql7e4XVP9MyjfA9LIsB7 Gq0JPsI8gczbbd9GlixjGydiLr+u+nqyeuOlw= 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=Z7qEL5CJg0aPT3fSpJvfOmbH1OwKOn8xu1PVBVBZ4pQ=; b=bCX7t7dTpqDpGNSsyKe0b+nwy+KcHCpztkCAGKs8AGFCDltqanCE0/EuQHmbOTu4xK ch3NxBEogSdXE/omYb5T2WLGG9O7p34qNj4wkBC30bpCMjY5gzcoWMe/j3D5Rz1o9lVE tNog0HP2hts2dP4Xf6OvcMutPmvl9VB8IHqKl7MjN06Dir0BlIX4S0/+zCEyCMgQp9cb WfGB+3nxraF9Px9yYhINaVsSpF20RxLl4+jdvCoSjO1wY05jGQcdjnz0k4MF6PHMS6B9 B2/82birbOgqKeEuImDtN0Q1l07sr32WQOyVsDW2Pb5xi4B1o1rVBRWB174/T6VJFVe2 VImA== X-Gm-Message-State: AODbwcBPf4lHB9f5dCriX2GMGuT/X9Rp2MBsFv1UFI9ap0wXn6+O8y44 6CMxk8J/iBnI8rog X-Received: by 10.36.193.66 with SMTP id e63mr11532013itg.86.1494952625268; Tue, 16 May 2017 09:37:05 -0700 (PDT) Received: from [5.5.33.114] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id p77sm5211912ioe.3.2017.05.16.09.37.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 May 2017 09:37:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: <149285978295.25905.7347383325486705546.idtracker@ietfa.amsl.com> Date: Tue, 16 May 2017 12:37:03 -0400 Cc: The IESG , draft-ietf-rtcweb-overview@ietf.org, rtcweb-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <56868A9A-C993-469F-9F0A-51E756C5FEBB@sn3rd.com> References: <149285978295.25905.7347383325486705546.idtracker@ietfa.amsl.com> To: Eric Rescorla , RTCWeb IETF X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [rtcweb] Eric Rescorla's Discuss on draft-ietf-rtcweb-overview-18: (with DISCUSS and COMMENT) 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, 16 May 2017 16:43:19 -0000 > On Apr 22, 2017, at 07:16, Eric Rescorla wrote: >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Your citation to ICE is to 5245-bis, but at least the JSEP editor > consensus was that WebRTC depended on 5245, so this needs to be = resolved > one way or the other. The chairs believe that the overview draft should refer to RFC5245. = There=E2=80=99s nothing in overview that requires a reference to = 5245-bis (aka ICE-bis); it=E2=80=99s a definition for an "ICE Agent=E2=80=9D= . And, let=E2=80=99s face it overview is going directly into cluster = 238. So instead of arguing about whether to refer ICE or ICE-bis now = when overview is going to get stuck anyway let=E2=80=99s let the process = run it=E2=80=99s course: if trickle-ICE is going to get done about the = same time as ICE-bis then great we can update the references in AUTH48 = and if not we can figure out plan B. I=E2=80=99ve submitted the following PR to change the reference to 5245: https://github.com/rtcweb-wg/rtcweb-overview/pull/37 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- I haven=E2=80=99t yet completed the editorial changes as a result of = ekr's comments so I=E2=80=99ll address that in another email. spt= From nobody Tue May 16 09:49:57 2017 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 75FE81200F3; Tue, 16 May 2017 09:49:55 -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 DZn3er-Vr5DP; Tue, 16 May 2017 09:49:54 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e: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 7B28D1294F5; Tue, 16 May 2017 09:45:12 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id u28so79136355pgn.1; Tue, 16 May 2017 09:45:12 -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=8+wjxAFYnj+tLzvMPuU+mqzZF/NfbaotIeESn8/6tj0=; b=ZsO79uT24Cd2LjMkWy/6BNxyidM/zLxn6c/SUupiRBwI4y/DfuIcM+e3IzkY9qLfSC n8BKD6FC26Bh+MSLx1yrarTb5Fo7f4gMg9tIEd9DEwrASdWGmRX2Yv3wiq52e8ZsIcmW +UZKaKMkpUxoEPxWBf6k4X9yWYf8Gmb6RvqpbAE/oOmNWTS29yEuaP+XBxIdmrIcgjD9 UpWY5wvZf81LCYV+t5ec0IMSxefPs3zY/gHKEAwfLdqWco6nzRCIqkM20bFiHUy1gf/c kXL1cqMKorF1/bugwBB4Y56Dou+902KPJA5bm3Jv5a1YG29tsY9U1U+F/pwNVbDrMeWU HALA== 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=8+wjxAFYnj+tLzvMPuU+mqzZF/NfbaotIeESn8/6tj0=; b=dpAnXNG8E1ScFfqhVNfrbkJ1i95UGbzHHUl2QtCo5y9lXSVdpnf2YN7KbgZi2rYGK3 Z34RPX2HQMfmr10Po2E2YivBYsshp0v0zCK1W3m6E0158tNLS0reu9URAl3M5nVv4jPt FjysMngqgyGwNYtWR7+0a02kjxGwTTCTifiJxOFij+zNf29n572XJxhV68WYc9Lv3AWH hNPMO4UhpARPRJHUdX+fv0zGdmGrGwXUQQtjTeE5yqfVQk5+FZnir02Ge9M1AW2xsKuf km7itiXWWwO/z2fcGj2SmvNZXqOUd32X6KCvnCLW/+WjbhXcj0XRErZ8yHqH348PL86Z cLTA== X-Gm-Message-State: AODbwcD17mQZnes4NUbFm37s5EHdvDDp9vDImyRVFNweN0EHKh0ZApFu e/n9qZnbLbHQOOPeV5s+dSmmD0nNLA== X-Received: by 10.98.67.140 with SMTP id l12mr13295075pfi.110.1494953111958; Tue, 16 May 2017 09:45:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.135 with HTTP; Tue, 16 May 2017 09:44:31 -0700 (PDT) In-Reply-To: <5989F802-F407-4213-B4CC-82F6346FE9F5@sn3rd.com> References: <149314689247.17908.12182134468119701573.idtracker@ietfa.amsl.com> <5989F802-F407-4213-B4CC-82F6346FE9F5@sn3rd.com> From: Kathleen Moriarty Date: Tue, 16 May 2017 12:44:31 -0400 Message-ID: To: Sean Turner Cc: The IESG , draft-ietf-rtcweb-overview@ietf.org, rtcweb-chairs@ietf.org, rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Kathleen Moriarty's No Objection on draft-ietf-rtcweb-overview-18: (with COMMENT) 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, 16 May 2017 16:49:55 -0000 Hi Sean, Thanks very much for your response to my comments. The solutions all look good and I appreciate the updates that were made. On Tue, May 16, 2017 at 12:36 PM, Sean Turner wrote: > >> On Apr 25, 2017, at 15:01, Kathleen Moriarty wrote: >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thanks for your work on this draft, it's a helpful overview. I see the >> reasoning in the shepherd report for informational, but am curious if th= e >> standards track status is needed for other SDOs that might reference thi= s >> document? > > Addressed via discussions with Ben/Adam. > >> In reading sections 8 & 9, I would think the presentation and control in >> section 8 would have the privacy implications of the second bullet in >> section 9. As such, it seems odd that normative language is used in thi= s >> bullet and not in section 8. I'd be fine with no normative language in >> either as long as the protocol drafts cover that appropriately. Some >> mention of privacy in section 8 could be helpful since it covers more >> ground than the example in section 9. > > I=E2=80=99m looking at it this way: s8 is really also about local system = support functions too. We could reorder s8 and s9, but I=E2=80=99m hoping = that thinking about s8 as a local support functions is sufficient. That's fine, this was just a comment anyway. Thanks. > >> Security considerations: I don't see anything listed for security or >> privacy considerations in respect to the signaling channel to the >> web/application server. Should there be considerations listed? Securit= y >> of the actual server and content on the server as well as vulnerabilitie= s >> in listening protocols are just a few of the questions that come to mind= . >> If it doesn't matter, please let me know. I appreciate the comment on >> the browser being target rich as they have been in many attacks to gain >> entry into networks leveraging established outbound sessions. Maybe thi= s >> is covered in I-D.ietf-rtcweb-security and if so (have not had a chance >> to review it yet), a high-level mention of gateway security here might b= e >> helpful. > > The security considerations and privacy considerations are addressed the = two (cough) now expired security drafts: > (cough) now expired security drafts: > https://www.ietf.org/archive/id/draft-ietf-rtcweb-security-arch-12.txt > https://www.ietf.org/archive/id/draft-ietf-rtcweb-security-08.txt > The Security Considerations points to draft-ietf-rtcweb-security, which w= ill get you to the other draft. Instead of recreating all of that here, I= =E2=80=99m basically asking for your patience until these drafts make it to= the IESG in the next couple of months. There=E2=80=99s a huge, and I mean= Donald Trump =E2=80=9Cyugeee=E2=80=9D, cluster of drafts that can=E2=80=99= t go anywhere until those the security drafts get through the process so I = hoping until then you=E2=80=99ll be satisfied sharpening your weapons of ma= ss DISCUSSion until then ;) That sounds fine, thank you. > >> I agree with Warren's comment about the management aspects being covered >> here since it is an overview document. It could be a very helpful >> consideration for protocol developers that may devise new ways to enable >> management as a result of understanding the issues. > > Addressed via PR: > https://github.com/rtcweb-wg/rtcweb-overview/pull/15 Thanks for that! > >> I had to look up jingle and BOSH, you may want to consider adding >> references to the XMPP specifications. > > Hmm there are references to XMPP and Jingle in the draft. BOSH, I had to= look up too ;). Added a reference via the following PR: > https://github.com/rtcweb-wg/rtcweb-overview/pull/33 Thanks! > > spt > --=20 Best regards, Kathleen From nobody Tue May 16 12:51:20 2017 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 7F54A12955A for ; Tue, 16 May 2017 12:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-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 b53tr9ASdxdf for ; Tue, 16 May 2017 12:51:12 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 791E512EC4C for ; Tue, 16 May 2017 12:46:54 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id g49so106623529uaa.1 for ; Tue, 16 May 2017 12:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zAv6lAyd4pN4c6Z+6/Y+iJKrZiPe7L+Horv6R2XP3mw=; b=fPa/Ua4MXNG85mAGZ2GrcQVVzzDUD1V67Ft+Fgs07/I0aI49VMpxdYOdkSMK+h8SMQ DafxtnLW2CNQ9N93cz3yWOIKJCo+Cl4WeMkKSHG3QCLtVAVFsSL87X1wcHh/Gi56WXId 8TAVJZVE8U3fpbM2kAJaDplBF0FEuNfH4sO0c4gTsWNK8hGCmJi/erzsfPBR91iy3dT/ sYTMvC5xZ1OnRXB1H73pyb4YBXtZTnz7S1feO4eKmBGMPPEmNMBjAuyy5hPgcSCakGB9 3Ls5fk6xk1nC3VwTIojKDV0aAArH87gqEjSWob0FrmwTctLzyxq0z9N4+q0rby2hz+/A ZAtg== 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=zAv6lAyd4pN4c6Z+6/Y+iJKrZiPe7L+Horv6R2XP3mw=; b=aBwBkyBTdPU1+Z16VRUP5wPN8BlyxmcPnFDT1RISEth0ScKwYKDVfYEP4AtHDB+2Gw IO101ZvTVPD7xFciPtqNBLYW+qfc2PEe86nRmaj/AieLfC9svjkEcrzOMzpYSq+Y8GMs QAd/G/hh3a/vHxsM1S43fh3ZmBmDIlAVblE4lh+UncmfklTH5cdZTAI3tCf2Chkw7SCH jbeTbZmOXDlEn0dQQTQaZhhgIDZYjca1FPVJr+sbAZm8RR+w3a0IN1ngHfHNplp6+53c sv3+41JazdEHgHXEHCkyXbTFPmK4cDmhlvkUK5pKZn77IFzs5RxbFcLP7zyb98IrOyNk qjdA== X-Gm-Message-State: AODbwcBpt310huhLg5Pr4QQ9dDec0bqGVVOd+4cZ1jwB9Ku3GjjYtpPu 9QVzSgG1bEh3yn4eWdfBZP+DkwTWtQBD X-Received: by 10.159.34.54 with SMTP id 51mr7000303uad.110.1494964013314; Tue, 16 May 2017 12:46:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.71.83 with HTTP; Tue, 16 May 2017 12:46:12 -0700 (PDT) In-Reply-To: <6A958EF5-4C21-4AA8-8FE0-E69A369211B5@sn3rd.com> References: <149313309242.25495.7497824051996027302.idtracker@ietfa.amsl.com> <6A958EF5-4C21-4AA8-8FE0-E69A369211B5@sn3rd.com> From: Warren Kumari Date: Tue, 16 May 2017 15:46:12 -0400 Message-ID: To: Sean Turner Cc: The IESG , draft-ietf-rtcweb-overview@ietf.org, rtcweb-chairs@ietf.org, rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Warren Kumari's No Objection on draft-ietf-rtcweb-overview-18: (with COMMENT) 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, 16 May 2017 19:51:13 -0000 Thank you very much. These work for me... W On Tue, May 16, 2017 at 12:36 PM, Sean Turner wrote: > >> On Apr 25, 2017, at 11:11, Warren Kumari wrote: >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thank you -- I like these sort of overview documents for complex things >> like WebRTC - they provide a newcomer to the technology a good place to >> start, and help describe some of the reasons why things look the way the= y >> do. >> >> [ Edit: So, after more thought (and some discussion) I think that it >> would be useful for the document to at least note the fact that >> technologies like this mean that some of the existing operational >> practices may need to change. For example, many enterprises perform QoS >> based upon the fact that certain types of devices live in certain subnet= s >> (e.g many phones get placed in a specific VLAN using LLDP or CDP). With >> more real time content coming from browsers, these matching practices >> break, and so operators may not be able to QoS mark / prioritize traffic >> accordingly. Perhaps something like: "One of the implications of a >> solution like WebRTC is that more real-time traffic will be sourced from >> computers (and not dedicated devices like telephones or >> videoconferencing devices). This may have implications for operators >> performing QoS marking and prioritization" ? This isn't really specific >> to webrtc, but rather to a more general set of solutions like softphones >> and the like, but is accelerated by WebRTC. ] > > To address Benoit, Kathleen, and Warren=E2=80=99s concerns here=E2=80=99s= a PR: > https://github.com/rtcweb-wg/rtcweb-overview/pull/15 > >> I do have a few comments on the document itself - there are all minor / >> bikeshedding and can be ignored if you choose: >> 1: "Development of The Universal Solution has proved hard, however, for >> all the usual reasons." >> -- this is cute, but leaves people wondering what "all the usual reasons >> are". Perhaps just "Development of The Universal Solution has, however, >> proved hard." (or just cut after the "however in the original"). >> >> 2: I'm not sure why you have "Protocol" in the terminology section. It >> doesn't seem like it is useful for the document, and this document >> doesn't seem like the right place to (re) define it. >> >> 3: Acknowledgements: >> Funny spacing in "Olle E. Johansson=E2=80=9D > > To address #1 and #3, here=E2=80=99s a PR: > https://github.com/rtcweb-wg/rtcweb-overview/pull/17/files > > Note I=E2=80=99m going to leave protocol in because I don=E2=80=99t think= it really hurts to leave it in. > > spt --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue May 16 14:35:41 2017 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 980BB12F27C; Tue, 16 May 2017 14:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 L1y7vRWTdhbz; Tue, 16 May 2017 14:35:30 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20A03131447; Tue, 16 May 2017 14:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4356; q=dns/txt; s=iport; t=1494970209; x=1496179809; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=0QVzrKKLm+8yIEVR1T3O6IuEzUocvuSXilRZkbRAz9s=; b=PJY03kFSbWYzX4q/p7AEGt0OLl6XbmtQSpcPKyqbc+cGurpOZHU7s/Zr fwonDzztnvVR3gvvpZTOVyN6vB0IpM+gCp67FpQyEfgNU9LYyXgIa9iBX zp7+h2LMpuBlUSH8mTTso+VC8/TihRTW+gOil/eUeKdyv52An429iG/T1 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AhAQDIbhtZ/40NJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQyDbIoYkUMhlXWCDyyFeAKFTz8YAQIBAQEBAQEBayiFGQE?= =?us-ascii?q?FIw8BBUEQCxgCAiYCAlcGDQYCAQEXiggOrEWCJosGAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBGwWBC4VUgV4rC4Jlh3WCYAEEiUSNK4cbhxyLf4sChmmMFIgvHziBCi8gCBk?= =?us-ascii?q?VhXKBTD42iEMBAQE?= X-IronPort-AV: E=Sophos;i="5.38,350,1491264000"; d="scan'208";a="425287838" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 May 2017 21:30:08 +0000 Received: from [10.82.180.116] ([10.82.180.116]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v4GLU7SL007777; Tue, 16 May 2017 21:30:07 GMT To: Sean Turner Cc: The IESG , draft-ietf-rtcweb-overview@ietf.org, rtcweb-chairs@ietf.org, rtcweb@ietf.org References: <149330304139.2869.18368236668622249540.idtracker@ietfa.amsl.com> <3D82CEB3-F405-412A-8F2D-6C2A199D06AC@sn3rd.com> From: Benoit Claise Message-ID: <63c2e6f4-1aec-791d-7783-f960dc06c519@cisco.com> Date: Tue, 16 May 2017 23:30:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <3D82CEB3-F405-412A-8F2D-6C2A199D06AC@sn3rd.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Benoit Claise's No Objection on draft-ietf-rtcweb-overview-18: (with COMMENT) 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, 16 May 2017 21:35:33 -0000 Thanks Sean. Regards, B. >> On Apr 27, 2017, at 10:24, Benoit Claise wrote: >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> This topic below was discussed during the IESG telechat: >> >> Reading from the document objectives, from the abstract: >> >> This document gives an overview and context of a protocol suite >> intended for use with real-time applications that can be deployed in >> browsers - "real time communication on the Web". >> >> It intends to serve as a starting and coordination point to make >> sure >> all the parts that are needed to achieve this goal are findable, and >> that the parts that belong in the Internet protocol suite are fully >> specified and on the right publication track. >> >> Reading this, I was thinking: great, I will have the full overview. >> With "deployed", "starting and coordination point to make sure that all >> the parts ..." I will have some focus on the operational aspects, >> basically, how should operators operate theses browser-embedded >> applications. >> Now, reading further ... >> >> This document is intended to serve as the roadmap to the WebRTC >> specifications. It defines terms used by other parts of the WebRTC >> protocol specifications, lists references to other specifications >> that don't need further elaboration in the WebRTC context, and gives >> pointers to other documents that form part of the WebRTC suite. >> >> ... I thought: Ok, if not covered here, at least I will have a pointer to >> another operational document. >> But wait: >> >> By reading this document and the documents it refers to, it should >> be >> possible to have all information needed to implement an WebRTC >> compatible implementation. >> >> So is this only about implementation? >> >> I like this document very much as it explains all the RTCWEB pieces in >> one location. However, there is one important piece missing: the network >> management considerations. See >> https://datatracker.ietf.org/doc/html/rfc5706#appendix-A >> This is where I'm coming from, discussing some more with Warren (this a >> cut and past from this ballot): >> >> [ Edit: So, after more thought (and some discussion) I think that it >> would be useful for the document to at least note the fact that >> technologies like this mean that some of the existing operational >> practices may need to change. For example, many enterprises perform QoS >> based upon the fact that certain types of devices live in certain subnets >> (e.g many phones get placed in a specific VLAN using LLDP or CDP). With >> more real time content coming from browsers, these matching practices >> break, and so operators may not be able to QoS mark / prioritize traffic >> accordingly. Perhaps something like: "One of the implications of a >> solution like WebRTC is that more real-time traffic will be sourced from >> computers (and not dedicated devices like telephones or videoconferencing >> devices). This may have implications for operators performing QoS marking >> and prioritization" ? This isn't really specific to webrtc, but rather to >> a more general set of solutions like softphones and the like, but is >> accelerated by WebRTC. ] >> >> In light of the previous discussions about draft-mm-wg-effect-encrypt-11, >> the operators are used to manage voice, video, gaming a certain way, with >> their operational current practices. Now, their current practices might >> not work any longer. What should they do now in term of monitoring, >> troubleshooting, QoS, SLA monitoring, etc these days with WebRTC? >> While we should add this note (or a similar one) in the doc, I'm >> wondering: where are (should be) those operational aspects discussed, if >> not here? >> I've seen https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-18, not >> sure it's appropriate. Anyway, it's now in a RFC-editor state. >> I could have requested a specific manageability doc in the charter. Too >> late now. > To address Benoit/Warren/Kathleen’s comments on this, I’ve submitted the following PR: > https://github.com/rtcweb-wg/rtcweb-overview/pull/15 > > spt. > From nobody Tue May 16 14:56:28 2017 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 127ED12EC9F for ; Tue, 16 May 2017 14:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 1KhGC4kERfG8 for ; Tue, 16 May 2017 14:56:24 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 E70931289B0 for ; Tue, 16 May 2017 14:51:10 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id e28so108614339uah.0 for ; Tue, 16 May 2017 14:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=cU+hvH+MyU8hUb39HjBeFn3jkAFnKEO7edBRkvivwjQ=; b=eSGovBDDuW37OaA66B9AP1x/v6TmUfoChrEvM781Xnul9G5I3RJh/JDKT+Er8ZV8by bMkwlUFmo2sq6CFyy4FcSt2DRLZ8bUw3QiOkqLJJSSKtxT/2b5jzzpMasCfqTwUjxbc1 4IAGT07pTCEo7NpcwtIWfzsd/wMRi/4px+AnjuEdqfXeL+C+rvFKEdC8dDRVga/jvXx1 IFCzaCKHlfNu4mAZMkKv9Vv9GA95oVUvNQI9wsXpbrQf0EVPiGCRgb1OTwJdQxxVcriH XgkRAYFqWO3sjPeZVZhdLlNOhEhpcocxjRCrDWXoeZxieaw9u6fSEW5UIDRjGeJrP+Q7 omjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=cU+hvH+MyU8hUb39HjBeFn3jkAFnKEO7edBRkvivwjQ=; b=fjRwZ665SZ9aWTOdiEC4/1d0WilObhvhbtYS8YaM70kz+cXad6mLgjMzFwZFKslo9Y MsLvvhLOxmxEUwlPPhr1HoVw4HHgsFo0xCVqHRXJzHUFccgu4+0rKpgYxlljKit/fcZW LxEGaXGGf5a4MejOhhbJcD2DI9PBKILmx+VK88Gb3WfF/VeF/kqYW01mArGivQ6xbwgP 0w0AtMDC7H4OadkOcsGOkuk6WFXSemat6RW432YDM8m3Fw0uQsRs/o/VNenwNgEPTnp6 MgHRPlQ+CCPXqNbF6M6GQNnA3BYgGl+7/xZ5oFsjhtBA/FP5Ozv4KLR3mDLoB6JIuKVo qQBA== X-Gm-Message-State: AODbwcCkLHC57zjA0KM3lT7wrWJGvt1Pu9wG49KAPUPlhqTnWT5O1ea5 aMraejMaM+m+P+yEwyDX7gpjxdSWDzXdXxQ= X-Received: by 10.176.79.133 with SMTP id m5mr71553uah.62.1494971469816; Tue, 16 May 2017 14:51:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.49.18 with HTTP; Tue, 16 May 2017 14:50:49 -0700 (PDT) From: Bernard Aboba Date: Tue, 16 May 2017 14:50:49 -0700 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="f403043eb7e86868ff054fab2bae" Archived-At: Subject: [rtcweb] Comments on draft-ietf-rtcweb-fec-04 (Opus FEC) 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, 16 May 2017 21:56:26 -0000 --f403043eb7e86868ff054fab2bae Content-Type: text/plain; charset="UTF-8" Section 3.3 For Opus, packets deemed as important are re-encoded at a lower bitrate and added to the subsequent packet, allowing partial recovery of a lost packet. This scheme is fairly efficient; experiments performed indicate that when Opus FEC is used, the overhead imposed is about 20-30%, depending on the amount of protection needed. Note that this mechanism can only carry redundancy information for the immediately preceding packet; as such the decoder cannot fully recover multiple consecutive lost packets, which can be a problem on wireless networks. See [RFC6716], Section 2.1.7 for complete details. Section 4.1 When using the Opus codec, use of the built-in Opus FEC mechanism is RECOMMENDED. This provides reasonable protection of the audio stream against typical losses, with modest overhead. Note that as indicated above the built-in Opus FEC only provides single-frame redundancy; if multi-packet protection is needed, the built-in FEC should be combined with [RFC2198 ] redundancy to protect the N-2th, N-3rd, etc. packets. [BA] While loss of a single packet is by far the most likely loss mode, our tests do not indicate that there is much benefit from Opus internal FEC. For example, when we compared Opus internal FEC against no FEC and concealment, we found little discernible difference in MOS score. On the other hand, we did see a benefit arising from RFC 2198 redundancy to protect against burst loss. So based on our test results, we cannot recommend use of built-in Opus FEC. --f403043eb7e86868ff054fab2bae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Section 3.3

   For Opus, packets deemed as important are re-encoded at a lower
   bitrate and added to the subsequent packet, allowing partial recovery
   of a lost packet.  This scheme is fairly efficient; experiments
   performed indicate that when Opus FEC is used, the overhead imposed
   is about 20-30%, depending on the amount of protection needed.  Note
   that this mechanism can only carry redundancy information for the
   immediately preceding packet; as such the decoder cannot fully
   recover multiple consecutive lost packets, which can be a problem on
   wireless networks.  See [RFC6716], Section=C2=A02.1.7 for complete
   details.

Section 4.1

=

   When using the=
 Opus codec, use of the built-in Opus FEC mechanism is
   RECOMMENDED.  This provides reasonable protection of the audio stream
   against typical losses, with modest overhead.  Note that as indicated
   above the built-in Opus FEC only provides single-frame redundancy; if
   multi-packet protection is needed, the built-in FEC should be
   combined with [RFC2198] redundancy t=
o protect the N-2th, N-3rd, etc.
   packets.

[BA] While loss of a single packet is by far the =
most likely loss
mode, our tests do =
not indicate that there is much benefit from
Opus internal FEC.  For example, when we compared Opus internal
FEC against no FEC and concealment, we=
 found little discernible
difference=
 in MOS score. On the other hand, we did see a benefit
arising from RFC 2198 redundancy to protect against burs=
t loss.
So based on our test results=
, we cannot recommend use of built-in
Opus FEC.
--f403043eb7e86868ff054fab2bae-- From nobody Thu May 18 07:18:39 2017 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 8299212EAB8 for ; Thu, 18 May 2017 07:18: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, 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=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 q4OHDRniZ9NZ for ; Thu, 18 May 2017 07:18:35 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001: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 28E8412EAC0 for ; Thu, 18 May 2017 07:13:00 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id k91so29245426ioi.1 for ; Thu, 18 May 2017 07:13:00 -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=/6OcuArrwGZ9wnpmFJLAyeGgUSECNZ/BUzFmgnpCYPY=; b=HoHxB09SsVyi/vzhyjfxklz9KPOA02qTh/gWAB2pEUyFL7SSRB+eUFZie2tA9N4MHU MrRq3JGP/8LGK+6oOetrbX9NGXtVvewncytEe1aVQjDheSSETD2xgGPkrXd55x0Ic4kR 64mk2IzZQrBG+Xpk/w6umL/lncwdLyBH4rPM8= 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=/6OcuArrwGZ9wnpmFJLAyeGgUSECNZ/BUzFmgnpCYPY=; b=HJNrGxh0hlLoA6qtXZ680AWCV/rgYKWZoo8FAASK68qdXRaZbuBqXuVLzCHomW2WF6 ltJVIOt0GS19zaogpBDPDxLrS4yB5Jr382S+jPUNcowc+Ffsex2zq+Mx7llraB/KxNRz 6lw7Lw+zitk8nMyUqeWYWKkYqvPPM6fTraOSN/n7eC7mNsQ6pCd1lQruXbReG9OAhrMv ZI0rX0pMkUMX//9671i69IDiqZNIhD6hNSp4GoGFzDA5b7itrhtybiT7NpuJ2Qe52zL0 NNr6a4bBMQMUVNgCKVmxYVz3NvDNDVA27R3XLr9XPcooMh6NQBEvw50dXVucfhzD1dIr 4jCg== X-Gm-Message-State: AODbwcALKZnuUhmarTrxNnN6XY/BIQPx4m5ZhUn65Uc7gr18yeMwOHQM JMxHVw5sRJhld7bKU1QNOw== X-Received: by 10.107.128.216 with SMTP id k85mr4609917ioi.115.1495116779220; Thu, 18 May 2017 07:12:59 -0700 (PDT) Received: from [5.5.33.138] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id b62sm2621580itc.16.2017.05.18.07.12.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 May 2017 07:12:58 -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 10.3 \(3273\)) Message-Id: <4C1F0FE7-F7E6-47F7-922D-057E4E7FA466@sn3rd.com> Date: Thu, 18 May 2017 10:12:53 -0400 To: RTCWeb IETF X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [rtcweb] Referring to 5245bis or 5245? 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, 18 May 2017 14:18:36 -0000 ekr=E2=80=99s discuss on draft-ietf-rtcweb-overview has raised whether = drafts should refer to RFC 5245 or draft-ietf-ice-rfc5245bis. We only = need to normatively refer to 5245bis if a technical part of 5245bis = needs to be read and implemented in order to implement the referring = draft. We have 7 drafts that refer to RFC 5245 and 2 that refer to = draft-ietf-rfc5245bis: draft-ietf-rtcweb-overview: As noted in my response to ekr=E2=80=99s = discuss position [0], the chairs believe that the reference to =E2=80=9CIC= E=E2=80=9D in the ICE Agent definition should be to RFC 5245. draft-ietf-rtcweb-transports: Likewise, the chairs believer that a = reference to RFC 5245 is also appropriate in transports. This draft was = changed in version -17 to refer to 5245bis. =46rom GH: "The drafts = -bundle and -dualstack-fairness both depend on 5245bis according to = Cullen's chart in 'rtcweb-deps-13', and we already have a normative = dependency from -transport on these. So consistency of the bundle is = improved by referencing 5245bis." spt [0] = https://mailarchive.ietf.org/arch/msg/rtcweb/GWdXRIO68FZwVtzzqugnELKeaY8= From nobody Thu May 18 08:00:08 2017 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 35A3112EBA9 for ; Thu, 18 May 2017 08:00:06 -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 E9TqwAZL18hl for ; Thu, 18 May 2017 08:00:04 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 5E36D12E85E for ; Thu, 18 May 2017 07:54:29 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id b84so204834700wmh.0 for ; Thu, 18 May 2017 07:54:29 -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=qM572Ct4b1/tmAczPYt1NcNFSi1lfNUx5TmbI6PxRdM=; b=n6TO8bKah6Ugn79DitK5rmhckf4dsyZ0c+tBtmuP/Bp7SxI8cLzRHnlRhjryc+jrYl WbU6k5bHvjL3d8PBZ3qUP7AsZfbQD+LtHjAkoCer2Hr8jICKNnmCZw/yhyfDAgTgJ8Cx Bniy+yyRKsKToeRqqxvpByKzEEqV8nSl76i2YHRahGd6s9tWXB0eh5kiwyMZ+G4BcjGO GFB+kaBMO8hmZPU9sewFqtueztroohR2u4obQzcwRoTBnVRcsN+1CWHVV+Ku09Nr65j7 ct23SJMIkPDeHW9SbcfooSPGk0WL4S1N7xID2kXUekIHSM0dP06uUH/yOe58/LO23+1Q 6nEQ== 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=qM572Ct4b1/tmAczPYt1NcNFSi1lfNUx5TmbI6PxRdM=; b=lFjUD7F1R+ONqkC3uVqxAR4b7xE05C/Hn8OvBMhi74AF/aQRgdndTbln9/TnP46soC /xtzcqRDFof6Jhflk+dJUfSxwOwFjn7moCnzJ8osqhqiz3g5tqA9axganiYNDFTn22l/ mp0ccFRS0QFgKm6/YkAlmSi/0DdQgcofE6ZTj0yrM9LkdBSBKsevx0SjiPFpJp69LiQL 9VqJLuaSmT6J+cqwbyheVNOLbrN18Oz8YpbdTdMJDMgpgLIseUAt3UtZTc0RkY7BVm9p 7Tn5czYNIuiZhAkKB4H75PagM8LpN6/szw4CP9Ks5+1A3JFji4faI18dYYigLZMwZSI7 YOlQ== X-Gm-Message-State: AODbwcBiWvXYLDbrKS8cvdMBLrlshY+i9Qc6mRz7R+Lp+cXxdQTlmTLe YcRt25CxG1OcZA2MMdri7aF/NFaeT71HTMY= X-Received: by 10.25.148.20 with SMTP id w20mr1043429lfd.169.1495119267884; Thu, 18 May 2017 07:54:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.75.9 with HTTP; Thu, 18 May 2017 07:54:27 -0700 (PDT) In-Reply-To: <4C1F0FE7-F7E6-47F7-922D-057E4E7FA466@sn3rd.com> References: <4C1F0FE7-F7E6-47F7-922D-057E4E7FA466@sn3rd.com> From: Martin Thomson Date: Thu, 18 May 2017 10:54:27 -0400 Message-ID: To: Sean Turner Cc: RTCWeb IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Referring to 5245bis or 5245? 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, 18 May 2017 15:00:06 -0000 I'm really confused about the statement regarding -transports. You say that 5245 is sufficient, then follow with justification for the opposite position. If we have as large a dependency as bundle that refers to 5245bis, then we are taking a transitive dependency on 5245bis and might as well refer to that. A lot of this comes down to what bundle says. Now, I see that bundle depends on both 5245 and its -bis, which seems pretty inconsistent. I don't immediately see any strong reason for bundle to refer to the -bis, though it does refer to the ice-sip-sdp draft, which might be sufficiently implicated as to make the change necessary. We should ask Christer to confirm this. I think that if we clarify that either way, then the reference in -dualstack-fairness seems less of a concern; that document doesn't need to reference 5245bis, though it would be nice if it could. On 18 May 2017 at 10:12, Sean Turner wrote: > ekr=E2=80=99s discuss on draft-ietf-rtcweb-overview has raised whether dr= afts should refer to RFC 5245 or draft-ietf-ice-rfc5245bis. We only need t= o normatively refer to 5245bis if a technical part of 5245bis needs to be r= ead and implemented in order to implement the referring draft. We have 7 d= rafts that refer to RFC 5245 and 2 that refer to draft-ietf-rfc5245bis: > > draft-ietf-rtcweb-overview: As noted in my response to ekr=E2=80=99s disc= uss position [0], the chairs believe that the reference to =E2=80=9CICE=E2= =80=9D in the ICE Agent definition should be to RFC 5245. > > draft-ietf-rtcweb-transports: Likewise, the chairs believer that a refere= nce to RFC 5245 is also appropriate in transports. This draft was changed = in version -17 to refer to 5245bis. From GH: "The drafts -bundle and -dual= stack-fairness both depend on 5245bis according to Cullen's chart in 'rtcwe= b-deps-13', and we already have a normative dependency from -transport on t= hese. So consistency of the bundle is improved by referencing 5245bis." > > spt > > [0] https://mailarchive.ietf.org/arch/msg/rtcweb/GWdXRIO68FZwVtzzqugnELKe= aY8 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu May 18 08:40:56 2017 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 81579129AD2 for ; Thu, 18 May 2017 08:40:54 -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=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 zr5htd7OwWOZ for ; Thu, 18 May 2017 08:40:52 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001: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 5AF94129B05 for ; Thu, 18 May 2017 08:35:22 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id f102so30695203ioi.2 for ; Thu, 18 May 2017 08:35:22 -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=Z2egWPjGX34bLF9rO0wocGUyLsla9CP2cJdW24WeUbw=; b=U0VeMYOZQpi8ZWDl6E40dBbZeTYkFXigYxDFOXJUz3WqeOriG04NP0tPR7VWrjRlI4 A963o8GpcYWgNpm5hsAtddFwjM2iEE48eU6e193wi8gEj4qy3hCs5aU/WYnCAod/HI82 1LYXuYn0mgdo77upl20INooblFSdELzmwQMwE= 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=Z2egWPjGX34bLF9rO0wocGUyLsla9CP2cJdW24WeUbw=; b=JPJiDWsyml/HXxpSEofsfUVSCptx1sClQeHOa1S72YD4qYyYV1y2vNThmKr9Vgl5/y jWqzN/byVJUceHZxi1qNC7f7AJ1V13z6K4m7m0IGiUksHc1ou9LI/Doth45JHMIil4bp rQ3rXr+wkbsI6rgi/o/ofhm+r+hFvheZzTpfhUI8csVYy3jl2qLmwfuu9hdU8RF+bN57 YlX+9dd7s9Dt+QaHRwy3yaplDubOCGr+g1CDqkQ5lDFoXldvUdxpIe96EU6MIvDnRxnS uY2nOb6cB2KYIpoct4LYQIBvO3sLX8DpHVqlOPqit0/1jEUzc+tqEIJp9frS5iVsodcZ bvNA== X-Gm-Message-State: AODbwcDHgZ8uGxTn0/xSfZkF6osbG77Z9vnKWZy9JSI2ERBrI+mFwWBx n8SyehcQwvjwl2nM X-Received: by 10.107.130.25 with SMTP id e25mr4800321iod.31.1495121721728; Thu, 18 May 2017 08:35:21 -0700 (PDT) Received: from [5.5.33.138] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id i73sm1863442ioi.55.2017.05.18.08.35.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 May 2017 08:35:20 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: Date: Thu, 18 May 2017 11:35:15 -0400 Cc: RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <3CC0A416-5A81-46FA-886C-5F43BA5193A6@sn3rd.com> References: <4C1F0FE7-F7E6-47F7-922D-057E4E7FA466@sn3rd.com> To: Martin Thomson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [rtcweb] Referring to 5245bis or 5245? 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, 18 May 2017 15:40:54 -0000 > On May 18, 2017, at 10:54, Martin Thomson = wrote: >=20 > I'm really confused about the statement regarding -transports. You > say that 5245 is sufficient, then follow with justification for the > opposite position. Sorry the change from 5425 to 5245bis was included in the latest version = using that rationale. This shows to me that it was =E2=80=9Cnice=E2=80=9D= to get alignment and point to 5245bis not that it is necessary to point = 5245. I.e., it=E2=80=99d be just fine to switch it back to referring to = 5245. > If we have as large a dependency as bundle that refers to 5245bis, > then we are taking a transitive dependency on 5245bis and might as > well refer to that. >=20 > A lot of this comes down to what bundle says. Now, I see that bundle > depends on both 5245 and its -bis, which seems pretty inconsistent. I > don't immediately see any strong reason for bundle to refer to the > -bis, though it does refer to the ice-sip-sdp draft, which might be > sufficiently implicated as to make the change necessary. We should > ask Christer to confirm this. >=20 > I think that if we clarify that either way, then the reference in > -dualstack-fairness seems less of a concern; that document doesn't > need to reference 5245bis, though it would be nice if it could. Exactly! spt > On 18 May 2017 at 10:12, Sean Turner wrote: >> ekr=E2=80=99s discuss on draft-ietf-rtcweb-overview has raised = whether drafts should refer to RFC 5245 or draft-ietf-ice-rfc5245bis. = We only need to normatively refer to 5245bis if a technical part of = 5245bis needs to be read and implemented in order to implement the = referring draft. We have 7 drafts that refer to RFC 5245 and 2 that = refer to draft-ietf-rfc5245bis: >>=20 >> draft-ietf-rtcweb-overview: As noted in my response to ekr=E2=80=99s = discuss position [0], the chairs believe that the reference to =E2=80=9CIC= E=E2=80=9D in the ICE Agent definition should be to RFC 5245. >>=20 >> draft-ietf-rtcweb-transports: Likewise, the chairs believer that a = reference to RFC 5245 is also appropriate in transports. This draft was = changed in version -17 to refer to 5245bis. =46rom GH: "The drafts = -bundle and -dualstack-fairness both depend on 5245bis according to = Cullen's chart in 'rtcweb-deps-13', and we already have a normative = dependency from -transport on these. So consistency of the bundle is = improved by referencing 5245bis." >>=20 >> spt >>=20 >> [0] = https://mailarchive.ietf.org/arch/msg/rtcweb/GWdXRIO68FZwVtzzqugnELKeaY8 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu May 18 08:43:13 2017 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 37D2A129AE7 for ; Thu, 18 May 2017 08:43:12 -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=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 kOqDoKfqAEcA for ; Thu, 18 May 2017 08:43:10 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 62135124BFA for ; Thu, 18 May 2017 08:37:54 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id a10so20637680itg.1 for ; Thu, 18 May 2017 08:37:54 -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=kY7C/QV2XxM7rTM/hG8XYxdM8WWz/cdaIsilRSPf5KI=; b=hFBW54DXgT03JeXnzW7yT0eBU7S/w35XPRiKg7KXKbhFGD4ab2CLaDJ4e1hz8ZYrfM lbwBqeTULfOLUCCsJ8P0ayTD7njx2aPkVc7ZusIS/r0yLGOp7fNcZHMSs9bJqbKcJGVC oWlKjIT50tHqdBsVR9I9ockm7eZGqz9RX9z7g= 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=kY7C/QV2XxM7rTM/hG8XYxdM8WWz/cdaIsilRSPf5KI=; b=Guk8wacnhyavNOsrYZuWINixfgXyg0dD6HMrmBOfl+sLDbt53e/QHpcwlO+rjTm9y0 drSQTxP7NZVwsl7hhOlRIW1UtsSvCdxIYLiQQNb7cfKPwcCoW2/A7zihrZftnnEgr/NN JysbJYziL0pWdI/95GJ6tV/jJKO+17SwamMs5KwjgXnrs6ACTIJRxJS8MSjVX+WuWrbA ZRbg/rj2MtAxSbjg8FqulDxP+PRW+iqeUNDX1rbD+6x3uIMhdt+I0RxuzPXZ0aicBnIZ fH9BK4CdIafD/cjqvFD2dzyk8Yx3HTGGcPULzlrL3w9Iu+Flp68YJrdEHIdkWehnW621 aUPA== X-Gm-Message-State: AODbwcDUxi8bDZV1AnIW0W4Ilzs8OhxHGbiz/lvskbntN0sCJ2egxJ7D gYoIkXkbh/M8PFOY X-Received: by 10.36.73.131 with SMTP id e3mr22874156itd.0.1495121872887; Thu, 18 May 2017 08:37:52 -0700 (PDT) Received: from [5.5.33.138] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id 9sm8823749itm.12.2017.05.18.08.37.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 May 2017 08:37:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: <3CC0A416-5A81-46FA-886C-5F43BA5193A6@sn3rd.com> Date: Thu, 18 May 2017 11:37:49 -0400 Cc: RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <6BD64B92-4DE2-4BAD-A23D-65E8F52E13B0@sn3rd.com> References: <4C1F0FE7-F7E6-47F7-922D-057E4E7FA466@sn3rd.com> <3CC0A416-5A81-46FA-886C-5F43BA5193A6@sn3rd.com> To: Martin Thomson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [rtcweb] Referring to 5245bis or 5245? 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, 18 May 2017 15:43:12 -0000 > On May 18, 2017, at 11:35, Sean Turner wrote: >=20 >=20 >> On May 18, 2017, at 10:54, Martin Thomson = wrote: >>=20 >> I'm really confused about the statement regarding -transports. You >> say that 5245 is sufficient, then follow with justification for the >> opposite position. >=20 > Sorry the change from 5425 to 5245bis was included in the latest = version using that rationale. This shows to me that it was =E2=80=9Cnice=E2= =80=9D to get alignment and point to 5245bis not that it is necessary to = point 5245. I.e., it=E2=80=99d be just fine to switch it back to = referring to 5245. Whoops: This shows to me that it was =E2=80=9Cnice=E2=80=9D to get alignment and = point to 5245bis not that it is necessary to point 5245bis. I.e., = it=E2=80=99d be just fine to switch it back to referring to 5245. >> If we have as large a dependency as bundle that refers to 5245bis, >> then we are taking a transitive dependency on 5245bis and might as >> well refer to that. >>=20 >> A lot of this comes down to what bundle says. Now, I see that bundle >> depends on both 5245 and its -bis, which seems pretty inconsistent. = I >> don't immediately see any strong reason for bundle to refer to the >> -bis, though it does refer to the ice-sip-sdp draft, which might be >> sufficiently implicated as to make the change necessary. We should >> ask Christer to confirm this. >>=20 >> I think that if we clarify that either way, then the reference in >> -dualstack-fairness seems less of a concern; that document doesn't >> need to reference 5245bis, though it would be nice if it could. >=20 > Exactly! >=20 > spt >=20 >> On 18 May 2017 at 10:12, Sean Turner wrote: >>> ekr=E2=80=99s discuss on draft-ietf-rtcweb-overview has raised = whether drafts should refer to RFC 5245 or draft-ietf-ice-rfc5245bis. = We only need to normatively refer to 5245bis if a technical part of = 5245bis needs to be read and implemented in order to implement the = referring draft. We have 7 drafts that refer to RFC 5245 and 2 that = refer to draft-ietf-rfc5245bis: >>>=20 >>> draft-ietf-rtcweb-overview: As noted in my response to ekr=E2=80=99s = discuss position [0], the chairs believe that the reference to =E2=80=9CIC= E=E2=80=9D in the ICE Agent definition should be to RFC 5245. >>>=20 >>> draft-ietf-rtcweb-transports: Likewise, the chairs believer that a = reference to RFC 5245 is also appropriate in transports. This draft was = changed in version -17 to refer to 5245bis. =46rom GH: "The drafts = -bundle and -dualstack-fairness both depend on 5245bis according to = Cullen's chart in 'rtcweb-deps-13', and we already have a normative = dependency from -transport on these. So consistency of the bundle is = improved by referencing 5245bis." >>>=20 >>> spt >>>=20 >>> [0] = https://mailarchive.ietf.org/arch/msg/rtcweb/GWdXRIO68FZwVtzzqugnELKeaY8 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Thu May 18 09:42:00 2017 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 38689129666 for ; Thu, 18 May 2017 09:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.821 X-Spam-Level: X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 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 JWXSucq1VrCC for ; Thu, 18 May 2017 09:41:55 -0700 (PDT) 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 DEE6812932A for ; Thu, 18 May 2017 09:34:20 -0700 (PDT) X-AuditID: c1b4fb25-73a9f9a0000055fe-da-591dcd0b3455 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 4D.4A.22014.B0DCD195; Thu, 18 May 2017 18:34:19 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0339.000; Thu, 18 May 2017 18:34:18 +0200 From: Christer Holmberg To: Martin Thomson , Sean Turner CC: RTCWeb IETF Thread-Topic: [rtcweb] Referring to 5245bis or 5245? Thread-Index: AQHSz+GnKDPh4DvzQUm5jwEPYC4blKH6DACAgAA15OA= Date: Thu, 18 May 2017 16:34:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CBA8F4F@ESESSMB109.ericsson.se> References: <4C1F0FE7-F7E6-47F7-922D-057E4E7FA466@sn3rd.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbFdRZf7rGykQd9hMYtrZ/4xWqz9185u cWVVI7MDs8fOWXfZPZYs+cnkcfAgYwBzFJdNSmpOZllqkb5dAlfGxOO32AqWiVVsv/+UsYHx jmgXIyeHhICJxMd3R9m7GLk4hASOMEo8enABylnCKPF4xXnmLkYODjYBC4nuf9ogDSIC3hKv 53xjAbGZBRQlviyfzwZiCwsYSzSu2cEOUWMicefPWkYI20pi+eqfYPUsAqoS8zffYwaxeQV8 JU5PbWeE2NXMKHG//yRYEadAoMSDHcvAihgFxCS+n1rDBLFMXOLWk/lMEFcLSCzZc54ZwhaV ePn4HyuErSSxYvslRpCbmQU0Jdbv0oe5c0r3Q3aIvYISJ2c+YZnAKDoLydRZCB2zkHTMQtKx gJFlFaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZg3Bzc8lt1B+PlN46HGAU4GJV4eGW3yUYK sSaWFVfmHmKU4GBWEuG9cgAoxJuSWFmVWpQfX1Sak1p8iFGag0VJnNdx34UIIYH0xJLU7NTU gtQimCwTB6dUA6NZTHzm76ztIRemMsorH9kw+8jrnqBwyczvj8R85KfOCffasPNfovGXRR84 kmaW3ZXhag5leqnb+aG07PodxVXafXZuWUWP7RPf6SgEr8neFXKeL8l0g1ib8J5yLqmCz1/v HKh5U2D0dNVt0TnJcs53VqpqHlv54/LmrdFMIWoW7mVx/117ZiqxFGckGmoxFxUnAgDOtPnX lwIAAA== Archived-At: Subject: Re: [rtcweb] Referring to 5245bis or 5245? 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, 18 May 2017 16:41:58 -0000 SGksDQoNCi4uLg0KDQo+QSBsb3Qgb2YgdGhpcyBjb21lcyBkb3duIHRvIHdoYXQgYnVuZGxlIHNh eXMuICBOb3csIEkgc2VlIHRoYXQgYnVuZGxlIGRlcGVuZHMgb24gYm90aCA1MjQ1IGFuZCBpdHMg LWJpcywgd2hpY2ggc2VlbXMgcHJldHR5IGluY29uc2lzdGVudC4gDQo+IEkgZG9uJ3QgaW1tZWRp YXRlbHkgc2VlIGFueSBzdHJvbmcgcmVhc29uIGZvciBidW5kbGUgdG8gcmVmZXIgdG8gdGhlIC1i aXMsIHRob3VnaCBpdCBkb2VzIHJlZmVyIHRvIHRoZSBpY2Utc2lwLXNkcCBkcmFmdCwgd2hpY2gg bWlnaHQgYmUgDQo+c3VmZmljaWVudGx5IGltcGxpY2F0ZWQgYXMgdG8gbWFrZSB0aGUgY2hhbmdl IG5lY2Vzc2FyeS4gIFdlIHNob3VsZCBhc2sgQ2hyaXN0ZXIgdG8gY29uZmlybSB0aGlzLg0KDQpJ IGRvbid0IHRoaW5rIEJVTkRMRSBhcyBzdWNoIHJlcXVpcmVzIDUyNDViaXMuIFRoZSByZWZlcmVu Y2VzIHRvIGljZS1zZHAtc2RwIGNvdWxkIGFsc28gYmUgcmVwbGFjZWQgd2l0aCBhIHJlZmVyZW5j ZSB0byA1MjQ1Lg0KDQpIb3dldmVyLCB0aGUgdGV4dCBpbiBzZWN0aW9uIDExLjEgc2F5czoNCg0K ICAgIldoZW4gYW4gb2ZmZXJlciBhc3NvY2lhdGVzIGEgc2hhcmVkIGFkZHJlc3Mgd2l0aCBhIGJ1 bmRsZWQgIm09IiBsaW5lLA0KICAgdGhlIG9mZmVyZXIgTVVTVCBhc3NvY2lhdGUgU0RQICdjYW5k aWRhdGUnIGF0dHJpYnV0ZXMgKGFuZCBvdGhlcg0KICAgYXBwbGljYWJsZSBJQ0UtcmVsYXRlZCBt ZWRpYS1sZXZlbCBTRFAgYXR0cmlidXRlcykgd2l0aCB0aGUgIm09IiBsaW5lDQogICBmb2xsb3dp bmcgdGhlIHByb2NlZHVyZXMgaW4gU2VjdGlvbiA4LjEuIg0KDQouLi5hbmQgbGF0ZXI6DQoNCiAg ICJOT1RFOiBUaGUgZm9sbG93aW5nIElDRS1yZWxhdGVkIG1lZGlhLWxldmVsIFNEUCBhdHRyaWJ1 dGVzIGFyZQ0KICAgZGVmaW5lZCBpbiBbSS1ELmlldGYtbW11c2ljLWljZS1zaXAtc2RwXTogJ2Nh bmRpZGlhdGUnLCAncmVtb3RlLQ0KICAgY2FuZGlkYXRlcycsICdpY2UtbWlzbWF0Y2gnLCAnaWNl LXVmcmFnJywgJ2ljZS1wd2QnLCBhbmQgJ2ljZS0NCiAgIHBhY2luZycuIg0KDQpUaGUgJ2ljZS1w YWNpbmcnIGF0dHJpYnV0ZSBkaWQgbm90IGV4aXN0IGluIDUyNDUsIHNvIGlmIHdlIGNoYW5nZSB0 aGUgcmVmZXJlbmNlIHdlIHdvdWxkIGhhdmUgdG8gcmVtb3ZlIHRoYXQuDQoNCj5JIHRoaW5rIHRo YXQgaWYgd2UgY2xhcmlmeSB0aGF0IGVpdGhlciB3YXksIHRoZW4gdGhlIHJlZmVyZW5jZSBpbiAt ZHVhbHN0YWNrLWZhaXJuZXNzIHNlZW1zIGxlc3Mgb2YgYSBjb25jZXJuOyB0aGF0IGRvY3VtZW50 DQo+ZG9lc24ndCBuZWVkIHRvIHJlZmVyZW5jZSA1MjQ1YmlzLCB0aG91Z2ggaXQgd291bGQgYmUg bmljZSBpZiBpdCBjb3VsZC4NCg0KSSB0aGluayB0aGUgZG9jdW1lbnQgcGVvcGxlIGhhdmUgYmVl biB0YWxraW5nIGFib3V0IGlzIGljZS10cmlja2xlLiBTb21lIHBlb3BsZSBzZWVtIHRvIHRoaW5r IHRoYXQgaXQgcmVxdWlyZXMgNTI0NWJpcy4NCg0KT2YgY291cnNlLCBieSByZWZlcmVuY2luZyA1 MjQ1IHdlIHdpbGwgc3RpbGwgaGF2ZSB0aGluZ3MgbGlrZSBhZ2dyZXNzaXZlIG5vbWluYXRpb24g YXJvdW5kLiBUaGF0IG9idmlvdXNseSBkb2Vzbid0IGJyZWFrIFJUQ1dFQiwgYnV0IEkgdW5kZXJz dG9vZCBSVENXRUIgd2FzIHRoZSBtYWluIHJlYXNvbiB3ZSB3YW50ZWQgdG8gZ2V0IHJpZCBvZiB0 aG9zZSB0aGluZ3MuLi4NCg0KQWxzbywgYXQgSUVURiM5NyB3ZSBhZ3JlZWQgb24gYSBudW1iZXIg b2YgdGhpbmdzIHRoYXQgd2lsbCBiZSBkZWZpbmVkIGluIGRyYWYtaWNlLXNkcC1zaXAsIGUuZy4s IHdoZW4gYSB0cmFuc3BvcnQgY2hhbmdlIHJlcXVpcmVzIGEgbmV3IG9mZmVyL2Fuc3dlciBleGNo YW5nZSwgbm9uLXN1cHBvcnRlZCBtLSBsaW5lcyBpbiBvZmZlcnMvYW5zd2VycyBldGMuIFRob3Nl IHRoaW5ncyBtYXkgbm90IGJlIGltcG9ydGFudCBmb3IgUlRDV0VCLCBidXQgdGhleSBjb3VsZCBi ZSBpbXBvcnRhbnQgZm9yIG90aGVyLCBTRFAgTy9BLXJlbGF0ZWQsIFJUQ1dFQiBkZXBlbmRlbmNp ZXMuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0K From nobody Thu May 18 09:56:27 2017 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 11764129B60 for ; Thu, 18 May 2017 09:56:26 -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 83Y6DYmQ25WG for ; Thu, 18 May 2017 09:56:23 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 4E0B412EB45 for ; Thu, 18 May 2017 09:50:35 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id p24so32439068ioi.0 for ; Thu, 18 May 2017 09:50:35 -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=yiG9M+RiypJP9HQHgiFBsQGSzRJ4ZXB6qzwvhBWjbQE=; b=gPFpLx6rgwyUiXN+xJeQ3WEV0j1RphhneyE1hWGHnd289O7tGWZ2kZji8nIIJVGLmi mlFtf4AptqaTDsKUnnVik5ajouEDxg+P4DMtxaV12qTqnSrUlMZiAm851iu1S6fDnFNc OtwnnLHGGuHkTv1NFrsO5vEffBVWkJE2dLaSwWZpuLteQz4rqh2JmANmxl7ShgMGh3M1 c5pLxDj+tJ+V5QBKRAoHqvFeYhyP3D7vkxoKnc0acbgR6bIojMI9+XXoyXK6vkz6SXVZ eVB8u8k4VxSUg2E6nDUhlCBW+cItWJSMr69NCkN7xiwpalbCAigaUjOtz4QSXv1yT91N XgbA== 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=yiG9M+RiypJP9HQHgiFBsQGSzRJ4ZXB6qzwvhBWjbQE=; b=tIsbEqjN3ZGddyGZx9HoROauqmts8sx/WMneYKyfuiPIHrYyZwA86nLeSIPNdQbsrx STbSANr2aIFJ7aOMQXOP257wZ+Xt/oyfXJEF34xbpn+CP3k7h+++EuUxv/0hjo3GUVqO Egzw4LcKGjmL/RVYbyvAIZwWTA/URC0mODQ6A6rrCHC2ShOR3VygtanFoHpQp0g5nDSv bM642b+6smAEEgWwquihE5T4sMh1rGFcVJ4BlceaBvhcklvoW35xKo0p7Fg9l/Wf6zTQ G17vd+LpDZj3qE3mcPc2o/wemtdcCwZWP48B8iqbXIDse71s3JQn2A7fCMXKkrT59i6x Gp7Q== X-Gm-Message-State: AODbwcACXMIkv6nmzZBBdxKnOaHTF4XAX7FXF/l+bj8pt4FunTup7I9I w0h7M19rZ3lIgSGtUgHVZIsV9YrT/qBLqGU= X-Received: by 10.107.35.75 with SMTP id j72mr5218098ioj.180.1495126234640; Thu, 18 May 2017 09:50:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.28.145 with HTTP; Thu, 18 May 2017 09:50:14 -0700 (PDT) In-Reply-To: <6BD64B92-4DE2-4BAD-A23D-65E8F52E13B0@sn3rd.com> References: <4C1F0FE7-F7E6-47F7-922D-057E4E7FA466@sn3rd.com> <3CC0A416-5A81-46FA-886C-5F43BA5193A6@sn3rd.com> <6BD64B92-4DE2-4BAD-A23D-65E8F52E13B0@sn3rd.com> From: Bernard Aboba Date: Thu, 18 May 2017 09:50:14 -0700 Message-ID: To: Sean Turner Cc: Martin Thomson , RTCWeb IETF Content-Type: multipart/alternative; boundary="001a1141b3621c5a1e054fcf340f" Archived-At: Subject: Re: [rtcweb] Referring to 5245bis or 5245? 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, 18 May 2017 16:56:26 -0000 --001a1141b3621c5a1e054fcf340f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sean said: "draft-ietf-rtcweb-transports: Likewise, the chairs believer that a reference to RFC 5245 is also appropriate in transports. This draft was changed in version -17 to refer to 5245bis. From GH: "The drafts -bundle and -dualstack-fairness both depend on 5245bis according to Cullen's chart in 'rtcweb-deps-13', and we already have a normative dependency from -transport on these. So consistency of the bundle is improved by referencing 5245bis.". [BA] draft-ietf-rtcweb-overview has a normative reference to draft-ietf-rtcweb-transports which has a normative reference to draft- ietf-ice-dualstack-fairness which in turn has a normative reference to draft-ietf-ice-rfc5245bis. So even if you remove the normative reference to RFC5245bis from overview and transports, publication of overview will still be held up until publication of RFC 5245bis, which will obsolete RFC 5245. On Thu, May 18, 2017 at 8:37 AM, Sean Turner wrote: > > > On May 18, 2017, at 11:35, Sean Turner wrote: > > > > > >> On May 18, 2017, at 10:54, Martin Thomson > wrote: > >> > >> I'm really confused about the statement regarding -transports. You > >> say that 5245 is sufficient, then follow with justification for the > >> opposite position. > > > > Sorry the change from 5425 to 5245bis was included in the latest versio= n > using that rationale. This shows to me that it was =E2=80=9Cnice=E2=80= =9D to get alignment > and point to 5245bis not that it is necessary to point 5245. I.e., it=E2= =80=99d be > just fine to switch it back to referring to 5245. > > Whoops: > > This shows to me that it was =E2=80=9Cnice=E2=80=9D to get alignment and = point to 5245bis > not that it is necessary to point 5245bis. I.e., it=E2=80=99d be just fi= ne to > switch it back to referring to 5245. > > >> If we have as large a dependency as bundle that refers to 5245bis, > >> then we are taking a transitive dependency on 5245bis and might as > >> well refer to that. > >> > >> A lot of this comes down to what bundle says. Now, I see that bundle > >> depends on both 5245 and its -bis, which seems pretty inconsistent. I > >> don't immediately see any strong reason for bundle to refer to the > >> -bis, though it does refer to the ice-sip-sdp draft, which might be > >> sufficiently implicated as to make the change necessary. We should > >> ask Christer to confirm this. > >> > >> I think that if we clarify that either way, then the reference in > >> -dualstack-fairness seems less of a concern; that document doesn't > >> need to reference 5245bis, though it would be nice if it could. > > > > Exactly! > > > > spt > > > >> On 18 May 2017 at 10:12, Sean Turner wrote: > >>> ekr=E2=80=99s discuss on draft-ietf-rtcweb-overview has raised whethe= r drafts > should refer to RFC 5245 or draft-ietf-ice-rfc5245bis. We only need to > normatively refer to 5245bis if a technical part of 5245bis needs to be > read and implemented in order to implement the referring draft. We have = 7 > drafts that refer to RFC 5245 and 2 that refer to draft-ietf-rfc5245bis: > >>> > >>> draft-ietf-rtcweb-overview: As noted in my response to ekr=E2=80=99s = discuss > position [0], the chairs believe that the reference to =E2=80=9CICE=E2=80= =9D in the ICE > Agent definition should be to RFC 5245. > >>> > >>> draft-ietf-rtcweb-transports: Likewise, the chairs believer that a > reference to RFC 5245 is also appropriate in transports. This draft was > changed in version -17 to refer to 5245bis. From GH: "The drafts -bundle > and -dualstack-fairness both depend on 5245bis according to Cullen's char= t > in 'rtcweb-deps-13', and we already have a normative dependency from > -transport on these. So consistency of the bundle is improved by > referencing 5245bis." > >>> > >>> spt > >>> > >>> [0] https://mailarchive.ietf.org/arch/msg/rtcweb/ > GWdXRIO68FZwVtzzqugnELKeaY8 > >>> _______________________________________________ > >>> 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 > --001a1141b3621c5a1e054fcf340f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sean said:=C2=A0

"draft-ietf-rtcweb-transports: Likewise, the chairs believe= r that a reference to RFC 5245 is also appropriate in transports.=C2=A0 Thi= s draft was changed in version -17 to refer to 5245bis.=C2=A0 From GH: &quo= t;The drafts -bundle and -dualstack-fairness both depend on 5245bis accordi= ng to Cullen's chart in 'rtcweb-deps-13', and we already have a= normative dependency from -transport on these.=C2=A0 So consistency of the= bundle is improved by referencing 5245bis.".

[BA] draft-ietf= -rtcweb-overview has a normative reference to draft-ietf-rtcweb-transports = which has a normative reference to draft-ietf-ice-dualstack-fairness=C2=A0which = in turn has a normative reference to draft-ietf-ice-rfc5245bis.=C2=A0 So even if you remove the normative referenc= e to RFC5245bis from overview and transports, publication of overview will = still be held up until publication of RFC 5245bis, which will obsolete RFC = 5245.=C2=A0

On Thu, May 18, 2017 at 8:37 AM, Sean Turner &l= t;sean@sn3rd.com>= ; wrote:

> On May 18, 2017, at 11:35, Sean Turner <sean@sn3rd.com> wrote:
>
>
>> On May 18, 2017, at 10:54, Martin Thomson <martin.thomson@gmail.com> wrote:
>>
>> I'm really confused about the statement regarding -transports.= =C2=A0 You
>> say that 5245 is sufficient, then follow with justification for th= e
>> opposite position.
>
> Sorry the change from 5425 to 5245bis was included in the latest versi= on using that rationale.=C2=A0 This shows to me that it was =E2=80=9Cnice= =E2=80=9D to get alignment and point to 5245bis not that it is necessary to= point 5245.=C2=A0 I.e., it=E2=80=99d be just fine to switch it back to ref= erring to 5245.

Whoops:

This shows to me that it was =E2=80=9Cnice=E2=80=9D to get alignment and po= int to 5245bis not that it is necessary to point 5245bis.=C2=A0 I.e., it=E2= =80=99d be just fine to switch it back to referring to 5245.

>> If we have as large a dependency as bundle that refers to 5245bis,=
>> then we are taking a transitive dependency on 5245bis and might as=
>> well refer to that.
>>
>> A lot of this comes down to what bundle says.=C2=A0 Now, I see tha= t bundle
>> depends on both 5245 and its -bis, which seems pretty inconsistent= .=C2=A0 I
>> don't immediately see any strong reason for bundle to refer to= the
>> -bis, though it does refer to the ice-sip-sdp draft, which might b= e
>> sufficiently implicated as to make the change necessary.=C2=A0 We = should
>> ask Christer to confirm this.
>>
>> I think that if we clarify that either way, then the reference in<= br> >> -dualstack-fairness seems less of a concern; that document doesn&#= 39;t
>> need to reference 5245bis, though it would be nice if it could. >
> Exactly!
>
> spt
>
>> On 18 May 2017 at 10:12, Sean Turner <sean@sn3rd.com> wrote:
>>> ekr=E2=80=99s discuss on draft-ietf-rtcweb-overview has raised= whether drafts should refer to RFC 5245 or draft-ietf-ice-rfc5245bis.=C2= =A0 We only need to normatively refer to 5245bis if a technical part of 524= 5bis needs to be read and implemented in order to implement the referring d= raft.=C2=A0 We have 7 drafts that refer to RFC 5245 and 2=C2=A0 that refer = to draft-ietf-rfc5245bis:
>>>
>>> draft-ietf-rtcweb-overview: As noted in my response to ekr=E2= =80=99s discuss position [0], the chairs believe that the reference to =E2= =80=9CICE=E2=80=9D in the ICE Agent definition should be to RFC 5245.
>>>
>>> draft-ietf-rtcweb-transports: Likewise, the chairs believer th= at a reference to RFC 5245 is also appropriate in transports.=C2=A0 This dr= aft was changed in version -17 to refer to 5245bis.=C2=A0 From GH: "Th= e drafts -bundle and -dualstack-fairness both depend on 5245bis according t= o Cullen's chart in 'rtcweb-deps-13', and we already have a nor= mative dependency from -transport on these.=C2=A0 So consistency of the bun= dle is improved by referencing 5245bis."
>>>
>>> spt
>>>
>>> [0] https://mai= larchive.ietf.org/arch/msg/rtcweb/GWdXRIO68FZwVtzzqugnELKeaY8=
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinf= o/rtcweb
>

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

--001a1141b3621c5a1e054fcf340f-- From nobody Thu May 18 10:09:43 2017 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 BA393129BCA for ; Thu, 18 May 2017 10:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, 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 uD8Sc3B9oIIY for ; Thu, 18 May 2017 10:09:40 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 6CE5A12778E for ; Thu, 18 May 2017 10:04:05 -0700 (PDT) X-AuditID: c1b4fb2d-1e1ff70000000d37-a2-591dd4017b5c Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id FE.85.03383.104DD195; Thu, 18 May 2017 19:04:03 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0339.000; Thu, 18 May 2017 19:04:01 +0200 From: Christer Holmberg To: Bernard Aboba , Sean Turner CC: RTCWeb IETF Thread-Topic: [rtcweb] Referring to 5245bis or 5245? Thread-Index: AQHSz+GnKDPh4DvzQUm5jwEPYC4blKH6DACAgAALZoCAAAC4gIAAFDsAgAAkh7A= Date: Thu, 18 May 2017 17:03:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CBA8FEF@ESESSMB109.ericsson.se> References: <4C1F0FE7-F7E6-47F7-922D-057E4E7FA466@sn3rd.com> <3CC0A416-5A81-46FA-886C-5F43BA5193A6@sn3rd.com> <6BD64B92-4DE2-4BAD-A23D-65E8F52E13B0@sn3rd.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CBA8FEFESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7hC7zFdlIg00rjC027PvPbLH2Xzu7 xZVVjcwOzB47Z91l91iy5CeTx8GDjAHMUVw2Kak5mWWpRfp2CVwZ51vmMResWsBYcfjtE7YG xo45jF2MnBwSAiYSv09PYwaxhQSOMEps/+jbxcgFZC9hlPjcOx0owcHBJmAh0f1PG6RGRMBT 4n7LeXYQm1lAUeLL8vlsILawgLFE45od7BA1JhJ3/qxlhLD9JFr/9LCAjGERUJV41xwDEuYV 8JXYfe0BM8SqDUwSRxqWMYEkOAUCJXpfLgGbySggJvH91BomiF3iEreezGeCuFlAYsme88wQ tqjEy8f/WCFsJYkV2y8xQtTnS7St/8MMsUxQ4uTMJywTGEVmIRk1C0nZLCRls4BOZRbQlFi/ S38W1JdTuh+yQ9gaEq1z5rIjiy9gZF/FKFqcWlycm25krJdalJlcXJyfp5eXWrKJERhpB7f8 1t3BuPq14yFGAQ5GJR7e5kuykUKsiWXFlbmHGCU4mJVEeL+cAwrxpiRWVqUW5ccXleakFh9i lOZgURLnddh3IUJIID2xJDU7NbUgtQgmy8TBKdXA6PwwjvHYQYdPTCJsdaLC5XfcLGf1T7zf M3VHdIaJ7nQ9jj0Hpz4pTeM0tK/MtIx4aM2dwbxFPmFL6oKKA0LrVybsvim93t5x/bxtvtVe W98GT8pw3zGTKbfh5dTGpL1fFmw7tPiZXgKz7s9QN643vXuCTOef0jLR9Vz+q9Ukp67j66QD HUxdSizFGYmGWsxFxYkAHGwiprACAAA= Archived-At: Subject: Re: [rtcweb] Referring to 5245bis or 5245? 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, 18 May 2017 17:09:43 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CBA8FEFESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkluIGdlbmVyYWwsIGlmIHBlb3BsZSBoYXZlIGlzc3VlcyB3aXRoIHJlZmVyZW5jaW5n IDUyNDViaXMgYmVjYXVzZSB0aGV5IGFyZSBhZnJhaWQgaXQgd2lsbCBob2xkIHVwIHB1YmxpY2F0 aW9uIG9mIFJUQ1dFQiBzcGVjcywgbm90ZSB0aGF0IEkgaGF2ZSBpbmRpY2F0ZWQgdG8gdGhlIElD RSBXRyBjaGFpcnMgdGhhdCBJIHRoaW5rIDUyNDViaXMgaXMgZ2V0dGluZyByZWFkeSBmb3IgV0dM Qy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2Vi LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCZXJuYXJkIEFib2JhDQpTZW50OiAxOCBN YXkgMjAxNyAxODo1MA0KVG86IFNlYW4gVHVybmVyIDxzZWFuQHNuM3JkLmNvbT4NCkNjOiBSVENX ZWIgSUVURiA8cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFJlZmVycmlu ZyB0byA1MjQ1YmlzIG9yIDUyNDU/DQoNClNlYW4gc2FpZDoNCg0KImRyYWZ0LWlldGYtcnRjd2Vi LXRyYW5zcG9ydHM6IExpa2V3aXNlLCB0aGUgY2hhaXJzIGJlbGlldmVyIHRoYXQgYSByZWZlcmVu Y2UgdG8gUkZDIDUyNDUgaXMgYWxzbyBhcHByb3ByaWF0ZSBpbiB0cmFuc3BvcnRzLiAgVGhpcyBk cmFmdCB3YXMgY2hhbmdlZCBpbiB2ZXJzaW9uIC0xNyB0byByZWZlciB0byA1MjQ1YmlzLiAgRnJv bSBHSDogIlRoZSBkcmFmdHMgLWJ1bmRsZSBhbmQgLWR1YWxzdGFjay1mYWlybmVzcyBib3RoIGRl cGVuZCBvbiA1MjQ1YmlzIGFjY29yZGluZyB0byBDdWxsZW4ncyBjaGFydCBpbiAncnRjd2ViLWRl cHMtMTMnLCBhbmQgd2UgYWxyZWFkeSBoYXZlIGEgbm9ybWF0aXZlIGRlcGVuZGVuY3kgZnJvbSAt dHJhbnNwb3J0IG9uIHRoZXNlLiAgU28gY29uc2lzdGVuY3kgb2YgdGhlIGJ1bmRsZSBpcyBpbXBy b3ZlZCBieSByZWZlcmVuY2luZyA1MjQ1YmlzLiIuDQpbQkFdIGRyYWZ0LWlldGYtcnRjd2ViLW92 ZXJ2aWV3IGhhcyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gZHJhZnQtaWV0Zi1ydGN3ZWItdHJh bnNwb3J0cyB3aGljaCBoYXMgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIGRyYWZ0LWlldGYtaWNl LWR1YWxzdGFjay1mYWlybmVzcyB3aGljaCBpbiB0dXJuIGhhcyBhIG5vcm1hdGl2ZSByZWZlcmVu Y2UgdG8gZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJpcy4gIFNvIGV2ZW4gaWYgeW91IHJlbW92ZSB0 aGUgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byBSRkM1MjQ1YmlzIGZyb20gb3ZlcnZpZXcgYW5kIHRy YW5zcG9ydHMsIHB1YmxpY2F0aW9uIG9mIG92ZXJ2aWV3IHdpbGwgc3RpbGwgYmUgaGVsZCB1cCB1 bnRpbCBwdWJsaWNhdGlvbiBvZiBSRkMgNTI0NWJpcywgd2hpY2ggd2lsbCBvYnNvbGV0ZSBSRkMg NTI0NS4NCg0KT24gVGh1LCBNYXkgMTgsIDIwMTcgYXQgODozNyBBTSwgU2VhbiBUdXJuZXIgPHNl YW5Ac24zcmQuY29tPG1haWx0bzpzZWFuQHNuM3JkLmNvbT4+IHdyb3RlOg0KDQo+IE9uIE1heSAx OCwgMjAxNywgYXQgMTE6MzUsIFNlYW4gVHVybmVyIDxzZWFuQHNuM3JkLmNvbTxtYWlsdG86c2Vh bkBzbjNyZC5jb20+PiB3cm90ZToNCj4NCj4NCj4+IE9uIE1heSAxOCwgMjAxNywgYXQgMTA6NTQs IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50 aG9tc29uQGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4NCj4+IEknbSByZWFsbHkgY29uZnVzZWQgYWJv dXQgdGhlIHN0YXRlbWVudCByZWdhcmRpbmcgLXRyYW5zcG9ydHMuICBZb3UNCj4+IHNheSB0aGF0 IDUyNDUgaXMgc3VmZmljaWVudCwgdGhlbiBmb2xsb3cgd2l0aCBqdXN0aWZpY2F0aW9uIGZvciB0 aGUNCj4+IG9wcG9zaXRlIHBvc2l0aW9uLg0KPg0KPiBTb3JyeSB0aGUgY2hhbmdlIGZyb20gNTQy NSB0byA1MjQ1YmlzIHdhcyBpbmNsdWRlZCBpbiB0aGUgbGF0ZXN0IHZlcnNpb24gdXNpbmcgdGhh dCByYXRpb25hbGUuICBUaGlzIHNob3dzIHRvIG1lIHRoYXQgaXQgd2FzIOKAnG5pY2XigJ0gdG8g Z2V0IGFsaWdubWVudCBhbmQgcG9pbnQgdG8gNTI0NWJpcyBub3QgdGhhdCBpdCBpcyBuZWNlc3Nh cnkgdG8gcG9pbnQgNTI0NS4gIEkuZS4sIGl04oCZZCBiZSBqdXN0IGZpbmUgdG8gc3dpdGNoIGl0 IGJhY2sgdG8gcmVmZXJyaW5nIHRvIDUyNDUuDQoNCldob29wczoNCg0KVGhpcyBzaG93cyB0byBt ZSB0aGF0IGl0IHdhcyDigJxuaWNl4oCdIHRvIGdldCBhbGlnbm1lbnQgYW5kIHBvaW50IHRvIDUy NDViaXMgbm90IHRoYXQgaXQgaXMgbmVjZXNzYXJ5IHRvIHBvaW50IDUyNDViaXMuICBJLmUuLCBp dOKAmWQgYmUganVzdCBmaW5lIHRvIHN3aXRjaCBpdCBiYWNrIHRvIHJlZmVycmluZyB0byA1MjQ1 Lg0KDQo+PiBJZiB3ZSBoYXZlIGFzIGxhcmdlIGEgZGVwZW5kZW5jeSBhcyBidW5kbGUgdGhhdCBy ZWZlcnMgdG8gNTI0NWJpcywNCj4+IHRoZW4gd2UgYXJlIHRha2luZyBhIHRyYW5zaXRpdmUgZGVw ZW5kZW5jeSBvbiA1MjQ1YmlzIGFuZCBtaWdodCBhcw0KPj4gd2VsbCByZWZlciB0byB0aGF0Lg0K Pj4NCj4+IEEgbG90IG9mIHRoaXMgY29tZXMgZG93biB0byB3aGF0IGJ1bmRsZSBzYXlzLiAgTm93 LCBJIHNlZSB0aGF0IGJ1bmRsZQ0KPj4gZGVwZW5kcyBvbiBib3RoIDUyNDUgYW5kIGl0cyAtYmlz LCB3aGljaCBzZWVtcyBwcmV0dHkgaW5jb25zaXN0ZW50LiAgSQ0KPj4gZG9uJ3QgaW1tZWRpYXRl bHkgc2VlIGFueSBzdHJvbmcgcmVhc29uIGZvciBidW5kbGUgdG8gcmVmZXIgdG8gdGhlDQo+PiAt YmlzLCB0aG91Z2ggaXQgZG9lcyByZWZlciB0byB0aGUgaWNlLXNpcC1zZHAgZHJhZnQsIHdoaWNo IG1pZ2h0IGJlDQo+PiBzdWZmaWNpZW50bHkgaW1wbGljYXRlZCBhcyB0byBtYWtlIHRoZSBjaGFu Z2UgbmVjZXNzYXJ5LiAgV2Ugc2hvdWxkDQo+PiBhc2sgQ2hyaXN0ZXIgdG8gY29uZmlybSB0aGlz Lg0KPj4NCj4+IEkgdGhpbmsgdGhhdCBpZiB3ZSBjbGFyaWZ5IHRoYXQgZWl0aGVyIHdheSwgdGhl biB0aGUgcmVmZXJlbmNlIGluDQo+PiAtZHVhbHN0YWNrLWZhaXJuZXNzIHNlZW1zIGxlc3Mgb2Yg YSBjb25jZXJuOyB0aGF0IGRvY3VtZW50IGRvZXNuJ3QNCj4+IG5lZWQgdG8gcmVmZXJlbmNlIDUy NDViaXMsIHRob3VnaCBpdCB3b3VsZCBiZSBuaWNlIGlmIGl0IGNvdWxkLg0KPg0KPiBFeGFjdGx5 IQ0KPg0KPiBzcHQNCj4NCj4+IE9uIDE4IE1heSAyMDE3IGF0IDEwOjEyLCBTZWFuIFR1cm5lciA8 c2VhbkBzbjNyZC5jb208bWFpbHRvOnNlYW5Ac24zcmQuY29tPj4gd3JvdGU6DQo+Pj4gZWty4oCZ cyBkaXNjdXNzIG9uIGRyYWZ0LWlldGYtcnRjd2ViLW92ZXJ2aWV3IGhhcyByYWlzZWQgd2hldGhl ciBkcmFmdHMgc2hvdWxkIHJlZmVyIHRvIFJGQyA1MjQ1IG9yIGRyYWZ0LWlldGYtaWNlLXJmYzUy NDViaXMuICBXZSBvbmx5IG5lZWQgdG8gbm9ybWF0aXZlbHkgcmVmZXIgdG8gNTI0NWJpcyBpZiBh IHRlY2huaWNhbCBwYXJ0IG9mIDUyNDViaXMgbmVlZHMgdG8gYmUgcmVhZCBhbmQgaW1wbGVtZW50 ZWQgaW4gb3JkZXIgdG8gaW1wbGVtZW50IHRoZSByZWZlcnJpbmcgZHJhZnQuICBXZSBoYXZlIDcg ZHJhZnRzIHRoYXQgcmVmZXIgdG8gUkZDIDUyNDUgYW5kIDIgIHRoYXQgcmVmZXIgdG8gZHJhZnQt aWV0Zi1yZmM1MjQ1YmlzOg0KPj4+DQo+Pj4gZHJhZnQtaWV0Zi1ydGN3ZWItb3ZlcnZpZXc6IEFz IG5vdGVkIGluIG15IHJlc3BvbnNlIHRvIGVrcuKAmXMgZGlzY3VzcyBwb3NpdGlvbiBbMF0sIHRo ZSBjaGFpcnMgYmVsaWV2ZSB0aGF0IHRoZSByZWZlcmVuY2UgdG8g4oCcSUNF4oCdIGluIHRoZSBJ Q0UgQWdlbnQgZGVmaW5pdGlvbiBzaG91bGQgYmUgdG8gUkZDIDUyNDUuDQo+Pj4NCj4+PiBkcmFm dC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzOiBMaWtld2lzZSwgdGhlIGNoYWlycyBiZWxpZXZlciB0 aGF0IGEgcmVmZXJlbmNlIHRvIFJGQyA1MjQ1IGlzIGFsc28gYXBwcm9wcmlhdGUgaW4gdHJhbnNw b3J0cy4gIFRoaXMgZHJhZnQgd2FzIGNoYW5nZWQgaW4gdmVyc2lvbiAtMTcgdG8gcmVmZXIgdG8g NTI0NWJpcy4gIEZyb20gR0g6ICJUaGUgZHJhZnRzIC1idW5kbGUgYW5kIC1kdWFsc3RhY2stZmFp cm5lc3MgYm90aCBkZXBlbmQgb24gNTI0NWJpcyBhY2NvcmRpbmcgdG8gQ3VsbGVuJ3MgY2hhcnQg aW4gJ3J0Y3dlYi1kZXBzLTEzJywgYW5kIHdlIGFscmVhZHkgaGF2ZSBhIG5vcm1hdGl2ZSBkZXBl bmRlbmN5IGZyb20gLXRyYW5zcG9ydCBvbiB0aGVzZS4gIFNvIGNvbnNpc3RlbmN5IG9mIHRoZSBi dW5kbGUgaXMgaW1wcm92ZWQgYnkgcmVmZXJlbmNpbmcgNTI0NWJpcy4iDQo+Pj4NCj4+PiBzcHQN Cj4+Pg0KPj4+IFswXSBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3J0Y3dl Yi9HV2RYUklPNjhGWndWdHp6cXVnbkVMS2VhWTgNCj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4+PiBy dGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2Vi QGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B4CBA8FEFESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5JbiBnZW5lcmFsLCBpZiBwZW9wbGUgaGF2ZSBpc3N1ZXMgd2l0aCBy ZWZlcmVuY2luZyA1MjQ1YmlzIGJlY2F1c2UgdGhleSBhcmUgYWZyYWlkIGl0IHdpbGwgaG9sZCB1 cCBwdWJsaWNhdGlvbiBvZiBSVENXRUIgc3BlY3MsIG5vdGUNCiB0aGF0IEkgaGF2ZSBpbmRpY2F0 ZWQgdG8gdGhlIElDRSBXRyBjaGFpcnMgdGhhdCBJIHRoaW5rIDUyNDViaXMgaXMgZ2V0dGluZyBy ZWFkeSBmb3IgV0dMQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJl Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3Rlcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWls RW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1i b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CZXJuYXJkIEFib2JhPGJyPg0K PGI+U2VudDo8L2I+IDE4IE1heSAyMDE3IDE4OjUwPGJyPg0KPGI+VG86PC9iPiBTZWFuIFR1cm5l ciAmbHQ7c2VhbkBzbjNyZC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBSVENXZWIgSUVURiAmbHQ7 cnRjd2ViQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gUmVm ZXJyaW5nIHRvIDUyNDViaXMgb3IgNTI0NT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5TZWFuIHNhaWQ6Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZxdW90OzxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS41cHQiPmRyYWZ0LWlldGYtcnRjd2ViLXRyYW5zcG9ydHM6IExpa2V3 aXNlLCB0aGUgY2hhaXJzIGJlbGlldmVyIHRoYXQgYSByZWZlcmVuY2UgdG8gUkZDIDUyNDUgaXMg YWxzbyBhcHByb3ByaWF0ZSBpbiB0cmFuc3BvcnRzLiZuYnNwOyBUaGlzIGRyYWZ0IHdhcyBjaGFu Z2VkIGluIHZlcnNpb24gLTE3IHRvIHJlZmVyIHRvIDUyNDViaXMuJm5ic3A7DQogRnJvbSBHSDog JnF1b3Q7VGhlIGRyYWZ0cyAtYnVuZGxlIGFuZCAtZHVhbHN0YWNrLWZhaXJuZXNzIGJvdGggZGVw ZW5kIG9uIDUyNDViaXMgYWNjb3JkaW5nIHRvIEN1bGxlbidzIGNoYXJ0IGluICdydGN3ZWItZGVw cy0xMycsIGFuZCB3ZSBhbHJlYWR5IGhhdmUgYSBub3JtYXRpdmUgZGVwZW5kZW5jeSBmcm9tIC10 cmFuc3BvcnQgb24gdGhlc2UuJm5ic3A7IFNvIGNvbnNpc3RlbmN5IG9mIHRoZSBidW5kbGUgaXMg aW1wcm92ZWQgYnkgcmVmZXJlbmNpbmcgNTI0NWJpcy4mcXVvdDsuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W0JBXSBkcmFmdC1pZXRm LXJ0Y3dlYi1vdmVydmlldyBoYXMgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIGRyYWZ0LWlldGYt cnRjd2ViLXRyYW5zcG9ydHMgd2hpY2ggaGFzIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byBkcmFm dC08YSBuYW1lPSJyZWYtSS1ELmlldGYtbW11c2ljLWljZS1kdWFsc3RhY2stZmFpcm5lIiBpZD0i Z21haWwtcmVmLUktRC5pZXRmLW1tdXNpYy1pY2UtZHVhbHN0YWNrLWZhaXJuZXNzIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+aWV0Zi1pY2UtZHVhbHN0YWNrLWZhaXJuZXNzPC9zcGFu PjwvYT4mbmJzcDt3aGljaA0KIGluIHR1cm4gaGFzIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byBk cmFmdC08YSBuYW1lPSJyZWYtSS1ELmlldGYtaWNlLXJmYzUyNDViaXMiIGlkPSJnbWFpbC1yZWYt SS1ELmlldGYtaWNlLXJmYzUyNDViaXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5p ZXRmLWljZS1yZmM1MjQ1YmlzLiZuYnNwOyBTbyBldmVuIGlmIHlvdSByZW1vdmUgdGhlIG5vcm1h dGl2ZSByZWZlcmVuY2UgdG8gUkZDNTI0NWJpcyBmcm9tIG92ZXJ2aWV3IGFuZCB0cmFuc3BvcnRz LA0KIHB1YmxpY2F0aW9uIG9mIG92ZXJ2aWV3IHdpbGwgc3RpbGwgYmUgaGVsZCB1cCB1bnRpbCBw dWJsaWNhdGlvbiBvZiBSRkMgNTI0NWJpcywgd2hpY2ggd2lsbCBvYnNvbGV0ZSBSRkMgNTI0NS4m bmJzcDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBUaHUsIE1heSAxOCwgMjAxNyBhdCA4OjM3IEFNLCBTZWFuIFR1cm5l ciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNlYW5Ac24zcmQuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2Vh bkBzbjNyZC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQomZ3Q7IE9uIE1heSAxOCwgMjAxNywgYXQgMTE6MzUs IFNlYW4gVHVybmVyICZsdDs8YSBocmVmPSJtYWlsdG86c2VhbkBzbjNyZC5jb20iPnNlYW5Ac24z cmQuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBP biBNYXkgMTgsIDIwMTcsIGF0IDEwOjU0LCBNYXJ0aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSI+bWFydGluLnRob21zb25AZ21haWwuY29tPC9h PiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJJ20gcmVhbGx5IGNvbmZ1 c2VkIGFib3V0IHRoZSBzdGF0ZW1lbnQgcmVnYXJkaW5nIC10cmFuc3BvcnRzLiZuYnNwOyBZb3U8 YnI+DQomZ3Q7Jmd0OyBzYXkgdGhhdCA1MjQ1IGlzIHN1ZmZpY2llbnQsIHRoZW4gZm9sbG93IHdp dGgganVzdGlmaWNhdGlvbiBmb3IgdGhlPGJyPg0KJmd0OyZndDsgb3Bwb3NpdGUgcG9zaXRpb24u PGJyPg0KJmd0Ozxicj4NCiZndDsgU29ycnkgdGhlIGNoYW5nZSBmcm9tIDU0MjUgdG8gNTI0NWJp cyB3YXMgaW5jbHVkZWQgaW4gdGhlIGxhdGVzdCB2ZXJzaW9uIHVzaW5nIHRoYXQgcmF0aW9uYWxl LiZuYnNwOyBUaGlzIHNob3dzIHRvIG1lIHRoYXQgaXQgd2FzIOKAnG5pY2XigJ0gdG8gZ2V0IGFs aWdubWVudCBhbmQgcG9pbnQgdG8gNTI0NWJpcyBub3QgdGhhdCBpdCBpcyBuZWNlc3NhcnkgdG8g cG9pbnQgNTI0NS4mbmJzcDsgSS5lLiwgaXTigJlkIGJlIGp1c3QgZmluZSB0byBzd2l0Y2ggaXQg YmFjayB0bw0KIHJlZmVycmluZyB0byA1MjQ1Ljxicj4NCjxicj4NCldob29wczo8YnI+DQo8YnI+ DQpUaGlzIHNob3dzIHRvIG1lIHRoYXQgaXQgd2FzIOKAnG5pY2XigJ0gdG8gZ2V0IGFsaWdubWVu dCBhbmQgcG9pbnQgdG8gNTI0NWJpcyBub3QgdGhhdCBpdCBpcyBuZWNlc3NhcnkgdG8gcG9pbnQg NTI0NWJpcy4mbmJzcDsgSS5lLiwgaXTigJlkIGJlIGp1c3QgZmluZSB0byBzd2l0Y2ggaXQgYmFj ayB0byByZWZlcnJpbmcgdG8gNTI0NS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJmd0OyZndDsgSWYgd2UgaGF2ZSBhcyBsYXJnZSBhIGRl cGVuZGVuY3kgYXMgYnVuZGxlIHRoYXQgcmVmZXJzIHRvIDUyNDViaXMsPGJyPg0KJmd0OyZndDsg dGhlbiB3ZSBhcmUgdGFraW5nIGEgdHJhbnNpdGl2ZSBkZXBlbmRlbmN5IG9uIDUyNDViaXMgYW5k IG1pZ2h0IGFzPGJyPg0KJmd0OyZndDsgd2VsbCByZWZlciB0byB0aGF0Ljxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgQSBsb3Qgb2YgdGhpcyBjb21lcyBkb3duIHRvIHdoYXQgYnVuZGxlIHNh eXMuJm5ic3A7IE5vdywgSSBzZWUgdGhhdCBidW5kbGU8YnI+DQomZ3Q7Jmd0OyBkZXBlbmRzIG9u IGJvdGggNTI0NSBhbmQgaXRzIC1iaXMsIHdoaWNoIHNlZW1zIHByZXR0eSBpbmNvbnNpc3RlbnQu Jm5ic3A7IEk8YnI+DQomZ3Q7Jmd0OyBkb24ndCBpbW1lZGlhdGVseSBzZWUgYW55IHN0cm9uZyBy ZWFzb24gZm9yIGJ1bmRsZSB0byByZWZlciB0byB0aGU8YnI+DQomZ3Q7Jmd0OyAtYmlzLCB0aG91 Z2ggaXQgZG9lcyByZWZlciB0byB0aGUgaWNlLXNpcC1zZHAgZHJhZnQsIHdoaWNoIG1pZ2h0IGJl PGJyPg0KJmd0OyZndDsgc3VmZmljaWVudGx5IGltcGxpY2F0ZWQgYXMgdG8gbWFrZSB0aGUgY2hh bmdlIG5lY2Vzc2FyeS4mbmJzcDsgV2Ugc2hvdWxkPGJyPg0KJmd0OyZndDsgYXNrIENocmlzdGVy IHRvIGNvbmZpcm0gdGhpcy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEkgdGhpbmsgdGhh dCBpZiB3ZSBjbGFyaWZ5IHRoYXQgZWl0aGVyIHdheSwgdGhlbiB0aGUgcmVmZXJlbmNlIGluPGJy Pg0KJmd0OyZndDsgLWR1YWxzdGFjay1mYWlybmVzcyBzZWVtcyBsZXNzIG9mIGEgY29uY2Vybjsg dGhhdCBkb2N1bWVudCBkb2Vzbid0PGJyPg0KJmd0OyZndDsgbmVlZCB0byByZWZlcmVuY2UgNTI0 NWJpcywgdGhvdWdoIGl0IHdvdWxkIGJlIG5pY2UgaWYgaXQgY291bGQuPGJyPg0KJmd0Ozxicj4N CiZndDsgRXhhY3RseSE8YnI+DQomZ3Q7PGJyPg0KJmd0OyBzcHQ8YnI+DQomZ3Q7PGJyPg0KJmd0 OyZndDsgT24gMTggTWF5IDIwMTcgYXQgMTA6MTIsIFNlYW4gVHVybmVyICZsdDs8YSBocmVmPSJt YWlsdG86c2VhbkBzbjNyZC5jb20iPnNlYW5Ac24zcmQuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0K Jmd0OyZndDsmZ3Q7IGVrcuKAmXMgZGlzY3VzcyBvbiBkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmll dyBoYXMgcmFpc2VkIHdoZXRoZXIgZHJhZnRzIHNob3VsZCByZWZlciB0byBSRkMgNTI0NSBvciBk cmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzLiZuYnNwOyBXZSBvbmx5IG5lZWQgdG8gbm9ybWF0aXZl bHkgcmVmZXIgdG8gNTI0NWJpcyBpZiBhIHRlY2huaWNhbCBwYXJ0IG9mIDUyNDViaXMgbmVlZHMg dG8gYmUgcmVhZCBhbmQgaW1wbGVtZW50ZWQgaW4gb3JkZXIgdG8gaW1wbGVtZW50DQogdGhlIHJl ZmVycmluZyBkcmFmdC4mbmJzcDsgV2UgaGF2ZSA3IGRyYWZ0cyB0aGF0IHJlZmVyIHRvIFJGQyA1 MjQ1IGFuZCAyJm5ic3A7IHRoYXQgcmVmZXIgdG8gZHJhZnQtaWV0Zi1yZmM1MjQ1YmlzOjxicj4N CiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmll dzogQXMgbm90ZWQgaW4gbXkgcmVzcG9uc2UgdG8gZWty4oCZcyBkaXNjdXNzIHBvc2l0aW9uIFsw XSwgdGhlIGNoYWlycyBiZWxpZXZlIHRoYXQgdGhlIHJlZmVyZW5jZSB0byDigJxJQ0XigJ0gaW4g dGhlIElDRSBBZ2VudCBkZWZpbml0aW9uIHNob3VsZCBiZSB0byBSRkMgNTI0NS48YnI+DQomZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgZHJhZnQtaWV0Zi1ydGN3ZWItdHJhbnNwb3J0czog TGlrZXdpc2UsIHRoZSBjaGFpcnMgYmVsaWV2ZXIgdGhhdCBhIHJlZmVyZW5jZSB0byBSRkMgNTI0 NSBpcyBhbHNvIGFwcHJvcHJpYXRlIGluIHRyYW5zcG9ydHMuJm5ic3A7IFRoaXMgZHJhZnQgd2Fz IGNoYW5nZWQgaW4gdmVyc2lvbiAtMTcgdG8gcmVmZXIgdG8gNTI0NWJpcy4mbmJzcDsgRnJvbSBH SDogJnF1b3Q7VGhlIGRyYWZ0cyAtYnVuZGxlIGFuZCAtZHVhbHN0YWNrLWZhaXJuZXNzIGJvdGgg ZGVwZW5kIG9uDQogNTI0NWJpcyBhY2NvcmRpbmcgdG8gQ3VsbGVuJ3MgY2hhcnQgaW4gJ3J0Y3dl Yi1kZXBzLTEzJywgYW5kIHdlIGFscmVhZHkgaGF2ZSBhIG5vcm1hdGl2ZSBkZXBlbmRlbmN5IGZy b20gLXRyYW5zcG9ydCBvbiB0aGVzZS4mbmJzcDsgU28gY29uc2lzdGVuY3kgb2YgdGhlIGJ1bmRs ZSBpcyBpbXByb3ZlZCBieSByZWZlcmVuY2luZyA1MjQ1YmlzLiZxdW90Ozxicj4NCiZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBzcHQ8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsgWzBdIDxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cv cnRjd2ViL0dXZFhSSU82OEZad1Z0enpxdWduRUxLZWFZOCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0 cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9ydGN3ZWIvR1dkWFJJTzY4Rlp3VnR6 enF1Z25FTEtlYVk4PC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyBydGN3ZWIgbWFpbGlu ZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmci PnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48YnI+DQomZ3Q7PGJy Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRm Lm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B4CBA8FEFESESSMB109erics_-- From nobody Mon May 22 15:52:39 2017 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 A181C129409 for ; Mon, 22 May 2017 15:52:31 -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_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 7W_Jbh0pq-WQ for ; Mon, 22 May 2017 15:52:30 -0700 (PDT) Received: from smtp73.iad3a.emailsrvr.com (smtp73.iad3a.emailsrvr.com [173.203.187.73]) (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 D31EA129407 for ; Mon, 22 May 2017 15:52:29 -0700 (PDT) Received: from smtp10.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp10.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 69D026472; Mon, 22 May 2017 18:52:25 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp10.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id CDE7E5D73; Mon, 22 May 2017 18:52:24 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.67] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Mon, 22 May 2017 18:52:25 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CBA8FEF@ESESSMB109.ericsson.se> Date: Mon, 22 May 2017 16:52:23 -0600 Cc: Sean Turner , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C1F0FE7-F7E6-47F7-922D-057E4E7FA466@sn3rd.com> <3CC0A416-5A81-46FA-886C-5F43BA5193A6@sn3rd.com> <6BD64B92-4DE2-4BAD-A23D-65E8F52E13B0@sn3rd.com> <7594FB04B1934943A5C02806D1A2204B4CBA8FEF@ESESSMB109.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [rtcweb] Referring to 5245bis or 5245? 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, 22 May 2017 22:52:31 -0000 Note that I don't think the timeline is the major issue (it is an issue) = ... they key issue is that 5245bis does not seem to be needed for any = technical reason by WebRTC. > On May 18, 2017, at 11:03 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 > =20 >=20 > In general, if people have issues with referencing 5245bis because = they are afraid it will hold up publication of RTCWEB specs, note that I = have indicated to the ICE WG chairs that I think 5245bis is getting = ready for WGLC. >=20 > =20 >=20 > Regards, >=20 > =20 >=20 > Christer >=20 > =20 >=20 > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard = Aboba > Sent: 18 May 2017 18:50 > To: Sean Turner > Cc: RTCWeb IETF > Subject: Re: [rtcweb] Referring to 5245bis or 5245? >=20 > =20 >=20 > Sean said:=20 >=20 > =20 >=20 > "draft-ietf-rtcweb-transports: Likewise, the chairs believer that a = reference to RFC 5245 is also appropriate in transports. This draft was = changed in version -17 to refer to 5245bis. =46rom GH: "The drafts = -bundle and -dualstack-fairness both depend on 5245bis according to = Cullen's chart in 'rtcweb-deps-13', and we already have a normative = dependency from -transport on these. So consistency of the bundle is = improved by referencing 5245bis.". >=20 > [BA] draft-ietf-rtcweb-overview has a normative reference to = draft-ietf-rtcweb-transports which has a normative reference to = draft-ietf-ice-dualstack-fairness which in turn has a normative = reference to draft-ietf-ice-rfc5245bis. So even if you remove the = normative reference to RFC5245bis from overview and transports, = publication of overview will still be held up until publication of RFC = 5245bis, which will obsolete RFC 5245.=20 >=20 > =20 >=20 > On Thu, May 18, 2017 at 8:37 AM, Sean Turner wrote: >=20 >=20 > > On May 18, 2017, at 11:35, Sean Turner wrote: > > > > > >> On May 18, 2017, at 10:54, Martin Thomson = wrote: > >> > >> I'm really confused about the statement regarding -transports. You > >> say that 5245 is sufficient, then follow with justification for the > >> opposite position. > > > > Sorry the change from 5425 to 5245bis was included in the latest = version using that rationale. This shows to me that it was =E2=80=9Cnice=E2= =80=9D to get alignment and point to 5245bis not that it is necessary to = point 5245. I.e., it=E2=80=99d be just fine to switch it back to = referring to 5245. >=20 > Whoops: >=20 > This shows to me that it was =E2=80=9Cnice=E2=80=9D to get alignment = and point to 5245bis not that it is necessary to point 5245bis. I.e., = it=E2=80=99d be just fine to switch it back to referring to 5245. >=20 >=20 > >> If we have as large a dependency as bundle that refers to 5245bis, > >> then we are taking a transitive dependency on 5245bis and might as > >> well refer to that. > >> > >> A lot of this comes down to what bundle says. Now, I see that = bundle > >> depends on both 5245 and its -bis, which seems pretty inconsistent. = I > >> don't immediately see any strong reason for bundle to refer to the > >> -bis, though it does refer to the ice-sip-sdp draft, which might be > >> sufficiently implicated as to make the change necessary. We should > >> ask Christer to confirm this. > >> > >> I think that if we clarify that either way, then the reference in > >> -dualstack-fairness seems less of a concern; that document doesn't > >> need to reference 5245bis, though it would be nice if it could. > > > > Exactly! > > > > spt > > > >> On 18 May 2017 at 10:12, Sean Turner wrote: > >>> ekr=E2=80=99s discuss on draft-ietf-rtcweb-overview has raised = whether drafts should refer to RFC 5245 or draft-ietf-ice-rfc5245bis. = We only need to normatively refer to 5245bis if a technical part of = 5245bis needs to be read and implemented in order to implement the = referring draft. We have 7 drafts that refer to RFC 5245 and 2 that = refer to draft-ietf-rfc5245bis: > >>> > >>> draft-ietf-rtcweb-overview: As noted in my response to ekr=E2=80=99s= discuss position [0], the chairs believe that the reference to = =E2=80=9CICE=E2=80=9D in the ICE Agent definition should be to RFC 5245. > >>> > >>> draft-ietf-rtcweb-transports: Likewise, the chairs believer that a = reference to RFC 5245 is also appropriate in transports. This draft was = changed in version -17 to refer to 5245bis. =46rom GH: "The drafts = -bundle and -dualstack-fairness both depend on 5245bis according to = Cullen's chart in 'rtcweb-deps-13', and we already have a normative = dependency from -transport on these. So consistency of the bundle is = improved by referencing 5245bis." > >>> > >>> spt > >>> > >>> [0] = https://mailarchive.ietf.org/arch/msg/rtcweb/GWdXRIO68FZwVtzzqugnELKeaY8 > >>> _______________________________________________ > >>> 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 >=20 > =20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue May 23 22:38:27 2017 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 2608A126B72; Tue, 23 May 2017 22:38:25 -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.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149560430512.28459.18017801020136502401@ietfa.amsl.com> Date: Tue, 23 May 2017 22:38:25 -0700 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-05.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: Wed, 24 May 2017 05:38:25 -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 of the IETF. Title : WebRTC Forward Error Correction Requirements Author : Justin Uberti Filename : draft-ietf-rtcweb-fec-05.txt Pages : 10 Date : 2017-05-23 Abstract: This document provides information and requirements for how Forward Error Correction (FEC) should be used by WebRTC applications. 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-fec-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-fec-05 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 Wed May 24 17:00:03 2017 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 6494C129C00 for ; Wed, 24 May 2017 17:00:01 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 L3XoMq_i5XuQ for ; Wed, 24 May 2017 16:59:59 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 BBB32129B44 for ; Wed, 24 May 2017 16:59:59 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id k91so127693851ioi.1 for ; Wed, 24 May 2017 16:59:59 -0700 (PDT) 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=oOlKF/8egnv2r1U58ugRlGEB3+dzW7P6Qh2AM95nI6c=; b=jrQ/i4PSsd/xoDupHuXSO9xe4C9mK1rjo1QAhDypbwUHzbcp0XfEUgwweZ00tga9wu jCs5itoVbPc6E6tHyE3aWyFq+UABuClID8h7BOw2xQsn5zd5uo353D0EW/SSvSOjXFoU FKKhPiUmGqvxeSYJ08VABqvAebs2YtzZTn2zlEnUc2RtrAJUqIEcRI3/XmNitA7PkxKX 94abjC21e88xfCWggmKrLnHfszkS7svZGdVVbXaBbBjzsORXZjMBvCq+HziirwfBGnX6 WYOzl9iGtHBAGmaPGGpktXaXbpsFLX81ehhzXykrTFmKYRUvMwCQ+Ul2Dmc9BhiQGUzC cp4Q== 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=oOlKF/8egnv2r1U58ugRlGEB3+dzW7P6Qh2AM95nI6c=; b=LnXVcw9tbcMJORPqfM6k6Makn2ledJ76hGd/7UCs8ydwLE4aCP+EEePPz6LGiJ/P1t A/aWlaIquHE6m31Bhgd9s+e8NLI4mrk/dhqR6W3W9t0USfeNsTHazraa1DzRYwrTioOD evJejWxnlxFCdh/gv83YZTwoB3jIlDhyl/ll0jNINZpuCIjSYCJKpzQeWweN5HCArpo0 0lybUqjDHZv1ZMO1bgY1UhI729ENBSFwAKZ+EmAmF6vimrYvK7TROvf26s342NwpHdHV XT8piTr3JsHD43Wy/fsWdUzQP1RAOrhiDUioDjmxF5cg0uylJ0312u259VoN/DifTvmZ MOng== X-Gm-Message-State: AODbwcAe+tFG35w/Xb2t+uUJMrbYgInJ31YmhU7rOY3bxDDKvjgsFLc9 GcrvNDY0rT4+IX1fkadofrYcctJZb4ix X-Received: by 10.107.184.9 with SMTP id i9mr33342692iof.153.1495670398822; Wed, 24 May 2017 16:59:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.11.149 with HTTP; Wed, 24 May 2017 16:59:38 -0700 (PDT) In-Reply-To: <149560430512.28459.18017801020136502401@ietfa.amsl.com> References: <149560430512.28459.18017801020136502401@ietfa.amsl.com> From: Justin Uberti Date: Wed, 24 May 2017 16:59:38 -0700 Message-ID: To: internet-drafts@ietf.org Cc: i-d-announce@ietf.org, "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c06d100d3b85005504de65c" Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-05.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: Thu, 25 May 2017 00:00:01 -0000 --94eb2c06d100d3b85005504de65c Content-Type: text/plain; charset="UTF-8" Note that is simply a version bump for freshness. On Tue, May 23, 2017 at 10:38 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 > of the IETF. > > Title : WebRTC Forward Error Correction Requirements > Author : Justin Uberti > Filename : draft-ietf-rtcweb-fec-05.txt > Pages : 10 > Date : 2017-05-23 > > Abstract: > This document provides information and requirements for how Forward > Error Correction (FEC) should be used by WebRTC applications. > > > 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-05 > https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-fec-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-fec-05 > > > 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 > --94eb2c06d100d3b85005504de65c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Note that is simply a version bump for freshness.

On Tue, May 23, 2017= at 10:38 PM, <internet-drafts@ietf.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
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 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 Forward Error Correction Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Just= in Uberti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-fec-05.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 := 2017-05-23

Abstract:
=C2=A0 =C2=A0This document provides information and requirements for how Fo= rward
=C2=A0 =C2=A0Error Correction (FEC) should be used by WebRTC applications.<= br>

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

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

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


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

--94eb2c06d100d3b85005504de65c-- From nobody Wed May 24 17:03:03 2017 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 9F0B1129B44 for ; Wed, 24 May 2017 17:03:01 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 NI_hPCrZMlxj for ; Wed, 24 May 2017 17:02:59 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 B952C129494 for ; Wed, 24 May 2017 17:02:59 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id o5so48207075ith.1 for ; Wed, 24 May 2017 17:02:59 -0700 (PDT) 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=IQ9PjciHPOp0Y1q8yLL/9AoCnlX9WpHQlFfSBuWCH9E=; b=aaVo06NRiyh5RGZE1bT5s6N0cvE5JtXVWs812MkG2nOeFZPnSrDSltjunICe0phcVj 5bjQ7JFBwhlMfopO+56QEs7jbVUoHlEbG1wb7xITrppxNS3NA3zoogMdeUwQUgdFYxS9 43iBUCHQkvLVbv4jqnUdY9F0uRJF4aepflaJmzxlENczENZZleRU/ETCZhiqQsBqoouV BMyO6IQnhP3rfhszvrN+EHtr91+baHJDa08gNvVc/9q7KDVEcl3UtgtWuTc0oMpxlENV LlxRVzBYlP4jRy7EC+uWpDzW+VUNY3DAu+j71ydkYQp33OdDUtf8r2athu8jhAYb0oT1 If6A== 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=IQ9PjciHPOp0Y1q8yLL/9AoCnlX9WpHQlFfSBuWCH9E=; b=ZDtnF4kbyWGNq6svVBej9KkoKwae1JXXKBGcDoLXezK3xICCDOz1sJhBhageN4EAjE Y+1Xqjo1ml96+zhoxQa54fclysalpA/+YFMKXqTbKG7h2ZzYjeacyggnALTyJxK/Vo8a flTEbp9tXMdaYPjvAtOaipXt8qRV4FjyPk05OWrLBvRDpQfy8zjVW40BByh72Cn4IhiS WA1XwhlH6k6tr/yuHN8ScRAVFogvixQ8pTLqln0/ekxMMTCtY/PwRSOXsq5aR7z7Ua4W t09gB0reSw7zQHi1qQ5JF+neOXvL2F8bUQ9chxpB21dfayRSSU2PBJLXjsn11LhSceP3 sKEw== X-Gm-Message-State: AODbwcB6sZnx4au8k+5CUb8P7fDLFXMHTjs1G8kbjmm67zcTz86zbwIm J/2/ZipenqKTjnDzVrxymCAc3aaa+ks+DFo= X-Received: by 10.36.29.204 with SMTP id 195mr11117352itj.112.1495670578960; Wed, 24 May 2017 17:02:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.11.149 with HTTP; Wed, 24 May 2017 17:02:38 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Wed, 24 May 2017 17:02:38 -0700 Message-ID: To: Bernard Aboba Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="001a1135b7648fe0f105504df19c" Archived-At: Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-fec-04 (Opus FEC) 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, 25 May 2017 00:03:02 -0000 --001a1135b7648fe0f105504df19c Content-Type: text/plain; charset="UTF-8" This would be a pretty dramatic statement, basically indicating that the FEC mechanism that has been built for Opus is not useful. While I understand the rationale, I would like to have some more specific results that we can point at before making such a claim in a RFC. On Tue, May 16, 2017 at 2:50 PM, Bernard Aboba wrote: > Section 3.3 > > For Opus, packets deemed as important are re-encoded at a lower > bitrate and added to the subsequent packet, allowing partial recovery > of a lost packet. This scheme is fairly efficient; experiments > performed indicate that when Opus FEC is used, the overhead imposed > is about 20-30%, depending on the amount of protection needed. Note > that this mechanism can only carry redundancy information for the > immediately preceding packet; as such the decoder cannot fully > recover multiple consecutive lost packets, which can be a problem on > wireless networks. See [RFC6716], Section 2.1.7 for complete > details. > > > Section 4.1 > > > When using the Opus codec, use of the built-in Opus FEC mechanism is > RECOMMENDED. This provides reasonable protection of the audio stream > against typical losses, with modest overhead. Note that as indicated > above the built-in Opus FEC only provides single-frame redundancy; if > multi-packet protection is needed, the built-in FEC should be > combined with [RFC2198 ] redundancy to protect the N-2th, N-3rd, etc. > packets. > > > [BA] While loss of a single packet is by far the most likely loss > > mode, our tests do not indicate that there is much benefit from > > Opus internal FEC. For example, when we compared Opus internal > > FEC against no FEC and concealment, we found little discernible > > difference in MOS score. On the other hand, we did see a benefit > > arising from RFC 2198 redundancy to protect against burst loss. > > So based on our test results, we cannot recommend use of built-in > > Opus FEC. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a1135b7648fe0f105504df19c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This would be a pretty dramatic statement, basically indic= ating that the FEC mechanism that has been built for Opus is not useful.
While I understand the rationale, I would like to have som= e more specific results that we can point at before making such a claim in = a RFC.

On Tu= e, May 16, 2017 at 2:50 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
Sec= tion 3.3

   For Opus, packets deemed as important are=
 re-encoded at a lower
   bitrate and added to the subsequent packet, allowing partial recovery
   of a lost packet.  This scheme is fairly efficient; experiments
   performed indicate that when Opus FEC is used, the overhead imposed
   is about 20-30%, depending on the amount of protection needed.  Note
   that this mechanism can only carry redundancy information for the
   immediately preceding packet; as such the decoder cannot fully
   recover multiple consecutive lost packets, which can be a problem on
   wireless networks.  See [RFC6716], Section=C2=A02.1.7 for compl=
ete
   details.

Section 4.1

   When using the Opu=
s codec, use of the built-in Opus FEC mechanism is
   RECOMMENDED.  This provides reasonable protection of the audio stream
   against typical losses, with modest overhead.  Note that as indicated
   above the built-in Opus FEC only provides single-frame redundancy; if
   multi-packet protection is needed, the built-in FEC should be
   combined with [RFC2198=
] redundancy to protect the N-2th, N-3rd, etc.
   packets.

[BA] While loss of a single packet i=
s by far the most likely loss
mode, our tests do not indicate that =
there is much benefit from
Opus internal FEC.  For example, when we=
 compared Opus internal
FEC against no FEC and concealment, we foun=
d little discernible
difference in MOS score. On the other hand, we=
 did see a benefit
arising from RFC 2198 redundancy to protect agai=
nst burst loss.
So based on our test results, we cannot recommend u=
se of built-in
Opus FEC.

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

--001a1135b7648fe0f105504df19c-- From nobody Wed May 24 17:35:22 2017 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 BC294128C81 for ; Wed, 24 May 2017 17:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.702 X-Spam-Level: X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 MQJZYYQ9j2He for ; Wed, 24 May 2017 17:35:18 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 499941200C5 for ; Wed, 24 May 2017 17:35:18 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id 9so150544935pfj.1 for ; Wed, 24 May 2017 17:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=8o4kvxad1K9qNe2bTokMhrq1YU2naaYLnqcMsx70F/c=; b=OItBjxXTAIqiqeO7pFvQevo9zGfkqXfI/DLBUh6QkOMXjx7nKajHxZqpFQp+4Ayqaz Z+Ina9QU2uXSuwsS5apLzH6wnEpMC91uAdFov/yakYWFuQf1Lt/gVOgRLEnPEMU9u5d9 V2XN1u+fVIR5Udn2lTNVCfX/3+mOQspG7/gZHjlq4s+CYe6EXd6I6P9eZt7crzCa6+lr BtJsjUz8ix+6W+QNYBIJMMzXUGAtgouGhLPcBd8rUB+RK3t2P/c9iZj2HFOXMg/nDA3p JPEJOFFny5cbNs1UH4kD81C9NNMCkcNKE4Ip/k9IAd3d4hXbt5SnbxbMoJKu71TwOrBp bP2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=8o4kvxad1K9qNe2bTokMhrq1YU2naaYLnqcMsx70F/c=; b=YfhrLPM6f0gg29lJjXBOUWo1tr87bVlYBG1hVF9cvu+lOPB3F8RHsElWULJnOIb/dD XcH1YFjvAgiuiVSe7/hcITdxdCug4MK0TFE5x3VHDOW1Oqv+UaPvyQ1GCmeY5PSckCjt KTXjBLCUjjm+M3iRzbfmOjLm5xma17UZc4/ipQPIbonQhA3ADLhdFKw1tXHHRG+wC3z4 w8cRs8d+ts8bnKQPM3l7iBqWVq+pWhZJdpZRVXhqzgTOjAjR/BTxd9tt0dO7qxugkVLn 1XHXq8HcPWlCFzUFVQKKNPaXRlYD0Ku10aOevXPpMtRtY+Mmb46IsS2g3nVbCRBsesJ7 k2tA== X-Gm-Message-State: AODbwcATNMKJ5GsuuVuaqOInu0MMUDu4hdLlHPtvRur4k6obrHxggBHo Imz2Ed3QuB/lkGSZVyR+ve5GoJo1b/HEAHM= X-Received: by 10.99.160.17 with SMTP id r17mr29222509pge.95.1495672517687; Wed, 24 May 2017 17:35:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.166.111 with HTTP; Wed, 24 May 2017 17:35:17 -0700 (PDT) From: Colin Gallagher Date: Wed, 24 May 2017 17:35:17 -0700 Message-ID: To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary="f403045e38a41e01a105504e6529" Archived-At: Subject: [rtcweb] Request for New Security Review of WebRTC based on observed vulnerabilities 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, 25 May 2017 00:35:21 -0000 --f403045e38a41e01a105504e6529 Content-Type: text/plain; charset="UTF-8" To: IETF RTCWeb WG From: Colin Gallagher https://www.linkedin.com/in/colingallagher https://lifeboat.com/ex/bios.colin.gallagher Request for New Security Review of WebRTC based on observed vulnerabilities in certain examples Dear IETF RTCWeb WG, This request relates to WebRTC. The WebRTC is in draft at https://w3c.github.io/webrtc-pc/ and is described also at https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API#WebRTC_interfaces There are certain examples where the use of WebRTC has presented security vulnerabilities. While not exhaustive, there are two I wanted to mention that I had been exposed to recently. 1) The use of a video conferencing service which relies upon WebRTC (that is a well established service) 2) The examination of a browser based WebRTC version of a decentralized exchange (that is currently under development) In both cases the security vulnerability which is described below was the result of the use of WebRTC. The problem under consideration is as follows: As per the first example (the video conferencing service), recently I came upon a vendor who shall remain unnamed who uses WebRTC as the backbone for their video conferencing service. As a result, I found I was unable to access the service in question without disabling some security settings which I would have preferred to leave intact. My system is (based on what the aforementioned service detects) Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0. This is Ubuntu 16.10 64-bit with Firefox 53.0.2. However, quite some *long* while back I disabled WebRTC because of the security vulnerability (described in part here on information security stack exchange ). So as to mitigate this vulnerability, I changed settings in Firefox as follows: 1. I typed *about:config* in the address bar 2. I found the setting *media.peerconnection.enabled* 3. I set it to *false* Unfortunately, this setting does not allow Firefox to work with the video conferencing service in question, which relies entirely on WebRTC. So I had to go back in and change the media.peerconnection.enabled setting to *true* in Firefox in order to get it to work with the service in question. While this enabled me to conference with teams that desire to use the video conferencing service that rely wholly upon WebRTC, it concerns me because of the security vulnerability. One suggested mitigation was having NoScript, but using NoScript was not helpful (you generally need to disable it for the site you are viewing that relies upon WebRTC, in order to obtain any functionality, and whether NoScript is off or on, WebRTC still causes the vulnerability of leaking information as previously described). Furthermore, upon reload of the browser, even after setting media.peerconnection.enabled to *true*, the video conferencing service wouldn't work until I installed the WebRTC 0.1.3 extension for Firefox and set it to expose my real IP address as well as allowing the following: a. navigator.getUserMedia b. window.MediaStreamTrack c. window.RTCPeerConnection d. window.RTCSessionDescription That seemed to me to be a direct consequence of the persistent and ongoing security vulnerability in WebRTC. I contacted the video conferencing service provider and their solution was simply to state that "If the peer to peer connection is of concern, you can utilize our premium version which will route traffic through a forwarding server with in our environment that handles the processing of the video and sound of all users in the conference and send it to each user individually rather than using a peer to peer connection." In other words, they expect that people should have to pay in order to mitigate this WebRTC security vulnerability , because they are unwilling to design to protect all users from it. In a similar fashion, in the second example of the browser based WebRTC version of a decentralized exchange, the user's financial information is periodically exposed as a result of the information leakage which is presently caused by WebRTC. (Fortunately, this browser based WebRTC decentralized exchange is under development and is not currently open to actual usage.) Although undoubtedly this has been discussed here before, I am asking that WebRTC security issues be reconsidered and that a new security review be done to ameliorate or eliminate this problem in terms of WebRTC leaking this information. It is my view that WebRTC should be further designed and developed with an eye to mitigating this serious problem, so that users of services which might rely partially or wholly upon WebRTC would not have to be concerned about such information leakage. Respectfully, Colin Gallagher --f403045e38a41e01a105504e6529 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To:=C2=A0 IETF RTC= Web WG

From:=C2=A0 Colin Gallagher
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.linkedin.com/in/colingallagher
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://lifeboat.com/ex/bios.col= in.gallagher

Request for New Security Review of WebRTC bas= ed on observed vulnerabilities in certain examples

Dear IETF R= TCWeb WG,

This request relates to WebRTC.=C2=A0 The WebRT= C is in draft at https://w3c.g= ithub.io/webrtc-pc/ and is=20 described also at=20 https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API#= WebRTC_interfaces

There are certain examples where = the use of WebRTC has presented security vulnerabilities.=C2=A0 While not e= xhaustive, there are two I wanted to mention that I had been exposed to rec= ently.

1) The use of a video conferencing service w= hich relies upon WebRTC (that is a well established service)
2) Th= e examination of a browser based WebRTC version of a decentralized exchange= (that is currently under development)

In both cases the secur= ity vulnerability which is described below was the result of the use of Web= RTC.

The problem under consideration is as follows:

As per th= e first example (the video conferencing service), recently I came upon a vendor who shall remain unnamed who uses WebRTC as the=20 backbone for their video conferencing service.=C2=A0 As a result, I found I= =20 was unable to access the service in question without disabling some=20 security settings which I would have preferred to leave intact.

My = system is (based on what the aforementioned service detects) Mozilla/5.0 (X= 11; Ubuntu; Linux x86_64; rv:53.0)=20 Gecko/20100101 Firefox/53.0.=C2=A0 This is Ubuntu 16.10 64-bit with Firefox= =20 53.0.2.

However, quite some long while back I disabled WebRTC= because of the security vulnerability (described in part here = on information security stack exchange).=C2=A0 So as to mitigate this v= ulnerability, I changed settings in Firefox as follows:

  1. I ty= ped about:config in the address bar
  2. I found the setting media.peerconnection.enabled
  3. I set it to false

Unfortunately, this setting does not allow Firefox to work with the video conferencing service in question, which relies entirely on WebRTC.

So I had t= o go back in and change the media.peerconnection.enabled setting to true= in Firefox in order to get it to work with the service in question.=20 While this enabled me to conference with teams that desire to use the=20 video conferencing service that rely wholly upon WebRTC, it concerns me=20 because of the security vulnerability.

One suggested mitigation was h= aving NoScript, but using NoScript was not helpful (you generally need to d= isable it for the site you are viewing that relies upon WebRTC, in order to= obtain any functionality, and whether NoScript is off or on, WebRTC still = causes the vulnerability of leaking information as previously described).

Furthermore, upon reload of the browser, even after setting media.= peerconnection.enabled to true, the video conferencing service wouldn't work until I installed the=20 WebRTC 0.1.3 extension for Firefox and set it to expose my real IP=20 address as well as allowing the following:

a. navigator.getUserMedia<= br>b. window.MediaStreamTrack
c. window.RTCPeerConnection
d. window.R= TCSessionDescription

That seemed to me to be a direct consequence= of the persistent and ongoing security vulnerability in WebRTC.

= I contacted the video conferencing service provider and their solution=20 was simply to state that "If the peer to peer connection is of concern= ,=20 you can utilize our=20 premium version which will route traffic through a forwarding server=20 with in our environment that handles the processing of the video and=20 sound of all users in the conference and send it to each user=20 individually rather than using a peer to peer connection."=C2=A0 In ot= her=20 words, they expect that people should have to pay in order to mitigate this WebRTC security vulnerability, because they are unwilling = to design to protect all users from it.

In a similar fashion, in the = second example of the browser based WebRTC version of a decentralized excha= nge, the user's financial information is periodically exposed as a resu= lt of the information leakage which is presently caused by WebRTC.=C2=A0 (F= ortunately, this browser based WebRTC decentralized exchange is under devel= opment and is not currently open to actual usage.)

Although undoubtedly this has been discussed here before, I am asking that WebRTC s= ecurity issues be reconsidered and that a new security review be done to ameliorate or=20 eliminate this problem in terms of WebRTC leaking this information.=C2=A0 I= t is my view that WebRTC should be further designed and developed with an e= ye to mitigating this serious problem, so that users of services which migh= t rely partially or wholly upon WebRTC would not have to be concerned about= such information leakage.

Respectfully,

Colin Gallagher
--f403045e38a41e01a105504e6529-- From nobody Thu May 25 13:05:21 2017 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 B7A48129AC5 for ; Thu, 25 May 2017 13:05:19 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 iP3nlMO_sJMq for ; Thu, 25 May 2017 13:05:11 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001: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 A74A912EAB8 for ; Thu, 25 May 2017 13:05:11 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id o12so143819195iod.3 for ; Thu, 25 May 2017 13:05:11 -0700 (PDT) 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=4yTavUdE56vyRQKEp8JfZUk2dm1APdBQ3kcdfQsznRw=; b=mZCMMNh9ajIAw5sv+F78iurJH7LTq3xheJQbVBsohMmwEh6jLWzXb6qQdbTiWJ/dDH eO1RcIT78Mhin81OPeyg4ov/X6zxkGtg9xkbxpK7I0kNTQGzUPmsxj6HKjoMYwcXWcyu 2r0m0i49IrdeDYGNqL3Bk8WyucUMPgFfeSCk7BDnIdS1y8v43C41Ukf0OO3qaicoInwx pKt5uxTHUWTu4n3T+QnMJpHSTUJi5rTlxiBt50q66ASB/LYcwSfp8e7HDrLl7nA8kpvb 5iO8x1NjDrcTjDtVFPMAOiJfL92sLOA4nCdXRu5p1jR57gSeg/E3k8intNoTrFCCE/HF B87g== 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=4yTavUdE56vyRQKEp8JfZUk2dm1APdBQ3kcdfQsznRw=; b=sSMY/9XJKc10oPEa78bBxHloAarYMDj/WvGMb60GP+sAkalEistH+AHHAKebQQwc36 lwXZvOZLSziuTawLqMD96rndiEvfL6PJYcSySrzA1ARiZI7rWq+ma0IOCGrhk8K54Qpt 71g72Wfe+7NuYYlIm1dtISU3iIqqagIJd4yGzCm1iIMTHa6A69eXIG/UO6ylIL8Cae3I dhXAnJ6Y24mc/v/0wNwDA13s0Ok123JWuXAtOvlvUWedXOB2EIdFJueejFucgsf986Td afGWsjrweBBl5A5g7NFlhhXIn/kOX2BniCklkCaqgTWNtZlq10L2dBZR6lmO857etNwg IBPg== X-Gm-Message-State: AODbwcCXF/XHzAsiG6w1G63v+DXmCo57deDew6KEQBll7h15jTLObpfv cIoc0nnOQoYnV0cpLIesHLwn/iwDZtIptWw= X-Received: by 10.107.133.106 with SMTP id h103mr38652211iod.230.1495742710841; Thu, 25 May 2017 13:05:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.11.149 with HTTP; Thu, 25 May 2017 13:04:50 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Thu, 25 May 2017 13:04:50 -0700 Message-ID: To: Colin Gallagher Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="001a113ff9a6f5112b05505ebc94" Archived-At: Subject: Re: [rtcweb] Request for New Security Review of WebRTC based on observed vulnerabilities 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, 25 May 2017 20:05:20 -0000 --001a113ff9a6f5112b05505ebc94 Content-Type: text/plain; charset="UTF-8" Colin, This is an important topic, and the group has reviewed this situation in detail. The results have been written up in this document , and to my knowledge most browsers that support WebRTC currently conform to its recommendations. However, I'm not totally clear on your specific technical concern. You linked to an (now outdated) stackexchange page, but could you provide more detail about the specific situation you are concerned about? Justin On Wed, May 24, 2017 at 5:35 PM, Colin Gallagher < colingallagher.rpcv@gmail.com> wrote: > To: IETF RTCWeb WG > > From: Colin Gallagher > https://www.linkedin.com/in/colingallagher > https://lifeboat.com/ex/bios.colin.gallagher > > Request for New Security Review of WebRTC based on observed > vulnerabilities in certain examples > > Dear IETF RTCWeb WG, > > This request relates to WebRTC. The WebRTC is in draft at > https://w3c.github.io/webrtc-pc/ and is described also at > https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API# > WebRTC_interfaces > > There are certain examples where the use of WebRTC has presented security > vulnerabilities. While not exhaustive, there are two I wanted to mention > that I had been exposed to recently. > > 1) The use of a video conferencing service which relies upon WebRTC (that > is a well established service) > 2) The examination of a browser based WebRTC version of a decentralized > exchange (that is currently under development) > > In both cases the security vulnerability which is described below was the > result of the use of WebRTC. > > The problem under consideration is as follows: > > As per the first example (the video conferencing service), recently I came > upon a vendor who shall remain unnamed who uses WebRTC as the backbone for > their video conferencing service. As a result, I found I was unable to > access the service in question without disabling some security settings > which I would have preferred to leave intact. > > My system is (based on what the aforementioned service detects) > Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 > Firefox/53.0. This is Ubuntu 16.10 64-bit with Firefox 53.0.2. > > However, quite some *long* while back I disabled WebRTC because of the > security vulnerability (described in part here on information security > stack exchange > ). > So as to mitigate this vulnerability, I changed settings in Firefox as > follows: > > > 1. I typed *about:config* in the address bar > 2. I found the setting *media.peerconnection.enabled* > 3. I set it to *false* > > Unfortunately, this setting does not allow Firefox to work with the video > conferencing service in question, which relies entirely on WebRTC. > > So I had to go back in and change the media.peerconnection.enabled setting > to *true* in Firefox in order to get it to work with the service in > question. While this enabled me to conference with teams that desire to use > the video conferencing service that rely wholly upon WebRTC, it concerns me > because of the security vulnerability. > > One suggested mitigation was having NoScript, but using NoScript was not > helpful (you generally need to disable it for the site you are viewing that > relies upon WebRTC, in order to obtain any functionality, and whether > NoScript is off or on, WebRTC still causes the vulnerability of leaking > information as previously described). > > Furthermore, upon reload of the browser, even after setting > media.peerconnection.enabled to *true*, the video conferencing service > wouldn't work until I installed the WebRTC 0.1.3 extension for Firefox and > set it to expose my real IP address as well as allowing the following: > > a. navigator.getUserMedia > b. window.MediaStreamTrack > c. window.RTCPeerConnection > d. window.RTCSessionDescription > > That seemed to me to be a direct consequence of the persistent and ongoing > security vulnerability in WebRTC. > > I contacted the video conferencing service provider and their solution was > simply to state that "If the peer to peer connection is of concern, you can > utilize our premium version which will route traffic through a forwarding > server with in our environment that handles the processing of the video and > sound of all users in the conference and send it to each user individually > rather than using a peer to peer connection." In other words, they expect > that people should have to pay in order to mitigate this WebRTC security > vulnerability > , > because they are unwilling to design to protect all users from it. > > In a similar fashion, in the second example of the browser based WebRTC > version of a decentralized exchange, the user's financial information is > periodically exposed as a result of the information leakage which is > presently caused by WebRTC. (Fortunately, this browser based WebRTC > decentralized exchange is under development and is not currently open to > actual usage.) > > Although undoubtedly this has been discussed here before, I am asking that > WebRTC security issues be reconsidered and that a new security review be > done to ameliorate or eliminate this problem in terms of WebRTC leaking > this information. It is my view that WebRTC should be further designed and > developed with an eye to mitigating this serious problem, so that users of > services which might rely partially or wholly upon WebRTC would not have to > be concerned about such information leakage. > > Respectfully, > Colin Gallagher > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a113ff9a6f5112b05505ebc94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Colin,

This is an important topic, and = the group has reviewed this situation in detail. The results have been writ= ten up in this document, and to my knowledge most browsers that support W= ebRTC currently conform to its recommendations.

Ho= wever, I'm not totally clear on your specific technical concern. You li= nked to an (now outdated) stackexchange page, but could you provide more de= tail about the specific situation you are concerned about?

Justin

On Wed, May 24, 2017 at 5:35 PM, Colin Gallagher <co= lingallagher.rpcv@gmail.com> wrote:
To:=C2=A0= IETF RTCWeb WG

From:=C2=A0 Colin Gallagher
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.linkedin.com/= in/colingallagher
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 https://lifeboat.com/ex/bios.colin.gallagher
Request for New Security Review of WebRTC based on observed vulnera= bilities in certain examples

Dear IETF RTCWeb WG,

This request relates to WebRTC.=C2=A0 The WebRTC is in draft at https://w3c.githu= b.io/webrtc-pc/ and is=20 described also at=20 https://developer.mozilla.org/en-US/d= ocs/Web/API/WebRTC_API#WebRTC_interfaces

There= are certain examples where the use of WebRTC has presented security vulner= abilities.=C2=A0 While not exhaustive, there are two I wanted to mention th= at I had been exposed to recently.

1) The use of a = video conferencing service which relies upon WebRTC (that is a well establi= shed service)
2) The examination of a browser based WebRTC version= of a decentralized exchange (that is currently under development)

<= /div>In both cases the security vulnerability which is described below was = the result of the use of WebRTC.

The problem under consideration is = as follows:

As per the first example (the video conferencing service= ), recently I came upon a vendor who shall remain unnamed who uses WebRTC as the=20 backbone for their video conferencing service.=C2=A0 As a result, I found I= =20 was unable to access the service in question without disabling some=20 security settings which I would have preferred to leave intact.

My = system is (based on what the aforementioned service detects) Mozilla/5.0 (X= 11; Ubuntu; Linux x86_64; rv:53.0)=20 Gecko/20100101 Firefox/53.0.=C2=A0 This is Ubuntu 16.10 64-bit with Firefox= =20 53.0.2.

However, quite some long while back I disabled WebRTC= because of the security vulnerability (described in part here = on information security stack exchange).=C2=A0 So as to mitigate this v= ulnerability, I changed settings in Firefox as follows:

  1. I ty= ped about:config in the address bar
  2. I found the setting media.peerconnection.enabled
  3. I set it to false

Unfortunately, this setting does not allow Firefox to work with the video conferencing service in question, which relies entirely on WebRTC.

So I had t= o go back in and change the media.peerconnection.enabled setting to true= in Firefox in order to get it to work with the service in question.=20 While this enabled me to conference with teams that desire to use the=20 video conferencing service that rely wholly upon WebRTC, it concerns me=20 because of the security vulnerability.

One suggested mitigation was h= aving NoScript, but using NoScript was not helpful (you generally need to d= isable it for the site you are viewing that relies upon WebRTC, in order to= obtain any functionality, and whether NoScript is off or on, WebRTC still = causes the vulnerability of leaking information as previously described).

Furthermore, upon reload of the browser, even after setting media.= peerconnection.enabled to true, the video conferencing service wouldn't work until I installed the=20 WebRTC 0.1.3 extension for Firefox and set it to expose my real IP=20 address as well as allowing the following:

a. navigator.getUserMedia<= br>b. window.MediaStreamTrack
c. window.RTCPeerConnection
d. window.R= TCSessionDescription

That seemed to me to be a direct consequence= of the persistent and ongoing security vulnerability in WebRTC.

= I contacted the video conferencing service provider and their solution=20 was simply to state that "If the peer to peer connection is of concern= ,=20 you can utilize our=20 premium version which will route traffic through a forwarding server=20 with in our environment that handles the processing of the video and=20 sound of all users in the conference and send it to each user=20 individually rather than using a peer to peer connection."=C2=A0 In ot= her=20 words, they expect that people should have to pay in order to mitigate this WebRTC security vulnerability, because they are unwilling = to design to protect all users from it.

In a similar fashion, in the = second example of the browser based WebRTC version of a decentralized excha= nge, the user's financial information is periodically exposed as a resu= lt of the information leakage which is presently caused by WebRTC.=C2=A0 (F= ortunately, this browser based WebRTC decentralized exchange is under devel= opment and is not currently open to actual usage.)

Although undoubtedly this has been discussed here before, I am asking that WebRTC s= ecurity issues be reconsidered and that a new security review be done to ameliorate or=20 eliminate this problem in terms of WebRTC leaking this information.=C2=A0 I= t is my view that WebRTC should be further designed and developed with an e= ye to mitigating this serious problem, so that users of services which migh= t rely partially or wholly upon WebRTC would not have to be concerned about= such information leakage.

Respectfully,

Colin Gallagher

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

--001a113ff9a6f5112b05505ebc94-- From nobody Fri May 26 00:58:17 2017 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 55F6D126FDC for ; Fri, 26 May 2017 00:58:15 -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 HwV7Qe5FPRJ7 for ; Fri, 26 May 2017 00:58:10 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 8919A1242EA for ; Fri, 26 May 2017 00:58:10 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id e193so4645454pfh.0 for ; Fri, 26 May 2017 00:58:10 -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=K5gI7f3JW7jP2YazMu1SXWNOOF8WDWIGXVYkzNOuKNE=; b=uycOGPYdgD0kLBQ4quKrnGuAS+7cS7PDa93fh28rs6Cj8BuG1Bg92LAsqlh92nAngH HVjozCHE205D0IN3QXofJVgXHq0p4AhV2FZ6Mb+Rn4oHT/iEUYcCttxfEEer9jDp45Ht 4XT/KziXAD5ZFmoa/R52SF+JLlyW+acq04hhnYMSq0ost3DYN+lbHJGYSJ6ChmI8SGP4 Fh1n7ZhSe7qF9jrWnGukhZdFP/fOUIbb4/XWu/UK1GyCy7+QSoxur0JNvFFH6/VAB9Ld 1GmbtqsdEvZpnjiHFFyanl6+cIzFUxthNbPoxEof/iEVp416lx0ZDCpWgY2lnWA2YexT cffg== 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=K5gI7f3JW7jP2YazMu1SXWNOOF8WDWIGXVYkzNOuKNE=; b=LhlH2VfbY7dQmhO/Qupc0DUMzriwOCDm9oeGO+eM2SLH2lmprH7eD0P2I1PrZ148g6 W+hAu6AVPlEUkVwMkPJ9yJ9XozZMWYZd4REcXF+7dCA3qBujWpjAn+LIhNUJjzaFlj2+ 63BTtZSCu1DMbrH0RKU18ZJIdQTxhkehSTukZoCNdjAu47/kwDz9DKtp21KxGiNK5+JM Qqxd+vUFt3yvLm2QGN3qWOqUXqeuZcvi8F4Hmp/Vb6nG16kshWO8SLMcdbIrEZu0ljSe 79O8Z7v+Oapxk8ad6JbY6o665djjr4TETiDNWk4vvXKWFwf3u/fud1X9AwVUM0gHZg1x 7QcA== X-Gm-Message-State: AODbwcC8PFppEogcO2AdwZpbMkGWiVCWKwL3Eung1cq2COwQmo3uZKrT 4JbCsz4fTcSevifyAP/JxaJzq6o88g== X-Received: by 10.99.181.25 with SMTP id y25mr808391pge.192.1495785489894; Fri, 26 May 2017 00:58:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.179.161 with HTTP; Fri, 26 May 2017 00:58:09 -0700 (PDT) In-Reply-To: References: From: Colin Gallagher Date: Fri, 26 May 2017 00:58:09 -0700 Message-ID: To: Justin Uberti Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1b7fd6c912f5055068b2a2" Archived-At: Subject: Re: [rtcweb] Request for New Security Review of WebRTC based on observed vulnerabilities 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, 26 May 2017 07:58:15 -0000 --94eb2c1b7fd6c912f5055068b2a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Justin, It's my understanding that various browsers have made an attempt to conform to the recommendations in the document that you have provided . Unfortunately, at least in Firefox (the most current version) so far as I can tell, there is a serious vulnerability. To be more specific, the problem was observed in my operating system with my current browser, which is Ubuntu 16.10 64-bit with Firefox 53.0.2 (64-bit). The browser does not address the WebRTC problems by default. The stackexchange page that I cited originally is actually not outdated in the sense that its method of measuring whether or not the WebRTC vulnerability exists on a given system is still intact and works. The stackexchange page suggests two pages to determine whether or not you have leakage / WebRTC related vulnerability. These pages are: 1) Browser leaks test for WebRTC https://browserleaks.com/webrtc 2) IP Leaks https://ipleak.net/ Currently for Browser leaks test for WebRTC (due to that I have again changed settings in my system so that I will not have to be exposed to this vulnerability) the settings show up on the page as: RTCPeerConnection=C3=97False RTCDataChannel=C3=97False ORTC (Microsoft Edge)=C3=97False (for example....) And under IP leaks, it currently shows "No leak, RTCPeerConnection not available." *That is because:* (A) I have (again) changed my settings in about:config back to the followin= g 1. I typed *about:config* in the address bar 2. I found the setting *media.peerconnection.enabled* 3. I set it to *false (it was previously set at true, so as to allow WebRTC to work, but this exposed information which I would not have want= ed to be exposed)* (B) And I also have changed my settings back to the following in the WebRTC 0.1.3 extension for Firefox I have set it to no longer expose my real IP address as well as no longer allowing the following: a. navigator.getUserMedia b. window.MediaStreamTrack c. window.RTCPeerConnection d. window.RTCSessionDescription To be clear, *these mitigations that I have employed above would be unnecessary if WebRTC had not been designed in such a manner that it so clearly exposes so much user information.* In the document you provided , titled "WebRTC IP Address Handling Requirements - draft-ietf-rtcweb-ip-handling-03," it is stated that: *"1. If the client is behind a NAT, the client's private IP addresses, typically [RFC1918 ] addresses, can be learned. * * 2. If the client tries to hide its physical location through a VPN, and the VPN and local OS support routing over multiple interfaces (i.e., a "split-tunnel" VPN), WebRTC will discover the public address for the VPN as well as the ISP public address that the VPN runs over. 3. If the client is behind a proxy (a client-configured "classical application proxy", as defined in [RFC1919], Section 3 ), but direct access to the Internet is also supported, WebRTC's STUN [RFC5389 ]checks will bypass the proxy and reveal the public address of the client."* All of these are obvious vulnerabilities and serious problems (not only #2 as the document suggests). It is stated in the document that, *"we want to avoid solutions that disable WebRTC or make it harder to use."= * Yet, so far as my observations of WebRTC in the current version of Firefox with Ubuntu 16.10 have shown, there appears to be no other choice other than to disable WebRTC because its use completely compromises privacy and thus makes all other aspects of your system more difficult generally. It is stated in the document you cited that the goals here are to "Provide a privacy-friendly default behavior which strikes the right balance between privacy and media performance for most users and use cases. (and) For users who care more about one versus the other, provide a means to customize the experience." This has clearlly not been accomplished in the context of Ubuntu 16.10 64-bit with Firefox 53.0.2 (64-bit). Hence my request for a new security review of WebRTC based on observed vulnerabilities. On Thu, May 25, 2017 at 1:04 PM, Justin Uberti wrote: > Colin, > > This is an important topic, and the group has reviewed this situation in > detail. The results have been written up in this document > , and to my > knowledge most browsers that support WebRTC currently conform to its > recommendations. > > However, I'm not totally clear on your specific technical concern. You > linked to an (now outdated) stackexchange page, but could you provide mor= e > detail about the specific situation you are concerned about? > > Justin > > On Wed, May 24, 2017 at 5:35 PM, Colin Gallagher < > colingallagher.rpcv@gmail.com> wrote: > >> To: IETF RTCWeb WG >> >> From: Colin Gallagher >> https://www.linkedin.com/in/colingallagher >> https://lifeboat.com/ex/bios.colin.gallagher >> >> Request for New Security Review of WebRTC based on observed >> vulnerabilities in certain examples >> >> Dear IETF RTCWeb WG, >> >> This request relates to WebRTC. The WebRTC is in draft at >> https://w3c.github.io/webrtc-pc/ and is described also at >> https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API# >> WebRTC_interfaces >> >> There are certain examples where the use of WebRTC has presented securit= y >> vulnerabilities. While not exhaustive, there are two I wanted to mentio= n >> that I had been exposed to recently. >> >> 1) The use of a video conferencing service which relies upon WebRTC (tha= t >> is a well established service) >> 2) The examination of a browser based WebRTC version of a decentralized >> exchange (that is currently under development) >> >> In both cases the security vulnerability which is described below was th= e >> result of the use of WebRTC. >> >> The problem under consideration is as follows: >> >> As per the first example (the video conferencing service), recently I >> came upon a vendor who shall remain unnamed who uses WebRTC as the backb= one >> for their video conferencing service. As a result, I found I was unable= to >> access the service in question without disabling some security settings >> which I would have preferred to leave intact. >> >> My system is (based on what the aforementioned service detects) >> Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 >> Firefox/53.0. This is Ubuntu 16.10 64-bit with Firefox 53.0.2. >> >> However, quite some *long* while back I disabled WebRTC because of the >> security vulnerability (described in part here on information security >> stack exchange >> ). >> So as to mitigate this vulnerability, I changed settings in Firefox as >> follows: >> >> >> 1. I typed *about:config* in the address bar >> 2. I found the setting *media.peerconnection.enabled* >> 3. I set it to *false* >> >> Unfortunately, this setting does not allow Firefox to work with the vide= o >> conferencing service in question, which relies entirely on WebRTC. >> >> So I had to go back in and change the media.peerconnection.enabled >> setting to *true* in Firefox in order to get it to work with the service >> in question. While this enabled me to conference with teams that desire = to >> use the video conferencing service that rely wholly upon WebRTC, it >> concerns me because of the security vulnerability. >> >> One suggested mitigation was having NoScript, but using NoScript was not >> helpful (you generally need to disable it for the site you are viewing t= hat >> relies upon WebRTC, in order to obtain any functionality, and whether >> NoScript is off or on, WebRTC still causes the vulnerability of leaking >> information as previously described). >> >> Furthermore, upon reload of the browser, even after setting >> media.peerconnection.enabled to *true*, the video conferencing service >> wouldn't work until I installed the WebRTC 0.1.3 extension for Firefox a= nd >> set it to expose my real IP address as well as allowing the following: >> >> a. navigator.getUserMedia >> b. window.MediaStreamTrack >> c. window.RTCPeerConnection >> d. window.RTCSessionDescription >> >> That seemed to me to be a direct consequence of the persistent and >> ongoing security vulnerability in WebRTC. >> >> I contacted the video conferencing service provider and their solution >> was simply to state that "If the peer to peer connection is of concern, = you >> can utilize our premium version which will route traffic through a >> forwarding server with in our environment that handles the processing of >> the video and sound of all users in the conference and send it to each u= ser >> individually rather than using a peer to peer connection." In other wor= ds, >> they expect that people should have to pay in order to mitigate this >> WebRTC security vulnerability >> , >> because they are unwilling to design to protect all users from it. >> >> In a similar fashion, in the second example of the browser based WebRTC >> version of a decentralized exchange, the user's financial information is >> periodically exposed as a result of the information leakage which is >> presently caused by WebRTC. (Fortunately, this browser based WebRTC >> decentralized exchange is under development and is not currently open to >> actual usage.) >> >> Although undoubtedly this has been discussed here before, I am asking >> that WebRTC security issues be reconsidered and that a new security revi= ew >> be done to ameliorate or eliminate this problem in terms of WebRTC leaki= ng >> this information. It is my view that WebRTC should be further designed = and >> developed with an eye to mitigating this serious problem, so that users = of >> services which might rely partially or wholly upon WebRTC would not have= to >> be concerned about such information leakage. >> >> Respectfully, >> Colin Gallagher >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --94eb2c1b7fd6c912f5055068b2a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Justin,

It's my understanding that various browsers have made an attempt to = conform to the recommendations in the document that you have provided.=C2= =A0 Unfortunately, at least in Firefox (the most current version) so far as= I can tell, there is a serious vulnerability.=C2=A0 To be more specific, t= he problem was observed in my operating system with my current browser, whi= ch is Ubuntu 16.10 64-bit with Firefox=20 53.0.2 (64-bit).=C2=A0 The browser does not address the WebRTC problems by = default.

The stackexchange page that I cited originally is act= ually not outdated in the sense that its method of measuring whether or not= the WebRTC vulnerability exists on a given system is still intact and work= s.=C2=A0 The stackexchange page suggests two pages to determine whether or = not you have leakage / WebRTC related vulnerability.=C2=A0 These pages are:=

1) Browser leaks test for WebRTC https://browserleaks.com/webrtc
2) IP Leaks https://ipleak.net/

Currentl= y for Browser leaks test for WebRTC (due to that I have again changed setti= ngs in my system so that I will not have to be exposed to this vulnerabilit= y) the settings show up on the page as:
RTCPeerConnection=C3=97False
RTCDataChannel= =C3=97False
ORTC (Microsoft Edge)=C3=97= False (for example....)

And under IP leaks, it currentl= y shows "No leak, RTCPeerConnection not available."=C2=A0
That is because:

(A) I have (again) changed my s= ettings in about:config back to the following

  1. I typed ab= out:config in the address bar
  2. I found the setting media.pe= erconnection.enabled
  3. I set it to false=C2=A0 (it was p= reviously set at true, so as to allow WebRTC to work, but this exposed info= rmation which I would not have wanted to be exposed)

(= B) And I also have changed my settings back to the following

in the W= ebRTC 0.1.3 extension for Firefox I have set it to no longer expose my real= IP=20 address as well as no longer allowing the following:

a. navigator.get= UserMedia
b. window.MediaStreamTrack
c. window.RTCPeerConnection
d= . window.RTCSessionDescription

To be clear, these mitigations that= I have employed above would be unnecessary if WebRTC had not been designed= in such a manner that it so clearly exposes so much user information.<= /p>

In the document you provided, titled "WebRTC IP Address Handli= ng Requirements - draft-ietf-rtcweb-ip-handling-03," it is stated that= :

"1. = If the client is behind a NAT, the client's private IP addresses, typi= cally [RFC1918] addresses, can be l= earned. 

 2.  If the client tries to hide its physical lo=
cation through a VPN,
       and the VPN and local OS support routing over multiple interfaces
       (i.e., a "split-tunnel" VPN), WebRTC will discover the pub=
lic
       address for the VPN as well as the ISP public address that the
       VPN runs over.

   3.  If the client is behind a proxy (a client-configured "classical
       application proxy", as defined in [RFC1919], Section=C2=A03), but
       direct access to the Internet is also supported, WebRTC's STUN
       [RFC5389]checks will bypas=
s the proxy and reveal the public
       address of the client."

All of=
 these are obvious vulnerabilities and serious problems (not only #2 as the=
 document suggests).

It is stated in the docum=
ent that, 

"we want to avoid solutions that disable WebRTC o=
r make it harder to use."

Yet, so far=
 as my observations of WebRTC in the current version of Firefox with Ubuntu=
 16.10 have shown,
there appears to be no other ch=
oice other than to disable WebRTC because its use completely compromises 
privacy and thus makes all other aspects of your sy=
stem more difficult generally.  

It is stated =
in the document you cited that the goals here are to "Provide a=
 privacy-friendly default behavior which strikes the
      right balance between privacy and media performance for most users
      and use cases. (and) For users who care more about one versus the oth=
er, provide a
      means to customize the experience."
This has clear=
lly not been accomplished in the context of Ubuntu 16.10 64-bit with Firefo=
x 53.0.2 (64-bit).

Hence my request for a new =
security review of WebRTC based on observed vulnerabilities.

=



On Thu, Ma=
y 25, 2017 at 1:04 PM, Justin Uberti <juberti@google.com> w=
rote:
Colin,

This is an important topic, and the group has reviewed this situati=
on in detail. The results have been written up in this docu=
ment, and to my knowledge most browsers that support WebRTC currently c=
onform to its recommendations.

However, I'm no=
t totally clear on your specific technical concern. You linked to an (now o=
utdated) stackexchange page, but could you provide more detail about the sp=
ecific situation you are concerned about?

Justin

On Wed, May 24, 2017 at 5:35 PM, Colin Gallagher <colingallagher.rpcv@gmail.com> wrote:
To:=C2=A0 IETF RTCWeb WG

From:=C2=A0 Colin Gallagher
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 https://www.linkedin.com/in/colingallagher<=
br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://lif=
eboat.com/ex/bios.colin.gallagher

Request for New Sec=
urity Review of WebRTC based on observed vulnerabilities in certain example=
s

Dear IETF RTCWeb WG,

This request relates =
to WebRTC.=C2=A0 The WebRTC is in draft at https://w3c.github.io/webrtc-pc/ an=
d is=20
described also at=20
https://developer.mozilla.org/en-US/d=
ocs/Web/API/WebRTC_API#WebRTC_interfaces

There=
 are certain examples where the use of WebRTC has presented security vulner=
abilities.=C2=A0 While not exhaustive, there are two I wanted to mention th=
at I had been exposed to recently.

1) The use of a =
video conferencing service which relies upon WebRTC (that is a well establi=
shed service)
2) The examination of a browser based WebRTC version=
 of a decentralized exchange (that is currently under development)

<=
/div>In both cases the security vulnerability which is described below was =
the result of the use of WebRTC.

The problem under consideration is =
as follows:

As per the first example (the video conferencing service=
), recently
 I came upon a vendor who shall remain unnamed who uses WebRTC as the=20
backbone for their video conferencing service.=C2=A0 As a result, I found I=
=20
was unable to access the service in question without disabling some=20
security settings which I would have preferred to leave intact. 

My =
system is (based on what the aforementioned service detects) Mozilla/5.0 (X=
11; Ubuntu; Linux x86_64; rv:53.0)=20
Gecko/20100101 Firefox/53.0.=C2=A0 This is Ubuntu 16.10 64-bit with Firefox=
=20
53.0.2.

However, quite some long while back I disabled WebRTC=
 because of the security vulnerability (described in part here =
on information security stack exchange).=C2=A0 So as to mitigate this v=
ulnerability, I changed settings in Firefox as follows:

  1. I ty=
ped about:config in the address bar
  2. I found the setting media.peerconnection.enabled
  3. I set it to false
Unfortunately,
 this setting does not allow Firefox to work with the video conferencing
 service in question, which relies entirely on WebRTC.
So I had t=
o go back in and change the media.peerconnection.enabled setting to true=

 in Firefox in order to get it to work with the service in question.=20
While this enabled me to conference with teams that desire to use the=20
video conferencing service that rely wholly upon WebRTC, it concerns me=20
because of the security vulnerability.
One suggested mitigation was h=
aving NoScript, but using NoScript was not helpful (you generally need to d=
isable it for the site you are viewing that relies upon WebRTC, in order to=
 obtain any functionality, and whether NoScript is off or on, WebRTC still =
causes the vulnerability of leaking information as previously described).
Furthermore, upon reload of the browser, even after setting media.=
peerconnection.enabled to true,
 the video conferencing service wouldn't work until I installed the=20
WebRTC 0.1.3 extension for Firefox and set it to expose my real IP=20
address as well as allowing the following:
a. navigator.getUserMedia<=
br>b. window.MediaStreamTrack
c. window.RTCPeerConnection
d. window.R=
TCSessionDescription
That seemed to me to be a direct consequence=
 of the persistent and ongoing security vulnerability in WebRTC.
=
I
 contacted the video conferencing service provider and their solution=20
was simply to state that "If the peer to peer connection is of concern=
,=20
you can utilize our=20
premium version which will route traffic through a forwarding server=20
with in our environment that handles the processing of the video and=20
sound of all users in the conference and send it to each user=20
individually rather than using a peer to peer connection."=C2=A0 In ot=
her=20
words, they expect that people should have to pay in order to mitigate this WebRTC security vulnerability, because they are unwilling =
to design to protect all users from it.
In a similar fashion, in the =
second example of the browser based WebRTC version of a decentralized excha=
nge, the user's financial information is periodically exposed as a resu=
lt of the information leakage which is presently caused by WebRTC.=C2=A0 (F=
ortunately, this browser based WebRTC decentralized exchange is under devel=
opment and is not currently open to actual usage.)
Although
 undoubtedly this has been discussed here before, I am asking that WebRTC s=
ecurity issues be
 reconsidered and that a new security review be done to ameliorate or=20
eliminate this problem in terms of WebRTC leaking this information.=C2=A0 I=
t is my view that WebRTC should be further designed and developed with an e=
ye to mitigating this serious problem, so that users of services which migh=
t rely partially or wholly upon WebRTC would not have to be concerned about=
 such information leakage.
Respectfully,
Colin Gallagher


_______________________________________________

rtcweb mailing list

rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb







--94eb2c1b7fd6c912f5055068b2a2--


From nobody Fri May 26 05:48:50 2017
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 852D612426E for ; Fri, 26 May 2017 05:48:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 NnLSL8yXg6tM for ; Fri, 26 May 2017 05:48:44 -0700 (PDT)
Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002: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 78CB51294D2 for ; Fri, 26 May 2017 05:48:44 -0700 (PDT)
Received: by mail-yb0-x22b.google.com with SMTP id 130so2049942ybl.3 for ; Fri, 26 May 2017 05:48:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=glpHLiuM0mKhkCLjGRgxNLaeDBEQkNszAFDYHdlbfKg=; b=o+/qLOLf1/5qzGn4wHJBL36vrP6Q/e1F6uz3rulU7S8pF0VyTX9wkfD9EnHkleX4By rSP0DydbAJFI6g7Zgcsbz9vD8KCg61zC3RSKz2yftgeE2SETGk/65rEf2ovt0Kp3MU8p KmaXOwZFcdsgxLGW3U4oCNlDjNHpijgQAiCCHjlkcSufLn3fcJK6+cfnRMubnF4oXKDP PT7xljwxPpb2xFGhqPlbwoA4JHj+BPfuND3BbEoQ6zTnsUg68/VKru2jkvxvz6T0bDpe 4Pkpxf1BrloMV8YFXDu1FOcWfKNpMu1ZiIp/7K9lKQAS0uvmFvjGFvv/H5YLsIgpTv7j YoUA==
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=glpHLiuM0mKhkCLjGRgxNLaeDBEQkNszAFDYHdlbfKg=; b=k2g5XSuCnx+yZFJ4ZOLpH3VDmKJZw4adut3SxLnbbu5u617OeWOje2/PUVoNTd4X2g wcUifs8NyA6vltOIW3A4LKnm17aeIf4nf/o6dQLmVsvpXkytW4d2Y/tY6Xl8a1F5/Cjg 9b2LOZ/7/hEgkt4AdIucSCHtB8PZsdRQPE26CqyXj1mML/Ko8u2AVIGtVAPUGk8H9M87 ROJpHJWq4WZNat0epdCClImM/hcL5ZliLzHpv9iPn3Hmv/x+ojenGXFJeayTglCWaCJ4 ZMyZC/kF9IRCThtJmdtpEwYj0Kr5r4f9IHzq32+DViwnxLBSS5/ykukC7cax+Wvr1BYM jdMA==
X-Gm-Message-State: AODbwcDFx8M2s7ZX0XwTKBB1P5oasDXxvnArywOmnXMQAPq+RHWxCq3m 2QNgYVVVNPQF1iIdA1QpmMwifQDqWYfF
X-Received: by 10.37.174.32 with SMTP id a32mr20539904ybj.50.1495802923639; Fri, 26 May 2017 05:48:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Fri, 26 May 2017 05:48:03 -0700 (PDT)
In-Reply-To: 
References:   
From: Eric Rescorla 
Date: Fri, 26 May 2017 20:48:03 +0800
Message-ID: 
To: Colin Gallagher 
Cc: Justin Uberti , "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary="f403045dbf82eb09cf05506cc13a"
Archived-At: 
Subject: Re: [rtcweb] Request for New Security Review of WebRTC based on observed vulnerabilities
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, 26 May 2017 12:48:48 -0000

--f403045dbf82eb09cf05506cc13a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Colin,

I'm not really sure what you think the new information is here.

The draft that Justin referred to reflects the consensus view of the RTCWEB
WG
about the best balance between privacy and usability, and yes, it does
result in
the server learning your default RFC 1918 address, so it's not surprising
that
accounts for the results you are seeing with Firefox. If you think there's
a defect
where Firefox isn't conforming to the spec, then you should file a bug, but
otherwise I'm not really seeing what there is for the WG to reconsider

-Ekr


On Fri, May 26, 2017 at 3:58 PM, Colin Gallagher <
colingallagher.rpcv@gmail.com> wrote:

> Justin,
>
> It's my understanding that various browsers have made an attempt to
> conform to the recommendations in the document that you have provided
> .
> Unfortunately, at least in Firefox (the most current version) so far as I
> can tell, there is a serious vulnerability.  To be more specific, the
> problem was observed in my operating system with my current browser, whic=
h
> is Ubuntu 16.10 64-bit with Firefox 53.0.2 (64-bit).  The browser does no=
t
> address the WebRTC problems by default.
>
> The stackexchange page that I cited originally is actually not outdated i=
n
> the sense that its method of measuring whether or not the WebRTC
> vulnerability exists on a given system is still intact and works.  The
> stackexchange page suggests two pages to determine whether or not you hav=
e
> leakage / WebRTC related vulnerability.  These pages are:
>
> 1) Browser leaks test for WebRTC https://browserleaks.com/webrtc
> 2) IP Leaks https://ipleak.net/
>
> Currently for Browser leaks test for WebRTC (due to that I have again
> changed settings in my system so that I will not have to be exposed to th=
is
> vulnerability) the settings show up on the page as:
> RTCPeerConnection=C3=97False
> RTCDataChannel=C3=97False
> ORTC (Microsoft Edge)=C3=97False (for example....)
>
> And under IP leaks, it currently shows "No leak, RTCPeerConnection not
> available."
>
> *That is because:*
>
> (A) I have (again) changed my settings in about:config back to the
> following
>
>
>    1. I typed *about:config* in the address bar
>    2. I found the setting *media.peerconnection.enabled*
>    3. I set it to *false  (it was previously set at true, so as to allow
>    WebRTC to work, but this exposed information which I would not have wa=
nted
>    to be exposed)*
>
> (B) And I also have changed my settings back to the following
>
> in the WebRTC 0.1.3 extension for Firefox I have set it to no longer
> expose my real IP address as well as no longer allowing the following:
>
> a. navigator.getUserMedia
> b. window.MediaStreamTrack
> c. window.RTCPeerConnection
> d. window.RTCSessionDescription
>
> To be clear, *these mitigations that I have employed above would be
> unnecessary if WebRTC had not been designed in such a manner that it so
> clearly exposes so much user information.*
>
> In the document you provided
> , titled
> "WebRTC IP Address Handling Requirements - draft-ietf-rtcweb-ip-handling-=
03,"
> it is stated that:
>
> *"1. If the client is behind a NAT, the client's private IP addresses,
> typically [RFC1918 ] addresses, can =
be
> learned. *
>
>
>
> * 2.  If the client tries to hide its physical location through a VPN,
>        and the VPN and local OS support routing over multiple interfaces
>        (i.e., a "split-tunnel" VPN), WebRTC will discover the public
>        address for the VPN as well as the ISP public address that the
>        VPN runs over.
>
>    3.  If the client is behind a proxy (a client-configured "classical
>        application proxy", as defined in [RFC1919], Section 3 ), but
>        direct access to the Internet is also supported, WebRTC's STUN
>        [RFC5389 ]checks will bypass =
the proxy and reveal the public
>        address of the client."*
>
> All of these are obvious vulnerabilities and serious problems (not only #=
2 as the document suggests).
>
> It is stated in the document that,
>
>
>
> *"we want to avoid solutions that disable WebRTC or make it harder to use=
."*
>
> Yet, so far as my observations of WebRTC in the current version of Firefo=
x with Ubuntu 16.10 have shown,
>
> there appears to be no other choice other than to disable WebRTC because =
its use completely compromises
>
> privacy and thus makes all other aspects of your system more difficult ge=
nerally.
>
> It is stated in the document you cited that the goals here are to "Provid=
e a privacy-friendly default behavior which strikes the
>       right balance between privacy and media performance for most users
>       and use cases. (and) For users who care more about one versus the o=
ther, provide a
>       means to customize the experience."
>
> This has clearlly not been accomplished in the context of Ubuntu 16.10 64=
-bit with Firefox 53.0.2 (64-bit).
>
> Hence my request for a new security review of WebRTC based on observed vu=
lnerabilities.
>
>
>
>
> On Thu, May 25, 2017 at 1:04 PM, Justin Uberti  wrote=
:
>
>> Colin,
>>
>> This is an important topic, and the group has reviewed this situation in
>> detail. The results have been written up in this document
>> , and to
>> my knowledge most browsers that support WebRTC currently conform to its
>> recommendations.
>>
>> However, I'm not totally clear on your specific technical concern. You
>> linked to an (now outdated) stackexchange page, but could you provide mo=
re
>> detail about the specific situation you are concerned about?
>>
>> Justin
>>
>> On Wed, May 24, 2017 at 5:35 PM, Colin Gallagher <
>> colingallagher.rpcv@gmail.com> wrote:
>>
>>> To:  IETF RTCWeb WG
>>>
>>> From:  Colin Gallagher
>>>            https://www.linkedin.com/in/colingallagher
>>>            https://lifeboat.com/ex/bios.colin.gallagher
>>>
>>> Request for New Security Review of WebRTC based on observed
>>> vulnerabilities in certain examples
>>>
>>> Dear IETF RTCWeb WG,
>>>
>>> This request relates to WebRTC.  The WebRTC is in draft at
>>> https://w3c.github.io/webrtc-pc/ and is described also at
>>> https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API#
>>> WebRTC_interfaces
>>>
>>> There are certain examples where the use of WebRTC has presented
>>> security vulnerabilities.  While not exhaustive, there are two I wanted=
 to
>>> mention that I had been exposed to recently.
>>>
>>> 1) The use of a video conferencing service which relies upon WebRTC
>>> (that is a well established service)
>>> 2) The examination of a browser based WebRTC version of a decentralized
>>> exchange (that is currently under development)
>>>
>>> In both cases the security vulnerability which is described below was
>>> the result of the use of WebRTC.
>>>
>>> The problem under consideration is as follows:
>>>
>>> As per the first example (the video conferencing service), recently I
>>> came upon a vendor who shall remain unnamed who uses WebRTC as the back=
bone
>>> for their video conferencing service.  As a result, I found I was unabl=
e to
>>> access the service in question without disabling some security settings
>>> which I would have preferred to leave intact.
>>>
>>> My system is (based on what the aforementioned service detects)
>>> Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101
>>> Firefox/53.0.  This is Ubuntu 16.10 64-bit with Firefox 53.0.2.
>>>
>>> However, quite some *long* while back I disabled WebRTC because of the
>>> security vulnerability (described in part here on information security
>>> stack exchange
>>> ).
>>> So as to mitigate this vulnerability, I changed settings in Firefox as
>>> follows:
>>>
>>>
>>>    1. I typed *about:config* in the address bar
>>>    2. I found the setting *media.peerconnection.enabled*
>>>    3. I set it to *false*
>>>
>>> Unfortunately, this setting does not allow Firefox to work with the
>>> video conferencing service in question, which relies entirely on WebRTC=
.
>>>
>>> So I had to go back in and change the media.peerconnection.enabled
>>> setting to *true* in Firefox in order to get it to work with the
>>> service in question. While this enabled me to conference with teams tha=
t
>>> desire to use the video conferencing service that rely wholly upon WebR=
TC,
>>> it concerns me because of the security vulnerability.
>>>
>>> One suggested mitigation was having NoScript, but using NoScript was no=
t
>>> helpful (you generally need to disable it for the site you are viewing =
that
>>> relies upon WebRTC, in order to obtain any functionality, and whether
>>> NoScript is off or on, WebRTC still causes the vulnerability of leaking
>>> information as previously described).
>>>
>>> Furthermore, upon reload of the browser, even after setting
>>> media.peerconnection.enabled to *true*, the video conferencing service
>>> wouldn't work until I installed the WebRTC 0.1.3 extension for Firefox =
and
>>> set it to expose my real IP address as well as allowing the following:
>>>
>>> a. navigator.getUserMedia
>>> b. window.MediaStreamTrack
>>> c. window.RTCPeerConnection
>>> d. window.RTCSessionDescription
>>>
>>> That seemed to me to be a direct consequence of the persistent and
>>> ongoing security vulnerability in WebRTC.
>>>
>>> I contacted the video conferencing service provider and their solution
>>> was simply to state that "If the peer to peer connection is of concern,=
 you
>>> can utilize our premium version which will route traffic through a
>>> forwarding server with in our environment that handles the processing o=
f
>>> the video and sound of all users in the conference and send it to each =
user
>>> individually rather than using a peer to peer connection."  In other wo=
rds,
>>> they expect that people should have to pay in order to mitigate this
>>> WebRTC security vulnerability
>>> ,
>>> because they are unwilling to design to protect all users from it.
>>>
>>> In a similar fashion, in the second example of the browser based WebRTC
>>> version of a decentralized exchange, the user's financial information i=
s
>>> periodically exposed as a result of the information leakage which is
>>> presently caused by WebRTC.  (Fortunately, this browser based WebRTC
>>> decentralized exchange is under development and is not currently open t=
o
>>> actual usage.)
>>>
>>> Although undoubtedly this has been discussed here before, I am asking
>>> that WebRTC security issues be reconsidered and that a new security rev=
iew
>>> be done to ameliorate or eliminate this problem in terms of WebRTC leak=
ing
>>> this information.  It is my view that WebRTC should be further designed=
 and
>>> developed with an eye to mitigating this serious problem, so that users=
 of
>>> services which might rely partially or wholly upon WebRTC would not hav=
e to
>>> be concerned about such information leakage.
>>>
>>> Respectfully,
>>> Colin Gallagher
>>>
>>>
>>> _______________________________________________
>>> 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
>
>

--f403045dbf82eb09cf05506cc13a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Colin,

I'm not really sure what you=
 think the new information is here.

The draft that=
 Justin referred to reflects the consensus view of the RTCWEB WG
=
about the best balance between privacy and usability, and yes, it does resu=
lt in
the server learning your default RFC 1918 address, so it=
9;s not surprising that
accounts for the results you are seeing w=
ith Firefox. If you think there's a defect
where Firefox isn&=
#39;t conforming to the spec, then you should file a bug, but
oth=
erwise I'm not really seeing what there is for the WG to reconsider

-Ekr


On Fri, May 26, 2017 at 3:58 PM, Colin =
Gallagher <colingallagher.rpcv@gmail.com> wrote:=

Justin,

It's my understanding that variou=
s browsers have made an attempt to conform to the recommendations in the document that you have provided.=C2=A0 Unfortunately, a=
t least in Firefox (the most current version) so far as I can tell, there i=
s a serious vulnerability.=C2=A0 To be more specific, the problem was obser=
ved in my operating system with my current browser, which is Ubuntu 16.10 6=
4-bit with Firefox=20
53.0.2 (64-bit).=C2=A0 The browser does not address the WebRTC problems by =
default.

The stackexchange page that I cited originally is act=
ually not outdated in the sense that its method of measuring whether or not=
 the WebRTC vulnerability exists on a given system is still intact and work=
s.=C2=A0 The stackexchange page suggests two pages to determine whether or =
not you have leakage / WebRTC related vulnerability.=C2=A0 These pages are:=


1) Browser leaks test for WebRTC https://browserleaks.com/webrtc<=
br>
2) IP Leaks http=
s://ipleak.net/

Currently for Browser leaks test for WebRT=
C (due to that I have again changed settings in my system so that I will no=
t have to be exposed to this vulnerability) the settings show up on the pag=
e as:
RTCPeerConnection=
=C3=97False
RTCDataChannel=C3=97False
ORTC (Microsoft Edge)=C3=97False (for example....)

An=
d under IP leaks, it currently shows "No leak, RTCPeerConnection not a=
vailable."=C2=A0 

That is because:

(A=
) I have (again) changed my settings in about:config back to the following<=
br>
  1. I typed about:config in the addres=
s bar
  2. I found the setting media.peerconnection.enabled
  3. I set it to false=C2=A0 (it was previously set at true,=
 so as to allow WebRTC to work, but this exposed information which I would =
not have wanted to be exposed)
(B) And I also have cha=
nged my settings back to the following
in the WebRTC 0.1.3 extension =
for Firefox I have set it to no longer expose my real IP=20
address as well as no longer allowing the following:
a. navigator.getUserMedia
b. window.MediaStreamTrack
c. window.RTCPe=
erConnection
d. window.RTCSessionDescription
To be clear, <=
b>these mitigations that I have employed above would be unnecessary if WebR=
TC had not been designed in such a manner that it so clearly exposes so muc=
h user information.
In the document you provided<=
/a>, titled "WebRTC IP Address Handling Requirements - draft-ietf-rtcw=
eb-ip-handling-03," it is stated that:
"1.  If the client is behind a N=
AT, the client's private IP addresses, typically [RFC1918] addresses, can be learned.

 2.  If the client tries to=
 hide its physical location through a VPN,
       and the VPN and local OS support routing over multiple interfaces
       (i.e., a "split-tunnel" VPN), WebRTC will discover the pub=
lic
       address for the VPN as well as the ISP public address that the
       VPN runs over.

   3.  If the client is behind a proxy (a client-configured "classical
       application proxy", as defined in [RFC1919], Section=C2=A03), but
       direct access to the Internet is also supported, WebRTC's STUN
       [RFC5389=
]checks will bypass the proxy and reveal the public
       address of the client."

All of these are obvious vulnerabilities and serious problem=
s (not only #2 as the document suggests).

It is stated in the document that, 

"we wan=
t to avoid solutions that disable WebRTC or make it harder to use."
Yet, so far as my obser=
vations of WebRTC in the current version of Firefox with Ubuntu 16.10 have =
shown,
there appears to be no=
 other choice other than to disable WebRTC because its use completely compr=
omises 
<=
span style=3D"font-family:arial,helvetica,sans-serif">privacy and thus make=
s all other aspects of your system more difficult generally.  

It is stated in the document you cite=
d that the goals here are to "Provide a privacy-friendly defaul=
t behavior which strikes the
      right balance between privacy and media performance for most users
      and use cases. (and) For users who care more about one versus the oth=
er, provide a
      means to customize the experience."
This has clearlly not been accomplished in the context of Ubuntu 16.=
10 64-bit with Firefox 53.0.2 (64-bit).

Hence my request for a new security review of WebRTC based o=
n observed vulnerabilities.

<=
div>


On =
Thu, May 25, 2017 at 1:04 PM, Justin Uberti <juberti@google.com>=
 wrote:
Colin,
This is an important topic, and the group has reviewed thi=
s situation in detail. The results have been written up in =
this document, and to my knowledge most browsers that support WebRTC cu=
rrently conform to its recommendations.

However, I=
'm not totally clear on your specific technical concern. You linked to =
an (now outdated) stackexchange page, but could you provide more detail abo=
ut the specific situation you are concerned about?

Justin

On Wed, May 24, 2017 at 5:35 =
PM, Colin Gallagher <colingallagher.rpcv@gmail.com>=
; wrote:
To:=C2=A0 IETF RTCWeb WG

From:=C2=A0 Colin Gallag=
her
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
a href=3D"https://www.linkedin.com/in/colingallagher" target=3D"_blank">htt=
ps://www.linkedin.com/in/colingallagher
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://lifeboat.com/ex/bios.c=
olin.gallagher

Request for New Security Review of WebRTC b=
ased on observed vulnerabilities in certain examples

Dear IETF=
 RTCWeb WG,

This request relates to WebRTC.=C2=A0 The Web=
RTC is in draft at https://w3c.github.io/webrtc-pc/ and is=20
described also at=20
https://developer.mozilla.org/en-US/d=
ocs/Web/API/WebRTC_API#WebRTC_interfaces

There=
 are certain examples where the use of WebRTC has presented security vulner=
abilities.=C2=A0 While not exhaustive, there are two I wanted to mention th=
at I had been exposed to recently.

1) The use of a =
video conferencing service which relies upon WebRTC (that is a well establi=
shed service)
2) The examination of a browser based WebRTC version=
 of a decentralized exchange (that is currently under development)

<=
/div>In both cases the security vulnerability which is described below was =
the result of the use of WebRTC.

The problem under consideration is =
as follows:

As per the first example (the video conferencing service=
), recently
 I came upon a vendor who shall remain unnamed who uses WebRTC as the=20
backbone for their video conferencing service.=C2=A0 As a result, I found I=
=20
was unable to access the service in question without disabling some=20
security settings which I would have preferred to leave intact. 

My =
system is (based on what the aforementioned service detects) Mozilla/5.0 (X=
11; Ubuntu; Linux x86_64; rv:53.0)=20
Gecko/20100101 Firefox/53.0.=C2=A0 This is Ubuntu 16.10 64-bit with Firefox=
=20
53.0.2.

However, quite some long while back I disabled WebRTC=
 because of the security vulnerability (described in part here =
on information security stack exchange).=C2=A0 So as to mitigate this v=
ulnerability, I changed settings in Firefox as follows:

  1. I ty=
ped about:config in the address bar
  2. I found the setting media.peerconnection.enabled
  3. I set it to false
Unfortunately,
 this setting does not allow Firefox to work with the video conferencing
 service in question, which relies entirely on WebRTC.
So I had t=
o go back in and change the media.peerconnection.enabled setting to true=

 in Firefox in order to get it to work with the service in question.=20
While this enabled me to conference with teams that desire to use the=20
video conferencing service that rely wholly upon WebRTC, it concerns me=20
because of the security vulnerability.
One suggested mitigation was h=
aving NoScript, but using NoScript was not helpful (you generally need to d=
isable it for the site you are viewing that relies upon WebRTC, in order to=
 obtain any functionality, and whether NoScript is off or on, WebRTC still =
causes the vulnerability of leaking information as previously described).
Furthermore, upon reload of the browser, even after setting media.=
peerconnection.enabled to true,
 the video conferencing service wouldn't work until I installed the=20
WebRTC 0.1.3 extension for Firefox and set it to expose my real IP=20
address as well as allowing the following:
a. navigator.getUserMedia<=
br>b. window.MediaStreamTrack
c. window.RTCPeerConnection
d. window.R=
TCSessionDescription
That seemed to me to be a direct consequence=
 of the persistent and ongoing security vulnerability in WebRTC.
=
I
 contacted the video conferencing service provider and their solution=20
was simply to state that "If the peer to peer connection is of concern=
,=20
you can utilize our=20
premium version which will route traffic through a forwarding server=20
with in our environment that handles the processing of the video and=20
sound of all users in the conference and send it to each user=20
individually rather than using a peer to peer connection."=C2=A0 In ot=
her=20
words, they expect that people should have to pay in order to mitigate this WebRTC security vulnerability, because they are unwilling =
to design to protect all users from it.
In a similar fashion, in the =
second example of the browser based WebRTC version of a decentralized excha=
nge, the user's financial information is periodically exposed as a resu=
lt of the information leakage which is presently caused by WebRTC.=C2=A0 (F=
ortunately, this browser based WebRTC decentralized exchange is under devel=
opment and is not currently open to actual usage.)
Although
 undoubtedly this has been discussed here before, I am asking that WebRTC s=
ecurity issues be
 reconsidered and that a new security review be done to ameliorate or=20
eliminate this problem in terms of WebRTC leaking this information.=C2=A0 I=
t is my view that WebRTC should be further designed and developed with an e=
ye to mitigating this serious problem, so that users of services which migh=
t rely partially or wholly upon WebRTC would not have to be concerned about=
 such information leakage.
Respectfully,
Colin Gallagher


_______________________________________________

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

--f403045dbf82eb09cf05506cc13a-- From nobody Fri May 26 05:53:22 2017 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 5D9F61294DC for ; Fri, 26 May 2017 05:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ghZPb-V3a3Dj for ; Fri, 26 May 2017 05:53:17 -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 DA91812426E for ; Fri, 26 May 2017 05:53:16 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id b84so128017042wmh.0 for ; Fri, 26 May 2017 05:53:16 -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; bh=y7PNPkrBS6sra5sjkXVYb6RG2d3/VZfKxQt0EqqvKvg=; b=leF2EEPeAr4C+JTG9tNmnuQDLDmGOthgDVBrkIynPxVM3Ng2IWDO36melP8LlVKQMq nBzZefwzAS6OVxaUOroOoTBz+z60Sc2V4SJ7nQnkrEzpi2WVJAabQ1wgoAtharRmWa9J wQLCejVLaYsIchMESlyqv9avDodwHoiq5bKdFZJMgkDoEVjhvO6m5rhk0I7GdGBomS5C E2y4JXaxw1HgQKVYFvZg5t3VgPuMrNPNj19O9O3v6pLEtJ/+zw47od+vMENjVXIylccF ctMsf0Zp6gqcOXimdJhtMGDwPkqZyTpRHGbyr8fCIgLNn6IFQjgZncEKYirrLcw2L2jP Upwg== 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=y7PNPkrBS6sra5sjkXVYb6RG2d3/VZfKxQt0EqqvKvg=; b=no/xLa8eD07rNl284HnxAzx70awZkqjWcduqvbn6nzd/BsV94FHIZ30NEGg5Hac2DB kfDlHRCXHUOT1IXKlRzdEbyvinAXpxKMEa99FI4RVG41Z71B7zL8ZvI7xfNEYHeKMj/C csh1SJMPpqsVIPmh47m09TigzKLBdpmhHTFuvbJSs5xid1tQ9+jswtalrKAWi31PP2BW EqNsXFUHo0EyKq8iZ7cfVhLDNBIBxT1YoQq0tiVmKO1FtyWYf8YWKUGfOZgjOAaohOwJ Q7RH+NizBU4Ne9eDzK6vdlECD1GBNrSuqHsxBvjIOAH5FcqA5xe3iaz+upvMpmtQE5xE od4Q== X-Gm-Message-State: AODbwcDyGHk4XqZPFeqan0jxVMPTwcCaTzXISx47HRNM+l1aIKg8Ln3A zM9GF8xmlf8KTACxlUvZXJIW94JhEEIP X-Received: by 10.80.165.23 with SMTP id y23mr2270968edb.64.1495803195385; Fri, 26 May 2017 05:53:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.146.136 with HTTP; Fri, 26 May 2017 05:53:14 -0700 (PDT) Received: by 10.80.146.136 with HTTP; Fri, 26 May 2017 05:53:14 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 26 May 2017 14:53:14 +0200 Message-ID: To: Colin Gallagher Cc: Justin Uberti , rtcweb@ietf.org Content-Type: multipart/alternative; boundary="f403045c1c801d801105506cd253" Archived-At: Subject: Re: [rtcweb] Request for New Security Review of WebRTC based on observed vulnerabilities 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, 26 May 2017 12:53:20 -0000 --f403045c1c801d801105506cd253 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It seems to me that you don't want WebRTC. For WebRTC to work IPs must be exposed. So not sure what you are asking for. El 26/5/2017 9:58, "Colin Gallagher" escribi=C3=B3: > Justin, > > It's my understanding that various browsers have made an attempt to > conform to the recommendations in the document that you have provided > . > Unfortunately, at least in Firefox (the most current version) so far as I > can tell, there is a serious vulnerability. To be more specific, the > problem was observed in my operating system with my current browser, whic= h > is Ubuntu 16.10 64-bit with Firefox 53.0.2 (64-bit). The browser does no= t > address the WebRTC problems by default. > > The stackexchange page that I cited originally is actually not outdated i= n > the sense that its method of measuring whether or not the WebRTC > vulnerability exists on a given system is still intact and works. The > stackexchange page suggests two pages to determine whether or not you hav= e > leakage / WebRTC related vulnerability. These pages are: > > 1) Browser leaks test for WebRTC https://browserleaks.com/webrtc > 2) IP Leaks https://ipleak.net/ > > Currently for Browser leaks test for WebRTC (due to that I have again > changed settings in my system so that I will not have to be exposed to th= is > vulnerability) the settings show up on the page as: > RTCPeerConnection=C3=97False > RTCDataChannel=C3=97False > ORTC (Microsoft Edge)=C3=97False (for example....) > > And under IP leaks, it currently shows "No leak, RTCPeerConnection not > available." > > *That is because:* > > (A) I have (again) changed my settings in about:config back to the > following > > > 1. I typed *about:config* in the address bar > 2. I found the setting *media.peerconnection.enabled* > 3. I set it to *false (it was previously set at true, so as to allow > WebRTC to work, but this exposed information which I would not have wa= nted > to be exposed)* > > (B) And I also have changed my settings back to the following > > in the WebRTC 0.1.3 extension for Firefox I have set it to no longer > expose my real IP address as well as no longer allowing the following: > > a. navigator.getUserMedia > b. window.MediaStreamTrack > c. window.RTCPeerConnection > d. window.RTCSessionDescription > > To be clear, *these mitigations that I have employed above would be > unnecessary if WebRTC had not been designed in such a manner that it so > clearly exposes so much user information.* > > In the document you provided > , titled > "WebRTC IP Address Handling Requirements - draft-ietf-rtcweb-ip-handling-= 03," > it is stated that: > > *"1. If the client is behind a NAT, the client's private IP addresses, > typically [RFC1918 ] addresses, can = be > learned. * > > > > * 2. If the client tries to hide its physical location through a VPN, > and the VPN and local OS support routing over multiple interfaces > (i.e., a "split-tunnel" VPN), WebRTC will discover the public > address for the VPN as well as the ISP public address that the > VPN runs over. > > 3. If the client is behind a proxy (a client-configured "classical > application proxy", as defined in [RFC1919], Section 3 ), but > direct access to the Internet is also supported, WebRTC's STUN > [RFC5389 ]checks will bypass = the proxy and reveal the public > address of the client."* > > All of these are obvious vulnerabilities and serious problems (not only #= 2 as the document suggests). > > It is stated in the document that, > > > > *"we want to avoid solutions that disable WebRTC or make it harder to use= ."* > > Yet, so far as my observations of WebRTC in the current version of Firefo= x with Ubuntu 16.10 have shown, > > there appears to be no other choice other than to disable WebRTC because = its use completely compromises > > privacy and thus makes all other aspects of your system more difficult ge= nerally. > > It is stated in the document you cited that the goals here are to "Provid= e a privacy-friendly default behavior which strikes the > right balance between privacy and media performance for most users > and use cases. (and) For users who care more about one versus the o= ther, provide a > means to customize the experience." > > This has clearlly not been accomplished in the context of Ubuntu 16.10 64= -bit with Firefox 53.0.2 (64-bit). > > Hence my request for a new security review of WebRTC based on observed vu= lnerabilities. > > > > > On Thu, May 25, 2017 at 1:04 PM, Justin Uberti wrote= : > >> Colin, >> >> This is an important topic, and the group has reviewed this situation in >> detail. The results have been written up in this document >> , and to >> my knowledge most browsers that support WebRTC currently conform to its >> recommendations. >> >> However, I'm not totally clear on your specific technical concern. You >> linked to an (now outdated) stackexchange page, but could you provide mo= re >> detail about the specific situation you are concerned about? >> >> Justin >> >> On Wed, May 24, 2017 at 5:35 PM, Colin Gallagher < >> colingallagher.rpcv@gmail.com> wrote: >> >>> To: IETF RTCWeb WG >>> >>> From: Colin Gallagher >>> https://www.linkedin.com/in/colingallagher >>> https://lifeboat.com/ex/bios.colin.gallagher >>> >>> Request for New Security Review of WebRTC based on observed >>> vulnerabilities in certain examples >>> >>> Dear IETF RTCWeb WG, >>> >>> This request relates to WebRTC. The WebRTC is in draft at >>> https://w3c.github.io/webrtc-pc/ and is described also at >>> https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API# >>> WebRTC_interfaces >>> >>> There are certain examples where the use of WebRTC has presented >>> security vulnerabilities. While not exhaustive, there are two I wanted= to >>> mention that I had been exposed to recently. >>> >>> 1) The use of a video conferencing service which relies upon WebRTC >>> (that is a well established service) >>> 2) The examination of a browser based WebRTC version of a decentralized >>> exchange (that is currently under development) >>> >>> In both cases the security vulnerability which is described below was >>> the result of the use of WebRTC. >>> >>> The problem under consideration is as follows: >>> >>> As per the first example (the video conferencing service), recently I >>> came upon a vendor who shall remain unnamed who uses WebRTC as the back= bone >>> for their video conferencing service. As a result, I found I was unabl= e to >>> access the service in question without disabling some security settings >>> which I would have preferred to leave intact. >>> >>> My system is (based on what the aforementioned service detects) >>> Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 >>> Firefox/53.0. This is Ubuntu 16.10 64-bit with Firefox 53.0.2. >>> >>> However, quite some *long* while back I disabled WebRTC because of the >>> security vulnerability (described in part here on information security >>> stack exchange >>> ). >>> So as to mitigate this vulnerability, I changed settings in Firefox as >>> follows: >>> >>> >>> 1. I typed *about:config* in the address bar >>> 2. I found the setting *media.peerconnection.enabled* >>> 3. I set it to *false* >>> >>> Unfortunately, this setting does not allow Firefox to work with the >>> video conferencing service in question, which relies entirely on WebRTC= . >>> >>> So I had to go back in and change the media.peerconnection.enabled >>> setting to *true* in Firefox in order to get it to work with the >>> service in question. While this enabled me to conference with teams tha= t >>> desire to use the video conferencing service that rely wholly upon WebR= TC, >>> it concerns me because of the security vulnerability. >>> >>> One suggested mitigation was having NoScript, but using NoScript was no= t >>> helpful (you generally need to disable it for the site you are viewing = that >>> relies upon WebRTC, in order to obtain any functionality, and whether >>> NoScript is off or on, WebRTC still causes the vulnerability of leaking >>> information as previously described). >>> >>> Furthermore, upon reload of the browser, even after setting >>> media.peerconnection.enabled to *true*, the video conferencing service >>> wouldn't work until I installed the WebRTC 0.1.3 extension for Firefox = and >>> set it to expose my real IP address as well as allowing the following: >>> >>> a. navigator.getUserMedia >>> b. window.MediaStreamTrack >>> c. window.RTCPeerConnection >>> d. window.RTCSessionDescription >>> >>> That seemed to me to be a direct consequence of the persistent and >>> ongoing security vulnerability in WebRTC. >>> >>> I contacted the video conferencing service provider and their solution >>> was simply to state that "If the peer to peer connection is of concern,= you >>> can utilize our premium version which will route traffic through a >>> forwarding server with in our environment that handles the processing o= f >>> the video and sound of all users in the conference and send it to each = user >>> individually rather than using a peer to peer connection." In other wo= rds, >>> they expect that people should have to pay in order to mitigate this >>> WebRTC security vulnerability >>> , >>> because they are unwilling to design to protect all users from it. >>> >>> In a similar fashion, in the second example of the browser based WebRTC >>> version of a decentralized exchange, the user's financial information i= s >>> periodically exposed as a result of the information leakage which is >>> presently caused by WebRTC. (Fortunately, this browser based WebRTC >>> decentralized exchange is under development and is not currently open t= o >>> actual usage.) >>> >>> Although undoubtedly this has been discussed here before, I am asking >>> that WebRTC security issues be reconsidered and that a new security rev= iew >>> be done to ameliorate or eliminate this problem in terms of WebRTC leak= ing >>> this information. It is my view that WebRTC should be further designed= and >>> developed with an eye to mitigating this serious problem, so that users= of >>> services which might rely partially or wholly upon WebRTC would not hav= e to >>> be concerned about such information leakage. >>> >>> Respectfully, >>> Colin Gallagher >>> >>> >>> _______________________________________________ >>> 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 > > --f403045c1c801d801105506cd253 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It seems to me that you don't want WebRTC. For WebRTC= to work IPs must be exposed. So not sure what you are asking for.

El 26/5/2017 9:58, &= quot;Colin Gallagher" <colingallagher.rpcv@gmail.com> escribi=C3=B3:
=
Justin,

It's my understanding that var= ious browsers have made an attempt to conform to the recommendations in the document that you have provided.=C2=A0 Unfortunately, = at least in Firefox (the most current version) so far as I can tell, there = is a serious vulnerability.=C2=A0 To be more specific, the problem was obse= rved in my operating system with my current browser, which is Ubuntu 16.10 = 64-bit with Firefox=20 53.0.2 (64-bit).=C2=A0 The browser does not address the WebRTC problems by = default.

The stackexchange page that I cited originally is act= ually not outdated in the sense that its method of measuring whether or not= the WebRTC vulnerability exists on a given system is still intact and work= s.=C2=A0 The stackexchange page suggests two pages to determine whether or = not you have leakage / WebRTC related vulnerability.=C2=A0 These pages are:=

1) Browser leaks test for WebRTC https://browserleaks.com/webrtc<= br>
2) IP Leaks http= s://ipleak.net/

Currently for Browser leaks test for WebRT= C (due to that I have again changed settings in my system so that I will no= t have to be exposed to this vulnerability) the settings show up on the pag= e as:
RTCPeerConnection= =C3=97False
RTCDataChannel=C3=97False
ORTC (Microsoft Edge)=C3=97False (for example....)

An= d under IP leaks, it currently shows "No leak, RTCPeerConnection not a= vailable."=C2=A0

That is because:

(A= ) I have (again) changed my settings in about:config back to the following<= br>
  1. I typed about:config in the address bar
  2. I f= ound the setting media.peerconnection.enabled
  3. I set it to = false=C2=A0 (it was previously set at true, so as to allow WebRTC t= o work, but this exposed information which I would not have wanted to be ex= posed)

(B) And I also have changed my settings back to= the following

in the WebRTC 0.1.3 extension for Firefox I have set i= t to no longer expose my real IP=20 address as well as no longer allowing the following:

a. navigator.get= UserMedia
b. window.MediaStreamTrack
c. window.RTCPeerConnection
d= . window.RTCSessionDescription

To be clear, these mitigations that= I have employed above would be unnecessary if WebRTC had not been designed= in such a manner that it so clearly exposes so much user information.<= /p>

In the document you provided, titled "WebRTC= IP Address Handling Requirements - draft-ietf-rtcweb-ip-handling-03,&= quot; it is stated that:

"1. If the client is behind a NAT, the client's pri= vate IP addresses, typically [RFC1918] addresses, can be learned. 

 2.  If the client tries to=
 hide its physical location through a VPN,
       and the VPN and local OS support routing over multiple interfaces
       (i.e., a "split-tunnel" VPN), WebRTC will discover the pub=
lic
       address for the VPN as well as the ISP public address that the
       VPN runs over.

   3.  If the client is behind a proxy (a client-configured "classical
       application proxy", as defined in [RFC1919], Section=C2=A03), but
       direct access to the Internet is also supported, WebRTC's STUN
       [RFC5389=
]checks will bypass the proxy and reveal the public
       address of the client."

All of these are obvious vulnerabilities and serious problem=
s (not only #2 as the document suggests).

It is stated in the document that, 

"we wan=
t to avoid solutions that disable WebRTC or make it harder to use."
Yet, so far as my obser=
vations of WebRTC in the current version of Firefox with Ubuntu 16.10 have =
shown,
there appears to be no=
 other choice other than to disable WebRTC because its use completely compr=
omises 
<=
span style=3D"font-family:arial,helvetica,sans-serif">privacy and thus make=
s all other aspects of your system more difficult generally.  

It is stated in the document you cite=
d that the goals here are to "Provide a privacy-friendly defaul=
t behavior which strikes the
      right balance between privacy and media performance for most users
      and use cases. (and) For users who care more about one versus the oth=
er, provide a
      means to customize the experience."
This has clearlly not been accomplished in the context of Ubuntu 16.=
10 64-bit with Firefox 53.0.2 (64-bit).

Hence my request for a new security review of WebRTC based o=
n observed vulnerabilities.


<= div>


On Thu, May 25, 2017 at 1:04 PM, Justin Ube= rti <juberti@google.com> wrote:
Colin,

This is an important topi= c, and the group has reviewed this situation in detail. The results have be= en written up in this document, and to my knowledge mos= t browsers that support WebRTC currently conform to its recommendations.

However, I'm not totally clear on your specific = technical concern. You linked to an (now outdated) stackexchange page, but = could you provide more detail about the specific situation you are concerne= d about?

Justin

On Wed, May 24, 2017 at 5:35 PM, Colin Gallagher <= colingal= lagher.rpcv@gmail.com> wrote:
To:=C2=A0 IETF RTCWeb WG
<= br>
From:=C2=A0 Colin Gallagher
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.linkedin.com/in/colingalla= gher
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ht= tps://lifeboat.com/ex/bios.colin.gallagher

Request fo= r New Security Review of WebRTC based on observed vulnerabilities in certai= n examples

Dear IETF RTCWeb WG,

This request= relates to WebRTC.=C2=A0 The WebRTC is in draft at https://w3c.github.io/webrtc-p= c/ and is=20 described also at=20 https://developer.mozilla.org/en-US/d= ocs/Web/API/WebRTC_API#WebRTC_interfaces

There= are certain examples where the use of WebRTC has presented security vulner= abilities.=C2=A0 While not exhaustive, there are two I wanted to mention th= at I had been exposed to recently.

1) The use of a = video conferencing service which relies upon WebRTC (that is a well establi= shed service)
2) The examination of a browser based WebRTC version= of a decentralized exchange (that is currently under development)

<= /div>In both cases the security vulnerability which is described below was = the result of the use of WebRTC.

The problem under consideration is = as follows:

As per the first example (the video conferencing service= ), recently I came upon a vendor who shall remain unnamed who uses WebRTC as the=20 backbone for their video conferencing service.=C2=A0 As a result, I found I= =20 was unable to access the service in question without disabling some=20 security settings which I would have preferred to leave intact.

My = system is (based on what the aforementioned service detects) Mozilla/5.0 (X= 11; Ubuntu; Linux x86_64; rv:53.0)=20 Gecko/20100101 Firefox/53.0.=C2=A0 This is Ubuntu 16.10 64-bit with Firefox= =20 53.0.2.

However, quite some long while back I disabled WebRTC= because of the security vulnerability (described in part here = on information security stack exchange).=C2=A0 So as to mitigate this v= ulnerability, I changed settings in Firefox as follows:

  1. I ty= ped about:config in the address bar
  2. I found the setting media.peerconnection.enabled
  3. I set it to false

Unfortunately, this setting does not allow Firefox to work with the video conferencing service in question, which relies entirely on WebRTC.

So I had t= o go back in and change the media.peerconnection.enabled setting to true= in Firefox in order to get it to work with the service in question.=20 While this enabled me to conference with teams that desire to use the=20 video conferencing service that rely wholly upon WebRTC, it concerns me=20 because of the security vulnerability.

One suggested mitigation was h= aving NoScript, but using NoScript was not helpful (you generally need to d= isable it for the site you are viewing that relies upon WebRTC, in order to= obtain any functionality, and whether NoScript is off or on, WebRTC still = causes the vulnerability of leaking information as previously described).

Furthermore, upon reload of the browser, even after setting media.= peerconnection.enabled to true, the video conferencing service wouldn't work until I installed the=20 WebRTC 0.1.3 extension for Firefox and set it to expose my real IP=20 address as well as allowing the following:

a. navigator.getUserMedia<= br>b. window.MediaStreamTrack
c. window.RTCPeerConnection
d. window.R= TCSessionDescription

That seemed to me to be a direct consequence= of the persistent and ongoing security vulnerability in WebRTC.

= I contacted the video conferencing service provider and their solution=20 was simply to state that "If the peer to peer connection is of concern= ,=20 you can utilize our=20 premium version which will route traffic through a forwarding server=20 with in our environment that handles the processing of the video and=20 sound of all users in the conference and send it to each user=20 individually rather than using a peer to peer connection."=C2=A0 In ot= her=20 words, they expect that people should have to pay in order to mitigate this WebRTC security vulnerability, because they are unwilling = to design to protect all users from it.

In a similar fashion, in the = second example of the browser based WebRTC version of a decentralized excha= nge, the user's financial information is periodically exposed as a resu= lt of the information leakage which is presently caused by WebRTC.=C2=A0 (F= ortunately, this browser based WebRTC decentralized exchange is under devel= opment and is not currently open to actual usage.)

Although undoubtedly this has been discussed here before, I am asking that WebRTC s= ecurity issues be reconsidered and that a new security review be done to ameliorate or=20 eliminate this problem in terms of WebRTC leaking this information.=C2=A0 I= t is my view that WebRTC should be further designed and developed with an e= ye to mitigating this serious problem, so that users of services which migh= t rely partially or wholly upon WebRTC would not have to be concerned about= such information leakage.

Respectfully,

Colin Gallagher

_______________________________________________
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
--f403045c1c801d801105506cd253-- From nobody Fri May 26 10:13:29 2017 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 12E5B128DF6 for ; Fri, 26 May 2017 10:13:28 -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, 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 WY6EiqbOp_Vc for ; Fri, 26 May 2017 10:13:25 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 0509F126B7F for ; Fri, 26 May 2017 10:13:24 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id e193so17075290pfh.0 for ; Fri, 26 May 2017 10:13:24 -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=Nr5nNfVXli1kTfb0J2ocqTXkjNE+CsNRzHDDVRKdZNI=; b=PCtPP8x9qs6S/dhMkEh/WrPqC0jj8d2KgcVH75vM7kGlTss2fxEfNn9ccV01wDCJw0 4xT6N8u3vJeBV3UXCXGvVMUFP1AEHq+tfsBp2DALf+pMCX0Bdl7f6erYEdHV7do8AHLI drsDzaj27cELE4hmdfAmd2/9CKXFBtr5bfZUEWL3sNQzuizuQPcLTslnntUXW+MMbxu4 RPPYP8Vl2T4zOOhm9/F8KAfu8Au4wOlNFU9gzjtonXInnxyptyVJE5kU4vlOJNVSAbbO EwzR8+gPVAcJTuHjo+KP+Ydunn9RkLcblS9t6ibbdZeebUGdCx6NLeRpcSDbekHJOErj rKnA== 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=Nr5nNfVXli1kTfb0J2ocqTXkjNE+CsNRzHDDVRKdZNI=; b=THxxhB4MzG2nu4GwmzcDEGaWSFO+lmuV9mM6+Lz4UNXIz+zlJDC5K74Mrg5EmeRl8H NaYPwJyrlKWkUFieOxyZ9nmUQLQkKhRH3dxZGLd/uMijOI5PSm/AsyVTR6sgU9mxnFRB pL/EF3DXAVGZ2xH83SzvZGvZz6TdTzMVevBUSrN9dMJcWexZh6Jv6cckIFzRy7zWXCZr rfB+xUziOYB7LId0nzoaEjelsgXRalIxEEugM0ZwD5cpu32FTDM47nDACZcJpy9twiST J6tWoPvoubYs/2MNLWneNN2vitg+RQxD+UV7r3AYqQqvsqNwz2BMPIeKctpTLD6s8QXn 8VAw== X-Gm-Message-State: AODbwcC+ohJfy4hsdXDvDZdNbqYL1NWGdJGw/xlVgtgbRydRpmjt2cSi 0tPPE0+GZyr3goc3TFPKh1KK+Z3Ldg== X-Received: by 10.99.54.141 with SMTP id d135mr3743893pga.85.1495818804354; Fri, 26 May 2017 10:13:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.179.161 with HTTP; Fri, 26 May 2017 10:13:23 -0700 (PDT) In-Reply-To: References: From: Colin Gallagher Date: Fri, 26 May 2017 10:13:23 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: Justin Uberti , rtcweb@ietf.org Content-Type: multipart/alternative; boundary="94eb2c193f667b663305507074bb" Archived-At: Subject: Re: [rtcweb] Request for New Security Review of WebRTC based on observed vulnerabilities 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, 26 May 2017 17:13:28 -0000 --94eb2c193f667b663305507074bb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It is quite clear what I am asking for. I am asking for a new security review of WebRTC. To quote my original request as posted: "I am asking that WebRTC security issues be reconsidered and that a new security review be done to ameliorate or eliminate this problem in terms of WebRTC leaking this information. It is my view that WebRTC should be further designed and developed with an eye to mitigating this serious problem, so that users of services which might rely partially or wholly upon WebRTC would not have to be concerned about such information leakage." In other words, I would like WebRTC to be reviewed for this very obvious security issue and redesigned so that it does not leak this information when utilized in browsers. Some developers who have considered using WebRTC (to develop a browser based WebRTC version of decentralized currency exchange) have observed this persistent security vulnerability and rather than accept the problems it would pose for users, the developers have instead contemplated incorporating onion routing among peers to mitigate the problem of IP being revealed or associated with messages. However, it should not only fall to developers who are considering using WebRTC to find some elaborate workaround or fix to the privacy problem with their particular application. WebRTC itself needs to be fixed as well. Respectfully, Colin Gallagher On Fri, May 26, 2017 at 5:53 AM, I=C3=B1aki Baz Castillo wr= ote: > It seems to me that you don't want WebRTC. For WebRTC to work IPs must be > exposed. So not sure what you are asking for. > > El 26/5/2017 9:58, "Colin Gallagher" > escribi=C3=B3: > >> Justin, >> >> It's my understanding that various browsers have made an attempt to >> conform to the recommendations in the document that you have provided >> . >> Unfortunately, at least in Firefox (the most current version) so far as = I >> can tell, there is a serious vulnerability. To be more specific, the >> problem was observed in my operating system with my current browser, whi= ch >> is Ubuntu 16.10 64-bit with Firefox 53.0.2 (64-bit). The browser does n= ot >> address the WebRTC problems by default. >> >> The stackexchange page that I cited originally is actually not outdated >> in the sense that its method of measuring whether or not the WebRTC >> vulnerability exists on a given system is still intact and works. The >> stackexchange page suggests two pages to determine whether or not you ha= ve >> leakage / WebRTC related vulnerability. These pages are: >> >> 1) Browser leaks test for WebRTC https://browserleaks.com/webrtc >> 2) IP Leaks https://ipleak.net/ >> >> Currently for Browser leaks test for WebRTC (due to that I have again >> changed settings in my system so that I will not have to be exposed to t= his >> vulnerability) the settings show up on the page as: >> RTCPeerConnection=C3=97False >> RTCDataChannel=C3=97False >> ORTC (Microsoft Edge)=C3=97False (for example....) >> >> And under IP leaks, it currently shows "No leak, RTCPeerConnection not >> available." >> >> *That is because:* >> >> (A) I have (again) changed my settings in about:config back to the >> following >> >> >> 1. I typed *about:config* in the address bar >> 2. I found the setting *media.peerconnection.enabled* >> 3. I set it to *false (it was previously set at true, so as to allow >> WebRTC to work, but this exposed information which I would not have w= anted >> to be exposed)* >> >> (B) And I also have changed my settings back to the following >> >> in the WebRTC 0.1.3 extension for Firefox I have set it to no longer >> expose my real IP address as well as no longer allowing the following: >> >> a. navigator.getUserMedia >> b. window.MediaStreamTrack >> c. window.RTCPeerConnection >> d. window.RTCSessionDescription >> >> To be clear, *these mitigations that I have employed above would be >> unnecessary if WebRTC had not been designed in such a manner that it so >> clearly exposes so much user information.* >> >> In the document you provided >> , titled >> "WebRTC IP Address Handling Requirements - draft-ietf-rtcweb-ip-handling= -03," >> it is stated that: >> >> *"1. If the client is behind a NAT, the client's private IP addresses, >> typically [RFC1918 ] addresses, can= be >> learned. * >> >> >> >> * 2. If the client tries to hide its physical location through a VPN, >> and the VPN and local OS support routing over multiple interfaces >> (i.e., a "split-tunnel" VPN), WebRTC will discover the public >> address for the VPN as well as the ISP public address that the >> VPN runs over. >> >> 3. If the client is behind a proxy (a client-configured "classical >> application proxy", as defined in [RFC1919], Section 3 ), but >> direct access to the Internet is also supported, WebRTC's STUN >> [RFC5389 ]checks will bypass= the proxy and reveal the public >> address of the client."* >> >> All of these are obvious vulnerabilities and serious problems (not only = #2 as the document suggests). >> >> It is stated in the document that, >> >> >> >> *"we want to avoid solutions that disable WebRTC or make it harder to us= e."* >> >> Yet, so far as my observations of WebRTC in the current version of Firef= ox with Ubuntu 16.10 have shown, >> >> there appears to be no other choice other than to disable WebRTC because= its use completely compromises >> >> privacy and thus makes all other aspects of your system more difficult g= enerally. >> >> It is stated in the document you cited that the goals here are to "Provi= de a privacy-friendly default behavior which strikes the >> right balance between privacy and media performance for most users >> and use cases. (and) For users who care more about one versus the = other, provide a >> means to customize the experience." >> >> This has clearlly not been accomplished in the context of Ubuntu 16.10 6= 4-bit with Firefox 53.0.2 (64-bit). >> >> Hence my request for a new security review of WebRTC based on observed v= ulnerabilities. >> >> >> >> >> On Thu, May 25, 2017 at 1:04 PM, Justin Uberti >> wrote: >> >>> Colin, >>> >>> This is an important topic, and the group has reviewed this situation i= n >>> detail. The results have been written up in this document >>> , and to >>> my knowledge most browsers that support WebRTC currently conform to its >>> recommendations. >>> >>> However, I'm not totally clear on your specific technical concern. You >>> linked to an (now outdated) stackexchange page, but could you provide m= ore >>> detail about the specific situation you are concerned about? >>> >>> Justin >>> >>> On Wed, May 24, 2017 at 5:35 PM, Colin Gallagher < >>> colingallagher.rpcv@gmail.com> wrote: >>> >>>> To: IETF RTCWeb WG >>>> >>>> From: Colin Gallagher >>>> https://www.linkedin.com/in/colingallagher >>>> https://lifeboat.com/ex/bios.colin.gallagher >>>> >>>> Request for New Security Review of WebRTC based on observed >>>> vulnerabilities in certain examples >>>> >>>> Dear IETF RTCWeb WG, >>>> >>>> This request relates to WebRTC. The WebRTC is in draft at >>>> https://w3c.github.io/webrtc-pc/ and is described also at >>>> https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API# >>>> WebRTC_interfaces >>>> >>>> There are certain examples where the use of WebRTC has presented >>>> security vulnerabilities. While not exhaustive, there are two I wante= d to >>>> mention that I had been exposed to recently. >>>> >>>> 1) The use of a video conferencing service which relies upon WebRTC >>>> (that is a well established service) >>>> 2) The examination of a browser based WebRTC version of a decentralize= d >>>> exchange (that is currently under development) >>>> >>>> In both cases the security vulnerability which is described below was >>>> the result of the use of WebRTC. >>>> >>>> The problem under consideration is as follows: >>>> >>>> As per the first example (the video conferencing service), recently I >>>> came upon a vendor who shall remain unnamed who uses WebRTC as the bac= kbone >>>> for their video conferencing service. As a result, I found I was unab= le to >>>> access the service in question without disabling some security setting= s >>>> which I would have preferred to leave intact. >>>> >>>> My system is (based on what the aforementioned service detects) >>>> Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 >>>> Firefox/53.0. This is Ubuntu 16.10 64-bit with Firefox 53.0.2. >>>> >>>> However, quite some *long* while back I disabled WebRTC because of the >>>> security vulnerability (described in part here on information security >>>> stack exchange >>>> ). >>>> So as to mitigate this vulnerability, I changed settings in Firefox as >>>> follows: >>>> >>>> >>>> 1. I typed *about:config* in the address bar >>>> 2. I found the setting *media.peerconnection.enabled* >>>> 3. I set it to *false* >>>> >>>> Unfortunately, this setting does not allow Firefox to work with the >>>> video conferencing service in question, which relies entirely on WebRT= C. >>>> >>>> So I had to go back in and change the media.peerconnection.enabled >>>> setting to *true* in Firefox in order to get it to work with the >>>> service in question. While this enabled me to conference with teams th= at >>>> desire to use the video conferencing service that rely wholly upon Web= RTC, >>>> it concerns me because of the security vulnerability. >>>> >>>> One suggested mitigation was having NoScript, but using NoScript was >>>> not helpful (you generally need to disable it for the site you are vie= wing >>>> that relies upon WebRTC, in order to obtain any functionality, and whe= ther >>>> NoScript is off or on, WebRTC still causes the vulnerability of leakin= g >>>> information as previously described). >>>> >>>> Furthermore, upon reload of the browser, even after setting >>>> media.peerconnection.enabled to *true*, the video conferencing service >>>> wouldn't work until I installed the WebRTC 0.1.3 extension for Firefox= and >>>> set it to expose my real IP address as well as allowing the following: >>>> >>>> a. navigator.getUserMedia >>>> b. window.MediaStreamTrack >>>> c. window.RTCPeerConnection >>>> d. window.RTCSessionDescription >>>> >>>> That seemed to me to be a direct consequence of the persistent and >>>> ongoing security vulnerability in WebRTC. >>>> >>>> I contacted the video conferencing service provider and their solution >>>> was simply to state that "If the peer to peer connection is of concern= , you >>>> can utilize our premium version which will route traffic through a >>>> forwarding server with in our environment that handles the processing = of >>>> the video and sound of all users in the conference and send it to each= user >>>> individually rather than using a peer to peer connection." In other w= ords, >>>> they expect that people should have to pay in order to mitigate this >>>> WebRTC security vulnerability >>>> , >>>> because they are unwilling to design to protect all users from it. >>>> >>>> In a similar fashion, in the second example of the browser based WebRT= C >>>> version of a decentralized exchange, the user's financial information = is >>>> periodically exposed as a result of the information leakage which is >>>> presently caused by WebRTC. (Fortunately, this browser based WebRTC >>>> decentralized exchange is under development and is not currently open = to >>>> actual usage.) >>>> >>>> Although undoubtedly this has been discussed here before, I am asking >>>> that WebRTC security issues be reconsidered and that a new security re= view >>>> be done to ameliorate or eliminate this problem in terms of WebRTC lea= king >>>> this information. It is my view that WebRTC should be further designe= d and >>>> developed with an eye to mitigating this serious problem, so that user= s of >>>> services which might rely partially or wholly upon WebRTC would not ha= ve to >>>> be concerned about such information leakage. >>>> >>>> Respectfully, >>>> Colin Gallagher >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> --94eb2c193f667b663305507074bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It is quite clear what I am askin= g for.=C2=A0 I am asking for a new security review of WebRTC.=C2=A0 To quot= e my original request as posted:

"I am asking that WebRTC secur= ity issues be reconsidered and that a new security review be done to ameliorate or=20 eliminate this problem in terms of WebRTC leaking this information.=C2=A0 I= t=20 is my view that WebRTC should be further designed and developed with an=20 eye to mitigating this serious problem, so that users of services which=20 might rely partially or wholly upon WebRTC would not have to be=20 concerned about such information leakage."

In other words= , I would like WebRTC to be reviewed for this very obvious security issue a= nd redesigned so that it does not leak this information when utilized in br= owsers.

Some developers who have considered using WebRTC (to d= evelop a browser based WebRTC version of decentralized currency exchange) h= ave observed this persistent security vulnerability and rather than accept = the problems it would pose for users, the developers have instead contempla= ted incorporating onion routing among peers to mitigate the problem of IP b= eing revealed or associated with messages.

However, it should = not only fall to developers who are considering using WebRTC to find some e= laborate workaround or fix to the privacy problem with their particular app= lication.=C2=A0 WebRTC itself needs to be fixed as well.

Respe= ctfully,

Colin Gallagher
<= br>
On Fri, May 26, 2017 at 5:53 AM, I=C3=B1aki B= az Castillo <ibc@aliax.net> wrote:
It seems to me that you don't want WebRTC. For= WebRTC to work IPs must be exposed. So not sure what you are asking for.

=
El 26/5/2017 9:58, "Colin Gallagher" &= lt;colin= gallagher.rpcv@gmail.com> escribi=C3=B3:
=
Justin,

It's my understanding that various = browsers have made an attempt to conform to the recommendations in the document that you have provided.=C2=A0 Unfortunately, at l= east in Firefox (the most current version) so far as I can tell, there is a= serious vulnerability.=C2=A0 To be more specific, the problem was observed= in my operating system with my current browser, which is Ubuntu 16.10 64-b= it with Firefox=20 53.0.2 (64-bit).=C2=A0 The browser does not address the WebRTC problems by = default.

The stackexchange page that I cited originally is act= ually not outdated in the sense that its method of measuring whether or not= the WebRTC vulnerability exists on a given system is still intact and work= s.=C2=A0 The stackexchange page suggests two pages to determine whether or = not you have leakage / WebRTC related vulnerability.=C2=A0 These pages are:=

1) Browser leaks test for WebRTC https://browserleaks.com/webrtc<= br>
2) IP Leaks http= s://ipleak.net/

Currently for Browser leaks test for WebRT= C (due to that I have again changed settings in my system so that I will no= t have to be exposed to this vulnerability) the settings show up on the pag= e as:
RTCPeerConnection=C3=97False
RTCDataChannel=C3=97False
ORTC = (Microsoft Edge)=C3=97False (for example....)

And under IP lea= ks, it currently shows "No leak, RTCPeerConnection not available."= ;=C2=A0

That is because:

(A) I have (agai= n) changed my settings in about:config back to the following

    I typed about:config in the address bar
  1. I found the setti= ng media.peerconnection.enabled
  2. I set it to false= =C2=A0 (it was previously set at true, so as to allow WebRTC to work, but t= his exposed information which I would not have wanted to be exposed)

(B) And I also have changed my settings back to the followin= g

in the WebRTC 0.1.3 extension for Firefox I have set it to no longe= r expose my real IP=20 address as well as no longer allowing the following:

a. navigator.get= UserMedia
b. window.MediaStreamTrack
c. window.RTCPeerConnection
d= . window.RTCSessionDescription

To be clear, these mitigations that= I have employed above would be unnecessary if WebRTC had not been designed= in such a manner that it so clearly exposes so much user information.<= /p>

In the document you provided, titled "WebRTC= IP Address Handling Requirements - draft-ietf-rtcweb-ip-handling-03,&= quot; it is stated that:

"1. If the client is behind a NAT, the client's pri= vate IP addresses, typically [RFC1918] addresses, can be learned. 

 2.  I=
f the client tries to hide its physical location through a VPN,
       and the VPN and local OS support routing over multiple interfaces
       (i.e., a "split-tunnel" VPN), WebRTC will discover the pub=
lic
       address for the VPN as well as the ISP public address that the
       VPN runs over.

   3.  If the client is behind a proxy (a client-configured "classical
       application proxy", as defined in [RFC1919], Section=C2=A03), but
       direct access to the Internet is also supported, WebRTC's STUN
       [RFC5389=
]checks will bypass the proxy and reveal the public
       address of the client."

All of these are obvious vulnerabilitie=
s and serious problems (not only #2 as the document suggests).

It is stated in =
the document that, 

"we want to avoid solutions that disable=
 WebRTC or make it harder to use."

Yet, so far as my observations of =
WebRTC in the current version of Firefox with Ubuntu 16.10 have shown,
<=
/span>
there appear=
s to be no other choice other than to disable WebRTC because its use comple=
tely compromises 
privacy and thus makes all other aspects of your system more diff=
icult generally.  

It is stated in the document you cited that the goals here a=
re to "Provide a privacy-friendly default behavior which strike=
s the
      right balance between privacy and media performance for most users
      and use cases. (and) For users who care more about one versus the oth=
er, provide a
      means to customize the experience."
This has clearlly not been accomplished in the =
context of Ubuntu 16.10 64-bit with Firefox 53.0.2 (64-bit).

=

Hence my request f=
or a new security review of WebRTC based on observed vulnerabilities.




O= n Thu, May 25, 2017 at 1:04 PM, Justin Uberti <juberti@google.com>= wrote:
Colin,
This is an important topic, and the group has reviewed thi= s situation in detail. The results have been written up in = this document, and to my knowledge most browsers that support WebRTC cu= rrently conform to its recommendations.

However, I= 'm not totally clear on your specific technical concern. You linked to = an (now outdated) stackexchange page, but could you provide more detail abo= ut the specific situation you are concerned about?

Justin

On Wed, = May 24, 2017 at 5:35 PM, Colin Gallagher <colingallagher.rpcv@= gmail.com> wrote:
To:=C2=A0 IETF RTCWe= b WG

From:=C2=A0 Colin Gallagher
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.linkedin.com/in/colingallagher
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 https://lifeboat.com/ex/bios.colin.gallagher

R= equest for New Security Review of WebRTC based on observed vulnerabilities = in certain examples

Dear IETF RTCWeb WG,

Thi= s request relates to WebRTC.=C2=A0 The WebRTC is in draft at https://w3c.github.io/webr= tc-pc/ and is=20 described also at=20 https://developer.mozilla.org/en-US/d= ocs/Web/API/WebRTC_API#WebRTC_interfaces

There= are certain examples where the use of WebRTC has presented security vulner= abilities.=C2=A0 While not exhaustive, there are two I wanted to mention th= at I had been exposed to recently.

1) The use of a = video conferencing service which relies upon WebRTC (that is a well establi= shed service)
2) The examination of a browser based WebRTC version= of a decentralized exchange (that is currently under development)

<= /div>In both cases the security vulnerability which is described below was = the result of the use of WebRTC.

The problem under consideration is = as follows:

As per the first example (the video conferencing service= ), recently I came upon a vendor who shall remain unnamed who uses WebRTC as the=20 backbone for their video conferencing service.=C2=A0 As a result, I found I= =20 was unable to access the service in question without disabling some=20 security settings which I would have preferred to leave intact.

My = system is (based on what the aforementioned service detects) Mozilla/5.0 (X= 11; Ubuntu; Linux x86_64; rv:53.0)=20 Gecko/20100101 Firefox/53.0.=C2=A0 This is Ubuntu 16.10 64-bit with Firefox= =20 53.0.2.

However, quite some long while back I disabled WebRTC= because of the security vulnerability (described in part here = on information security stack exchange).=C2=A0 So as to mitigate this v= ulnerability, I changed settings in Firefox as follows:

  1. I ty= ped about:config in the address bar
  2. I found the setting media.peerconnection.enabled
  3. I set it to false

Unfortunately, this setting does not allow Firefox to work with the video conferencing service in question, which relies entirely on WebRTC.

So I had t= o go back in and change the media.peerconnection.enabled setting to true= in Firefox in order to get it to work with the service in question.=20 While this enabled me to conference with teams that desire to use the=20 video conferencing service that rely wholly upon WebRTC, it concerns me=20 because of the security vulnerability.

One suggested mitigation was h= aving NoScript, but using NoScript was not helpful (you generally need to d= isable it for the site you are viewing that relies upon WebRTC, in order to= obtain any functionality, and whether NoScript is off or on, WebRTC still = causes the vulnerability of leaking information as previously described).

Furthermore, upon reload of the browser, even after setting media.= peerconnection.enabled to true, the video conferencing service wouldn't work until I installed the=20 WebRTC 0.1.3 extension for Firefox and set it to expose my real IP=20 address as well as allowing the following:

a. navigator.getUserMedia<= br>b. window.MediaStreamTrack
c. window.RTCPeerConnection
d. window.R= TCSessionDescription

That seemed to me to be a direct consequence= of the persistent and ongoing security vulnerability in WebRTC.

= I contacted the video conferencing service provider and their solution=20 was simply to state that "If the peer to peer connection is of concern= ,=20 you can utilize our=20 premium version which will route traffic through a forwarding server=20 with in our environment that handles the processing of the video and=20 sound of all users in the conference and send it to each user=20 individually rather than using a peer to peer connection."=C2=A0 In ot= her=20 words, they expect that people should have to pay in order to mitigate this WebRTC security vulnerability, because they are unwilling = to design to protect all users from it.

In a similar fashion, in the = second example of the browser based WebRTC version of a decentralized excha= nge, the user's financial information is periodically exposed as a resu= lt of the information leakage which is presently caused by WebRTC.=C2=A0 (F= ortunately, this browser based WebRTC decentralized exchange is under devel= opment and is not currently open to actual usage.)

Although undoubtedly this has been discussed here before, I am asking that WebRTC s= ecurity issues be reconsidered and that a new security review be done to ameliorate or=20 eliminate this problem in terms of WebRTC leaking this information.=C2=A0 I= t is my view that WebRTC should be further designed and developed with an e= ye to mitigating this serious problem, so that users of services which migh= t rely partially or wholly upon WebRTC would not have to be concerned about= such information leakage.

Respectfully,

Colin Gallagher

_______________________________________________
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

--94eb2c193f667b663305507074bb-- From nobody Fri May 26 10:50:22 2017 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 D8CED129B13 for ; Fri, 26 May 2017 10:50:21 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 qjSr51TP7EKs for ; Fri, 26 May 2017 10:50:18 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 7CE9F1205D3 for ; Fri, 26 May 2017 10:50:18 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id p24so13785080ioi.0 for ; Fri, 26 May 2017 10:50:18 -0700 (PDT) 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=OYqGPwvSrabsIOJufD6Rhx7mkTQd9i4a9gjaoQvGBeI=; b=UOax4V/UGGHbAbioTObYhW7LCjWuZvmmVYXvOOC3cEu/nuVpUDDrtMc/YmtZQ/j2vO XmVX9OQS0YVQSrDImYW1jJg7ZpuxSAworIm9B8qo65PPxtX4QJ1QrMQFZLSZscX8cAgd RxaU1Rkjv+e+shjn/uLXQXKk/6aYMWcz5edvIlqj+L60AhOCDb5NbiwJzJ62gZO7WtDo Ysc/xh1v/7FEQrTHSOol/VESsYKbgZD95Z1xm77+tZCZspVPb1xX/v89Ns+3baIr0aZU 7LPy++vCaQ/IzR5Dxcv1/cP/vemjgHDLvA/YZf8PHEZr4gUs3MN8XIJ1Vz4ZG6xDqkRO KJ0A== 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=OYqGPwvSrabsIOJufD6Rhx7mkTQd9i4a9gjaoQvGBeI=; b=d5oGB50dHKsEFwBhaS4raiOB3VQSy25x2N2PuX/9hRXZbdBi01ZSKhx7pRgWgV2Xwv jYYU1ItPSaGBzRLZyHfB8JI8m0G4rYydfzBdMZ1f4TC1vonMRhaTRtX/tAhAFI0N+qqS 4mr/IJalv4z86HQpwl/Mx/S7DXJ43xgOXwEJGYP3qgEZJSv1txy253Ao2wp+xvCmTCR6 t/CpNqWENhXG2tEv6u86PRPeUhcdco7GCJUZCTVQjaS26UcZttaJRmjVZTOPmp8VUi7y CNBnl7yHj3X9w6iijQodmAk8usQNwAiJimlR7162oFrdnf4PPw6+eAibSiEZoMRfb4YQ Glcw== X-Gm-Message-State: AODbwcC0BxrbSmxQYmjA60fZE9kyIe4bqt5hTBte5BEnlBHHygnIGR34 KRgtNbB9XhkBkhs2nN35maNDgyMb0BDX X-Received: by 10.107.133.106 with SMTP id h103mr2981462iod.230.1495821017592; Fri, 26 May 2017 10:50:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.11.149 with HTTP; Fri, 26 May 2017 10:49:56 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Fri, 26 May 2017 10:49:56 -0700 Message-ID: To: Colin Gallagher Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="001a113ff9a66765aa055070f882" Archived-At: Subject: Re: [rtcweb] Request for New Security Review of WebRTC based on observed vulnerabilities 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, 26 May 2017 17:50:22 -0000 --001a113ff9a66765aa055070f882 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Colin, As Eric mentioned, the group has reviewed this exact issue, and the aforementioned document represents the result of the review. I am still not quite clear on the exact technical issue you would like to see addressed and why it is, as you claim, a serious vulnerability. Comments inline. On Fri, May 26, 2017 at 12:58 AM, Colin Gallagher < colingallagher.rpcv@gmail.com> wrote: > Justin, > > It's my understanding that various browsers have made an attempt to > conform to the recommendations in the document that you have provided > . > Unfortunately, at least in Firefox (the most current version) so far as I > can tell, there is a serious vulnerability. To be more specific, the > problem was observed in my operating system with my current browser, whic= h > is Ubuntu 16.10 64-bit with Firefox 53.0.2 (64-bit). The browser does no= t > address the WebRTC problems by default. > > The stackexchange page that I cited originally is actually not outdated i= n > the sense that its method of measuring whether or not the WebRTC > vulnerability exists on a given system is still intact and works. The > stackexchange page suggests two pages to determine whether or not you hav= e > leakage / WebRTC related vulnerability. These pages are: > > 1) Browser leaks test for WebRTC https://browserleaks.com/webrtc > 2) IP Leaks https://ipleak.net/ > > Currently for Browser leaks test for WebRTC (due to that I have again > changed settings in my system so that I will not have to be exposed to th= is > vulnerability) the settings show up on the page as: > RTCPeerConnection=C3=97False > RTCDataChannel=C3=97False > ORTC (Microsoft Edge)=C3=97False (for example....) > > And under IP leaks, it currently shows "No leak, RTCPeerConnection not > available." > > *That is because:* > > (A) I have (again) changed my settings in about:config back to the > following > > > 1. I typed *about:config* in the address bar > 2. I found the setting *media.peerconnection.enabled* > 3. I set it to *false (it was previously set at true, so as to allow > WebRTC to work, but this exposed information which I would not have wa= nted > to be exposed)* > > (B) And I also have changed my settings back to the following > > in the WebRTC 0.1.3 extension for Firefox I have set it to no longer > expose my real IP address as well as no longer allowing the following: > > a. navigator.getUserMedia > b. window.MediaStreamTrack > c. window.RTCPeerConnection > d. window.RTCSessionDescription > > To be clear, *these mitigations that I have employed above would be > unnecessary if WebRTC had not been designed in such a manner that it so > clearly exposes so much user information.* > > In the document you provided > , titled > "WebRTC IP Address Handling Requirements - draft-ietf-rtcweb-ip-handling-= 03," > it is stated that: > > *"1. If the client is behind a NAT, the client's private IP addresses, > typically [RFC1918 ] addresses, can = be > learned. * > > > > * 2. If the client tries to hide its physical location through a VPN, > and the VPN and local OS support routing over multiple interfaces > (i.e., a "split-tunnel" VPN), WebRTC will discover the public > address for the VPN as well as the ISP public address that the > VPN runs over. > > 3. If the client is behind a proxy (a client-configured "classical > application proxy", as defined in [RFC1919], Section 3 ), but > direct access to the Internet is also supported, WebRTC's STUN > [RFC5389 ]checks will bypass = the proxy and reveal the public > address of the client."* > > All of these are obvious vulnerabilities and serious problems (not only #= 2 as the document suggests). > > The document discusses #1 and #3 in detail, and outlines mechanisms that can be used to address these cases if needed. If, despite the findings in the document, you think that these are indeed serious problems, it would be good to outline exactly why. > > It is stated in the document that, > > > > *"we want to avoid solutions that disable WebRTC or make it harder to use= ."* > > Yet, so far as my observations of WebRTC in the current version of Firefo= x with Ubuntu 16.10 have shown, > > there appears to be no other choice other than to disable WebRTC because = its use completely compromises > > privacy and thus makes all other aspects of your system more difficult ge= nerally. > > > It is stated in the document you cited that the goals here are to "Provid= e a privacy-friendly default behavior which strikes the > right balance between privacy and media performance for most users > and use cases. (and) For users who care more about one versus the o= ther, provide a > means to customize the experience." > > This has clearlly not been accomplished in the context of Ubuntu 16.10 64= -bit with Firefox 53.0.2 (64-bit). > > Hence my request for a new security review of WebRTC based on observed vu= lnerabilities. > > To my knowledge, the document addresses these goals. If you believe Firefox is not conforming, please file a bug; if you think the document is in error, please point out where and why. > > > > On Thu, May 25, 2017 at 1:04 PM, Justin Uberti wrote= : > >> Colin, >> >> This is an important topic, and the group has reviewed this situation in >> detail. The results have been written up in this document >> , and to >> my knowledge most browsers that support WebRTC currently conform to its >> recommendations. >> >> However, I'm not totally clear on your specific technical concern. You >> linked to an (now outdated) stackexchange page, but could you provide mo= re >> detail about the specific situation you are concerned about? >> >> Justin >> >> On Wed, May 24, 2017 at 5:35 PM, Colin Gallagher < >> colingallagher.rpcv@gmail.com> wrote: >> >>> To: IETF RTCWeb WG >>> >>> From: Colin Gallagher >>> https://www.linkedin.com/in/colingallagher >>> https://lifeboat.com/ex/bios.colin.gallagher >>> >>> Request for New Security Review of WebRTC based on observed >>> vulnerabilities in certain examples >>> >>> Dear IETF RTCWeb WG, >>> >>> This request relates to WebRTC. The WebRTC is in draft at >>> https://w3c.github.io/webrtc-pc/ and is described also at >>> https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API# >>> WebRTC_interfaces >>> >>> There are certain examples where the use of WebRTC has presented >>> security vulnerabilities. While not exhaustive, there are two I wanted= to >>> mention that I had been exposed to recently. >>> >>> 1) The use of a video conferencing service which relies upon WebRTC >>> (that is a well established service) >>> 2) The examination of a browser based WebRTC version of a decentralized >>> exchange (that is currently under development) >>> >>> In both cases the security vulnerability which is described below was >>> the result of the use of WebRTC. >>> >>> The problem under consideration is as follows: >>> >>> As per the first example (the video conferencing service), recently I >>> came upon a vendor who shall remain unnamed who uses WebRTC as the back= bone >>> for their video conferencing service. As a result, I found I was unabl= e to >>> access the service in question without disabling some security settings >>> which I would have preferred to leave intact. >>> >>> My system is (based on what the aforementioned service detects) >>> Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 >>> Firefox/53.0. This is Ubuntu 16.10 64-bit with Firefox 53.0.2. >>> >>> However, quite some *long* while back I disabled WebRTC because of the >>> security vulnerability (described in part here on information security >>> stack exchange >>> ). >>> So as to mitigate this vulnerability, I changed settings in Firefox as >>> follows: >>> >>> >>> 1. I typed *about:config* in the address bar >>> 2. I found the setting *media.peerconnection.enabled* >>> 3. I set it to *false* >>> >>> Unfortunately, this setting does not allow Firefox to work with the >>> video conferencing service in question, which relies entirely on WebRTC= . >>> >>> So I had to go back in and change the media.peerconnection.enabled >>> setting to *true* in Firefox in order to get it to work with the >>> service in question. While this enabled me to conference with teams tha= t >>> desire to use the video conferencing service that rely wholly upon WebR= TC, >>> it concerns me because of the security vulnerability. >>> >>> One suggested mitigation was having NoScript, but using NoScript was no= t >>> helpful (you generally need to disable it for the site you are viewing = that >>> relies upon WebRTC, in order to obtain any functionality, and whether >>> NoScript is off or on, WebRTC still causes the vulnerability of leaking >>> information as previously described). >>> >>> Furthermore, upon reload of the browser, even after setting >>> media.peerconnection.enabled to *true*, the video conferencing service >>> wouldn't work until I installed the WebRTC 0.1.3 extension for Firefox = and >>> set it to expose my real IP address as well as allowing the following: >>> >>> a. navigator.getUserMedia >>> b. window.MediaStreamTrack >>> c. window.RTCPeerConnection >>> d. window.RTCSessionDescription >>> >>> That seemed to me to be a direct consequence of the persistent and >>> ongoing security vulnerability in WebRTC. >>> >>> I contacted the video conferencing service provider and their solution >>> was simply to state that "If the peer to peer connection is of concern,= you >>> can utilize our premium version which will route traffic through a >>> forwarding server with in our environment that handles the processing o= f >>> the video and sound of all users in the conference and send it to each = user >>> individually rather than using a peer to peer connection." In other wo= rds, >>> they expect that people should have to pay in order to mitigate this >>> WebRTC security vulnerability >>> , >>> because they are unwilling to design to protect all users from it. >>> >>> In a similar fashion, in the second example of the browser based WebRTC >>> version of a decentralized exchange, the user's financial information i= s >>> periodically exposed as a result of the information leakage which is >>> presently caused by WebRTC. (Fortunately, this browser based WebRTC >>> decentralized exchange is under development and is not currently open t= o >>> actual usage.) >>> >>> Although undoubtedly this has been discussed here before, I am asking >>> that WebRTC security issues be reconsidered and that a new security rev= iew >>> be done to ameliorate or eliminate this problem in terms of WebRTC leak= ing >>> this information. It is my view that WebRTC should be further designed= and >>> developed with an eye to mitigating this serious problem, so that users= of >>> services which might rely partially or wholly upon WebRTC would not hav= e to >>> be concerned about such information leakage. >>> >>> Respectfully, >>> Colin Gallagher >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >> > --001a113ff9a66765aa055070f882 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Colin,

As Eric mentioned, the group has= reviewed this exact issue, and the aforementioned document represents the = result of the review.

I am still not quite clear o= n the exact technical issue you would like to see addressed and why it is, = as you claim, a serious vulnerability.

Comments in= line.

On Fri= , May 26, 2017 at 12:58 AM, Colin Gallagher <colingallagher.= rpcv@gmail.com> wrote:
Justin,

I= t's my understanding that various browsers have made an attempt to conf= orm to the recommendations in the document that you have pr= ovided.=C2=A0 Unfortunately, at least in Firefox (the most current vers= ion) so far as I can tell, there is a serious vulnerability.=C2=A0 To be mo= re specific, the problem was observed in my operating system with my curren= t browser, which is Ubuntu 16.10 64-bit with Firefox=20 53.0.2 (64-bit).=C2=A0 The browser does not address the WebRTC problems by = default.

The stackexchange page that I cited originally is act= ually not outdated in the sense that its method of measuring whether or not= the WebRTC vulnerability exists on a given system is still intact and work= s.=C2=A0 The stackexchange page suggests two pages to determine whether or = not you have leakage / WebRTC related vulnerability.=C2=A0 These pages are:=

1) Browser leaks test for WebRTC https://browserleaks.com/webrtc<= br>
2) IP Leaks http= s://ipleak.net/

Currently for Browser leaks test for WebRT= C (due to that I have again changed settings in my system so that I will no= t have to be exposed to this vulnerability) the settings show up on the pag= e as:
RTCPeerConnection= =C3=97False
RTCDataChannel=C3=97False
ORTC (Microsoft Edge)=C3=97False (for example....)

An= d under IP leaks, it currently shows "No leak, RTCPeerConnection not a= vailable."=C2=A0

That is because:

(A= ) I have (again) changed my settings in about:config back to the following<= br>
  1. I typed about:config in the addres= s bar
  2. I found the setting media.peerconnection.enabled
  3. I set it to false=C2=A0 (it was previously set at true,= so as to allow WebRTC to work, but this exposed information which I would = not have wanted to be exposed)

(B) And I also have cha= nged my settings back to the following

in the WebRTC 0.1.3 extension = for Firefox I have set it to no longer expose my real IP=20 address as well as no longer allowing the following:

a. navigator.getUserMedia
b. window.MediaStreamTrack
c. window.RTCPe= erConnection
d. window.RTCSessionDescription

To be clear, <= b>these mitigations that I have employed above would be unnecessary if WebR= TC had not been designed in such a manner that it so clearly exposes so muc= h user information.

In the document you provided<= /a>, titled "WebRTC IP Address Handling Requirements - draft-ietf-rtcw= eb-ip-handling-03," it is stated that:

"1. If the client is behind a N= AT, the client's private IP addresses, typically [RFC1918] addresses, can be learned. 

 2.  If the client tries to=
 hide its physical location through a VPN,
       and the VPN and local OS support routing over multiple interfaces
       (i.e., a "split-tunnel" VPN), WebRTC will discover the pub=
lic
       address for the VPN as well as the ISP public address that the
       VPN runs over.

   3.  If the client is behind a proxy (a client-configured "classical
       application proxy", as defined in [RFC1919], Section=C2=A03), but
       direct access to the Internet is also supported, WebRTC's STUN
       [RFC5389=
]checks will bypass the proxy and reveal the public
       address of the client."

All of these are obvious vulnerabilities and serious problem=
s (not only #2 as the document suggests).

The document discusses #1 and #3 in detail, and outli= nes mechanisms that can be used to address these cases if needed.

If, despite the findings in the document, you think that th= ese are indeed serious problems, it would be good to outline exactly why.

<=
span style=3D"font-family:arial,helvetica,sans-serif">It is stated in the d=
ocument that, 

"we want to avoid solutions that disable WebR=
TC or make it harder to use."

Yet, so far as my observations of WebRTC in the current versi=
on of Firefox with Ubuntu 16.10 have shown,
there appears to be no other choice other than to disable We=
bRTC because its use completely compromises 
privacy and thus makes all other aspects of your system mor=
e difficult generally.

<= pre class=3D"m_3620305583784542015gmail-newpage">It is stated in the document you cited that th= e goals here are to "Provide a privacy-friendly default behavio= r which strikes the right balance between privacy and media performance for most users and use cases. (and) For users who care more about one versus the oth= er, provide a means to customize the experience."
This has clearlly not been accomplished in the context of Ubuntu 16.=
10 64-bit with Firefox 53.0.2 (64-bit).

Hence my request for a new security review of WebRTC based o=
n observed vulnerabilities.

To my knowledge, the document addresses these goals. If you believe= Firefox is not conforming, please file a bug; if you think the document is= in error, please point out where and why.




On Thu, May 25, 2017 at 1:04 PM, Justin Uberti <jubert= i@google.com> wrote:
Colin,

This is an important topic, and the gr= oup has reviewed this situation in detail. The results have been written up= in this document, and to my knowledge most browsers th= at support WebRTC currently conform to its recommendations.

<= /div>
However, I'm not totally clear on your specific technical con= cern. You linked to an (now outdated) stackexchange page, but could you pro= vide more detail about the specific situation you are concerned about?

Justin

On Wed, M= ay 24, 2017 at 5:35 PM, Colin Gallagher <colingallagher.rpcv@g= mail.com> wrote:
To:=C2=A0 IETF RTCWeb WG

From= :=C2=A0 Colin Gallagher
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 https://www.linkedin.com/in/colingallagher
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://lifeboat.= com/ex/bios.colin.gallagher

Request for New Security = Review of WebRTC based on observed vulnerabilities in certain examples
<= br>
Dear IETF RTCWeb WG,

This request relates to Web= RTC.=C2=A0 The WebRTC is in draft at https://w3c.github.io/webrtc-pc/ and is= =20 described also at=20 https://developer.mozilla.org/en-US/d= ocs/Web/API/WebRTC_API#WebRTC_interfaces

There= are certain examples where the use of WebRTC has presented security vulner= abilities.=C2=A0 While not exhaustive, there are two I wanted to mention th= at I had been exposed to recently.

1) The use of a = video conferencing service which relies upon WebRTC (that is a well establi= shed service)
2) The examination of a browser based WebRTC version= of a decentralized exchange (that is currently under development)

<= /div>In both cases the security vulnerability which is described below was = the result of the use of WebRTC.

The problem under consideration is = as follows:

As per the first example (the video conferencing service= ), recently I came upon a vendor who shall remain unnamed who uses WebRTC as the=20 backbone for their video conferencing service.=C2=A0 As a result, I found I= =20 was unable to access the service in question without disabling some=20 security settings which I would have preferred to leave intact.

My = system is (based on what the aforementioned service detects) Mozilla/5.0 (X= 11; Ubuntu; Linux x86_64; rv:53.0)=20 Gecko/20100101 Firefox/53.0.=C2=A0 This is Ubuntu 16.10 64-bit with Firefox= =20 53.0.2.

However, quite some long while back I disabled WebRTC= because of the security vulnerability (described in part here = on information security stack exchange).=C2=A0 So as to mitigate this v= ulnerability, I changed settings in Firefox as follows:

  1. I ty= ped about:config in the address bar
  2. I found the setting media.peerconnection.enabled
  3. I set it to false

Unfortunately, this setting does not allow Firefox to work with the video conferencing service in question, which relies entirely on WebRTC.

So I had t= o go back in and change the media.peerconnection.enabled setting to true= in Firefox in order to get it to work with the service in question.=20 While this enabled me to conference with teams that desire to use the=20 video conferencing service that rely wholly upon WebRTC, it concerns me=20 because of the security vulnerability.

One suggested mitigation was h= aving NoScript, but using NoScript was not helpful (you generally need to d= isable it for the site you are viewing that relies upon WebRTC, in order to= obtain any functionality, and whether NoScript is off or on, WebRTC still = causes the vulnerability of leaking information as previously described).

Furthermore, upon reload of the browser, even after setting media.= peerconnection.enabled to true, the video conferencing service wouldn't work until I installed the=20 WebRTC 0.1.3 extension for Firefox and set it to expose my real IP=20 address as well as allowing the following:

a. navigator.getUserMedia<= br>b. window.MediaStreamTrack
c. window.RTCPeerConnection
d. window.R= TCSessionDescription

That seemed to me to be a direct consequence= of the persistent and ongoing security vulnerability in WebRTC.

= I contacted the video conferencing service provider and their solution=20 was simply to state that "If the peer to peer connection is of concern= ,=20 you can utilize our=20 premium version which will route traffic through a forwarding server=20 with in our environment that handles the processing of the video and=20 sound of all users in the conference and send it to each user=20 individually rather than using a peer to peer connection."=C2=A0 In ot= her=20 words, they expect that people should have to pay in order to mitigate this WebRTC security vulnerability, because they are unwilling = to design to protect all users from it.

In a similar fashion, in the = second example of the browser based WebRTC version of a decentralized excha= nge, the user's financial information is periodically exposed as a resu= lt of the information leakage which is presently caused by WebRTC.=C2=A0 (F= ortunately, this browser based WebRTC decentralized exchange is under devel= opment and is not currently open to actual usage.)

Although undoubtedly this has been discussed here before, I am asking that WebRTC s= ecurity issues be reconsidered and that a new security review be done to ameliorate or=20 eliminate this problem in terms of WebRTC leaking this information.=C2=A0 I= t is my view that WebRTC should be further designed and developed with an e= ye to mitigating this serious problem, so that users of services which migh= t rely partially or wholly upon WebRTC would not have to be concerned about= such information leakage.

Respectfully,

Colin Gallagher

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



--001a113ff9a66765aa055070f882-- From nobody Fri May 26 11:14:34 2017 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 24502128B8E for ; Fri, 26 May 2017 11:14:32 -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 ToLaMTAWLvti for ; Fri, 26 May 2017 11:14:28 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 7E36D129B1E for ; Fri, 26 May 2017 11:14:28 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id 9so18263354pfj.1 for ; Fri, 26 May 2017 11:14:28 -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=9hcSum9JCtH5CBPHUHi5S1Ukz1vJpON8IYC5gOwYncM=; b=c/Zsfaf9H6DXI9zKLm1gBWFn8XyZMyg+enKcVShb3I7QqspcrxQIveD0J81R0OgnpO ersKVDBwlICaciwF2qtKxgCLMyN1jgFzZ5kBlAcworwY9XGlwBpOiK5YC0Kwd36jBCBI W+Ye3Chf8EgyNk1LUz3RbPHbJ9NzQkN3Tjj8NSEDKH9rzwuk+LT2nuJ+hV2kIBBtLsbr Bbq2WYdBVktrJghAtYeiAiIW3iO+CYyPPysMyczKK7Y+OYpOJeHogyWB+5Vdc2bSm5bQ AsKxCV0nrIHHl+ga9+PWYVhKYxMeTecYc3h10kZ5Ngtcb9qAGfee+ttt4X/Fs9Lyyf7d /d3A== 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=9hcSum9JCtH5CBPHUHi5S1Ukz1vJpON8IYC5gOwYncM=; b=EIBZC5pRmySUb1gOnBFrcxTa5DIqx3Sn+J9vmWtP3VXUDk+sWcOQQIKbCe3nSLIdQe 3bWnnAS+i1j4DZ/x2kzt7PtGTpFPyZwcnpFyqpfFviWL2TjmcBHnqMeFSlxG8K8UIgcx pWY+YEOOLzJdFdm5ifxsTPFk54h53RGfKtR4OAngmw5/kgJJp8+zXr8L3PzlHWd7FdDm e41E/eC6EpNwt141hN6WgqLTzhFVKrM80E1Xl8qH1o2FmiYQ+NcuPOP4OGkg5OeD4sBO LRlFYT1mDCrwD4FtOCRFJQdvGMNycqmZR8sjVdzwhLjs9NVrXFXdQ3CWOv5L2r95Bxmu igZg== X-Gm-Message-State: AODbwcCaRSVBPz6b1wsWK8Uz9KmOE9n8bTg5wGEERlcnzCPARpdhCUgw 5t2ROIuQqsBwnIuQprAdrlV/Cfr6Pw== X-Received: by 10.98.14.86 with SMTP id w83mr3836409pfi.83.1495822468015; Fri, 26 May 2017 11:14:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.179.161 with HTTP; Fri, 26 May 2017 11:14:27 -0700 (PDT) In-Reply-To: References: From: Colin Gallagher Date: Fri, 26 May 2017 11:14:27 -0700 Message-ID: To: Justin Uberti Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="001a11462f7cda6be80550714e65" Archived-At: Subject: Re: [rtcweb] Request for New Security Review of WebRTC based on observed vulnerabilities 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, 26 May 2017 18:14:32 -0000 --001a11462f7cda6be80550714e65 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It seems the consensus of the group here is essentially a refusal to further review and potentially redesign WebRTC to remove the serious security vulnerabilities that it presents to its users. Thank you for your time. I will not further respond to this thread. On Fri, May 26, 2017 at 10:49 AM, Justin Uberti wrote: > Colin, > > As Eric mentioned, the group has reviewed this exact issue, and the > aforementioned document represents the result of the review. > > I am still not quite clear on the exact technical issue you would like to > see addressed and why it is, as you claim, a serious vulnerability. > > Comments inline. > > On Fri, May 26, 2017 at 12:58 AM, Colin Gallagher < > colingallagher.rpcv@gmail.com> wrote: > >> Justin, >> >> It's my understanding that various browsers have made an attempt to >> conform to the recommendations in the document that you have provided >> . >> Unfortunately, at least in Firefox (the most current version) so far as = I >> can tell, there is a serious vulnerability. To be more specific, the >> problem was observed in my operating system with my current browser, whi= ch >> is Ubuntu 16.10 64-bit with Firefox 53.0.2 (64-bit). The browser does n= ot >> address the WebRTC problems by default. >> >> The stackexchange page that I cited originally is actually not outdated >> in the sense that its method of measuring whether or not the WebRTC >> vulnerability exists on a given system is still intact and works. The >> stackexchange page suggests two pages to determine whether or not you ha= ve >> leakage / WebRTC related vulnerability. These pages are: >> >> 1) Browser leaks test for WebRTC https://browserleaks.com/webrtc >> 2) IP Leaks https://ipleak.net/ >> >> Currently for Browser leaks test for WebRTC (due to that I have again >> changed settings in my system so that I will not have to be exposed to t= his >> vulnerability) the settings show up on the page as: >> RTCPeerConnection=C3=97False >> RTCDataChannel=C3=97False >> ORTC (Microsoft Edge)=C3=97False (for example....) >> >> And under IP leaks, it currently shows "No leak, RTCPeerConnection not >> available." >> >> *That is because:* >> >> (A) I have (again) changed my settings in about:config back to the >> following >> >> >> 1. I typed *about:config* in the address bar >> 2. I found the setting *media.peerconnection.enabled* >> 3. I set it to *false (it was previously set at true, so as to allow >> WebRTC to work, but this exposed information which I would not have w= anted >> to be exposed)* >> >> (B) And I also have changed my settings back to the following >> >> in the WebRTC 0.1.3 extension for Firefox I have set it to no longer >> expose my real IP address as well as no longer allowing the following: >> >> a. navigator.getUserMedia >> b. window.MediaStreamTrack >> c. window.RTCPeerConnection >> d. window.RTCSessionDescription >> >> To be clear, *these mitigations that I have employed above would be >> unnecessary if WebRTC had not been designed in such a manner that it so >> clearly exposes so much user information.* >> >> In the document you provided >> , titled >> "WebRTC IP Address Handling Requirements - draft-ietf-rtcweb-ip-handling= -03," >> it is stated that: >> >> *"1. If the client is behind a NAT, the client's private IP addresses, >> typically [RFC1918 ] addresses, can= be >> learned. * >> >> >> >> * 2. If the client tries to hide its physical location through a VPN, >> and the VPN and local OS support routing over multiple interfaces >> (i.e., a "split-tunnel" VPN), WebRTC will discover the public >> address for the VPN as well as the ISP public address that the >> VPN runs over. >> >> 3. If the client is behind a proxy (a client-configured "classical >> application proxy", as defined in [RFC1919], Section 3 ), but >> direct access to the Internet is also supported, WebRTC's STUN >> [RFC5389 ]checks will bypass= the proxy and reveal the public >> address of the client."* >> >> All of these are obvious vulnerabilities and serious problems (not only = #2 as the document suggests). >> >> > The document discusses #1 and #3 in detail, and outlines mechanisms that > can be used to address these cases if needed. > > If, despite the findings in the document, you think that these are indeed > serious problems, it would be good to outline exactly why. > >> >> It is stated in the document that, >> >> >> >> *"we want to avoid solutions that disable WebRTC or make it harder to us= e."* >> >> Yet, so far as my observations of WebRTC in the current version of Firef= ox with Ubuntu 16.10 have shown, >> >> there appears to be no other choice other than to disable WebRTC because= its use completely compromises >> >> privacy and thus makes all other aspects of your system more difficult g= enerally. >> >> >> It is stated in the document you cited that the goals here are to "Provi= de a privacy-friendly default behavior which strikes the >> right balance between privacy and media performance for most users >> and use cases. (and) For users who care more about one versus the = other, provide a >> means to customize the experience." >> >> This has clearlly not been accomplished in the context of Ubuntu 16.10 6= 4-bit with Firefox 53.0.2 (64-bit). >> >> Hence my request for a new security review of WebRTC based on observed v= ulnerabilities. >> >> > To my knowledge, the document addresses these goals. If you believe > Firefox is not conforming, please file a bug; if you think the document i= s > in error, please point out where and why. > >> >> >> >> On Thu, May 25, 2017 at 1:04 PM, Justin Uberti >> wrote: >> >>> Colin, >>> >>> This is an important topic, and the group has reviewed this situation i= n >>> detail. The results have been written up in this document >>> , and to >>> my knowledge most browsers that support WebRTC currently conform to its >>> recommendations. >>> >>> However, I'm not totally clear on your specific technical concern. You >>> linked to an (now outdated) stackexchange page, but could you provide m= ore >>> detail about the specific situation you are concerned about? >>> >>> Justin >>> >>> On Wed, May 24, 2017 at 5:35 PM, Colin Gallagher < >>> colingallagher.rpcv@gmail.com> wrote: >>> >>>> To: IETF RTCWeb WG >>>> >>>> From: Colin Gallagher >>>> https://www.linkedin.com/in/colingallagher >>>> https://lifeboat.com/ex/bios.colin.gallagher >>>> >>>> Request for New Security Review of WebRTC based on observed >>>> vulnerabilities in certain examples >>>> >>>> Dear IETF RTCWeb WG, >>>> >>>> This request relates to WebRTC. The WebRTC is in draft at >>>> https://w3c.github.io/webrtc-pc/ and is described also at >>>> https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API# >>>> WebRTC_interfaces >>>> >>>> There are certain examples where the use of WebRTC has presented >>>> security vulnerabilities. While not exhaustive, there are two I wante= d to >>>> mention that I had been exposed to recently. >>>> >>>> 1) The use of a video conferencing service which relies upon WebRTC >>>> (that is a well established service) >>>> 2) The examination of a browser based WebRTC version of a decentralize= d >>>> exchange (that is currently under development) >>>> >>>> In both cases the security vulnerability which is described below was >>>> the result of the use of WebRTC. >>>> >>>> The problem under consideration is as follows: >>>> >>>> As per the first example (the video conferencing service), recently I >>>> came upon a vendor who shall remain unnamed who uses WebRTC as the bac= kbone >>>> for their video conferencing service. As a result, I found I was unab= le to >>>> access the service in question without disabling some security setting= s >>>> which I would have preferred to leave intact. >>>> >>>> My system is (based on what the aforementioned service detects) >>>> Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 >>>> Firefox/53.0. This is Ubuntu 16.10 64-bit with Firefox 53.0.2. >>>> >>>> However, quite some *long* while back I disabled WebRTC because of the >>>> security vulnerability (described in part here on information security >>>> stack exchange >>>> ). >>>> So as to mitigate this vulnerability, I changed settings in Firefox as >>>> follows: >>>> >>>> >>>> 1. I typed *about:config* in the address bar >>>> 2. I found the setting *media.peerconnection.enabled* >>>> 3. I set it to *false* >>>> >>>> Unfortunately, this setting does not allow Firefox to work with the >>>> video conferencing service in question, which relies entirely on WebRT= C. >>>> >>>> So I had to go back in and change the media.peerconnection.enabled >>>> setting to *true* in Firefox in order to get it to work with the >>>> service in question. While this enabled me to conference with teams th= at >>>> desire to use the video conferencing service that rely wholly upon Web= RTC, >>>> it concerns me because of the security vulnerability. >>>> >>>> One suggested mitigation was having NoScript, but using NoScript was >>>> not helpful (you generally need to disable it for the site you are vie= wing >>>> that relies upon WebRTC, in order to obtain any functionality, and whe= ther >>>> NoScript is off or on, WebRTC still causes the vulnerability of leakin= g >>>> information as previously described). >>>> >>>> Furthermore, upon reload of the browser, even after setting >>>> media.peerconnection.enabled to *true*, the video conferencing service >>>> wouldn't work until I installed the WebRTC 0.1.3 extension for Firefox= and >>>> set it to expose my real IP address as well as allowing the following: >>>> >>>> a. navigator.getUserMedia >>>> b. window.MediaStreamTrack >>>> c. window.RTCPeerConnection >>>> d. window.RTCSessionDescription >>>> >>>> That seemed to me to be a direct consequence of the persistent and >>>> ongoing security vulnerability in WebRTC. >>>> >>>> I contacted the video conferencing service provider and their solution >>>> was simply to state that "If the peer to peer connection is of concern= , you >>>> can utilize our premium version which will route traffic through a >>>> forwarding server with in our environment that handles the processing = of >>>> the video and sound of all users in the conference and send it to each= user >>>> individually rather than using a peer to peer connection." In other w= ords, >>>> they expect that people should have to pay in order to mitigate this >>>> WebRTC security vulnerability >>>> , >>>> because they are unwilling to design to protect all users from it. >>>> >>>> In a similar fashion, in the second example of the browser based WebRT= C >>>> version of a decentralized exchange, the user's financial information = is >>>> periodically exposed as a result of the information leakage which is >>>> presently caused by WebRTC. (Fortunately, this browser based WebRTC >>>> decentralized exchange is under development and is not currently open = to >>>> actual usage.) >>>> >>>> Although undoubtedly this has been discussed here before, I am asking >>>> that WebRTC security issues be reconsidered and that a new security re= view >>>> be done to ameliorate or eliminate this problem in terms of WebRTC lea= king >>>> this information. It is my view that WebRTC should be further designe= d and >>>> developed with an eye to mitigating this serious problem, so that user= s of >>>> services which might rely partially or wholly upon WebRTC would not ha= ve to >>>> be concerned about such information leakage. >>>> >>>> Respectfully, >>>> Colin Gallagher >>>> >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>>> >>> >> > --001a11462f7cda6be80550714e65 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It seems the consensus of the group here is essential= ly a refusal to further review and potentially redesign WebRTC to remove th= e serious security vulnerabilities that it presents to its users.

Thank you for your time.=C2=A0 I will not further respond to this threa= d.



On Fri, May 26, 2017 at 10:49 AM, Justin Uberti <juberti@go= ogle.com> wrote:
Colin,

As Eric mentioned, the group has reviewe= d this exact issue, and the aforementioned document represents the result o= f the review.

I am still not quite clear on the ex= act technical issue you would like to see addressed and why it is, as you c= laim, a serious vulnerability.

Comments inline.

On Fri, May 26, 2017 at 12:58 AM, Colin Gallagher <co= lingallagher.rpcv@gmail.com> wrote:
Just= in,

It's my understanding that various browsers have made = an attempt to conform to the recommendations in the documen= t that you have provided.=C2=A0 Unfortunately, at least in Firefox (the= most current version) so far as I can tell, there is a serious vulnerabili= ty.=C2=A0 To be more specific, the problem was observed in my operating sys= tem with my current browser, which is Ubuntu 16.10 64-bit with Firefox=20 53.0.2 (64-bit).=C2=A0 The browser does not address the WebRTC problems by = default.

The stackexchange page that I cited originally is act= ually not outdated in the sense that its method of measuring whether or not= the WebRTC vulnerability exists on a given system is still intact and work= s.=C2=A0 The stackexchange page suggests two pages to determine whether or = not you have leakage / WebRTC related vulnerability.=C2=A0 These pages are:=

1) Browser leaks test for WebRTC https://browserleaks.com/webrtc<= br>
2) IP Leaks http= s://ipleak.net/

Currently for Browser leaks test for WebRT= C (due to that I have again changed settings in my system so that I will no= t have to be exposed to this vulnerability) the settings show up on the pag= e as:
RTCPeerConnection=C3=97False
RTCDataChannel=C3=97False
ORTC = (Microsoft Edge)=C3=97False (for example....)

And under IP lea= ks, it currently shows "No leak, RTCPeerConnection not available."= ;=C2=A0

That is because:

(A) I have (agai= n) changed my settings in about:config back to the following

  1. I typed about:config in the address bar
  2. I found the= setting media.peerconnection.enabled
  3. I set it to <= strong>false=C2=A0 (it was previously set at true, so as to allow WebRTC to= work, but this exposed information which I would not have wanted to be exp= osed)

(B) And I also have changed my settings back to = the following

in the WebRTC 0.1.3 extension for Firefox I have set it= to no longer expose my real IP=20 address as well as no longer allowing the following:

a. navigat= or.getUserMedia
b. window.MediaStreamTrack
c. window.RTCPeerConnectio= n
d. window.RTCSessionDescription

To be clear, these mit= igations that I have employed above would be unnecessary if WebRTC had not = been designed in such a manner that it so clearly exposes so much user info= rmation.

In the document you provided, titled= "WebRTC IP Address Handling Requirements - draft-ietf-rtcweb-ip-handl= ing-03," it is stated that:

"1. If the client is behind a NAT, the cli= ent's private IP addresses, typically [RFC1918] addresses, can be learned. 

 2.  I=
f the client tries to hide its physical location through a VPN,
       and the VPN and local OS support routing over multiple interfaces
       (i.e., a "split-tunnel" VPN), WebRTC will discover the pub=
lic
       address for the VPN as well as the ISP public address that the
       VPN runs over.

   3.  If the client is behind a proxy (a client-configured "classical
       application proxy", as defined in [RFC1919], Section=C2=A03), but
       direct access to the Internet is also supported, WebRTC's STUN
       [RFC5389=
]checks will bypass the proxy and reveal the public
       address of the client."

All of these are obvious vulnerabilitie=
s and serious problems (not only #2 as the document suggests).

The document discuss= es #1 and #3 in detail, and outlines mechanisms that can be used to address= these cases if needed.

If, despite the findings i= n the document, you think that these are indeed serious problems, it would = be good to outline exactly why.

It i=
s stated in the document that, 

"we want to avoid solutions =
that disable WebRTC or make it harder to use."

Yet, so far as my obser=
vations of WebRTC in the current version of Firefox with Ubuntu 16.10 have =
shown,
t=
here appears to be no other choice other than to disable WebRTC because its=
 use completely compromises 
privacy and thus makes all other aspects of your syste=
m more difficult generally.

It is stated in the document you cited that the goals here are to "Provide a privacy-friendly default behavior which strikes the
      right balance between privacy and media performance for most users
      and use cases. (and) For users who care more about one versus the oth=
er, provide a
      means to customize the experience."
This has clearlly not been accomplished in the =
context of Ubuntu 16.10 64-bit with Firefox 53.0.2 (64-bit).

=

Hence my request f=
or a new security review of WebRTC based on observed vulnerabilities.

To my knowledge, t= he document addresses these goals. If you believe Firefox is not conforming= , please file a bug; if you think the document is in error, please point ou= t where and why.


=

On Thu, May 25, 2017 at 1:04 PM, Justin Uberti <juberti@google.com&= gt; wrote:
Colin,=

This is an important topic, and the group has reviewed = this situation in detail. The results have been written up in this document, and to my knowledge most browsers that support WebRTC= currently conform to its recommendations.

However= , I'm not totally clear on your specific technical concern. You linked = to an (now outdated) stackexchange page, but could you provide more detail = about the specific situation you are concerned about?

<= div>Justin

On We= d, May 24, 2017 at 5:35 PM, Colin Gallagher <colingallagher.= rpcv@gmail.com> wrote:
To:=C2=A0 IETF= RTCWeb WG

From:=C2=A0 Colin Gallagher
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.linkedin.com/in/= colingallagher
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 https://lifeboat.com/ex/bios.colin.gallagher

<= /div>Request for New Security Review of WebRTC based on observed vulnerabil= ities in certain examples

Dear IETF RTCWeb WG,

This request relates to WebRTC.=C2=A0 The WebRTC is in draft at https://w3c.github.= io/webrtc-pc/ and is=20 described also at=20 https://developer.mozilla.org/en-US/d= ocs/Web/API/WebRTC_API#WebRTC_interfaces

There= are certain examples where the use of WebRTC has presented security vulner= abilities.=C2=A0 While not exhaustive, there are two I wanted to mention th= at I had been exposed to recently.

1) The use of a = video conferencing service which relies upon WebRTC (that is a well establi= shed service)
2) The examination of a browser based WebRTC version= of a decentralized exchange (that is currently under development)

<= /div>In both cases the security vulnerability which is described below was = the result of the use of WebRTC.

The problem under consideration is = as follows:

As per the first example (the video conferencing service= ), recently I came upon a vendor who shall remain unnamed who uses WebRTC as the=20 backbone for their video conferencing service.=C2=A0 As a result, I found I= =20 was unable to access the service in question without disabling some=20 security settings which I would have preferred to leave intact.

My = system is (based on what the aforementioned service detects) Mozilla/5.0 (X= 11; Ubuntu; Linux x86_64; rv:53.0)=20 Gecko/20100101 Firefox/53.0.=C2=A0 This is Ubuntu 16.10 64-bit with Firefox= =20 53.0.2.

However, quite some long while back I disabled WebRTC= because of the security vulnerability (described in part here = on information security stack exchange).=C2=A0 So as to mitigate this v= ulnerability, I changed settings in Firefox as follows:

  1. I ty= ped about:config in the address bar
  2. I found the setting media.peerconnection.enabled
  3. I set it to false

Unfortunately, this setting does not allow Firefox to work with the video conferencing service in question, which relies entirely on WebRTC.

So I had t= o go back in and change the media.peerconnection.enabled setting to true= in Firefox in order to get it to work with the service in question.=20 While this enabled me to conference with teams that desire to use the=20 video conferencing service that rely wholly upon WebRTC, it concerns me=20 because of the security vulnerability.

One suggested mitigation was h= aving NoScript, but using NoScript was not helpful (you generally need to d= isable it for the site you are viewing that relies upon WebRTC, in order to= obtain any functionality, and whether NoScript is off or on, WebRTC still = causes the vulnerability of leaking information as previously described).

Furthermore, upon reload of the browser, even after setting media.= peerconnection.enabled to true, the video conferencing service wouldn't work until I installed the=20 WebRTC 0.1.3 extension for Firefox and set it to expose my real IP=20 address as well as allowing the following:

a. navigator.getUserMedia<= br>b. window.MediaStreamTrack
c. window.RTCPeerConnection
d. window.R= TCSessionDescription

That seemed to me to be a direct consequence= of the persistent and ongoing security vulnerability in WebRTC.

= I contacted the video conferencing service provider and their solution=20 was simply to state that "If the peer to peer connection is of concern= ,=20 you can utilize our=20 premium version which will route traffic through a forwarding server=20 with in our environment that handles the processing of the video and=20 sound of all users in the conference and send it to each user=20 individually rather than using a peer to peer connection."=C2=A0 In ot= her=20 words, they expect that people should have to pay in order to mitigate this WebRTC security vulnerability, because they are unwilling = to design to protect all users from it.

In a similar fashion, in the = second example of the browser based WebRTC version of a decentralized excha= nge, the user's financial information is periodically exposed as a resu= lt of the information leakage which is presently caused by WebRTC.=C2=A0 (F= ortunately, this browser based WebRTC decentralized exchange is under devel= opment and is not currently open to actual usage.)

Although undoubtedly this has been discussed here before, I am asking that WebRTC s= ecurity issues be reconsidered and that a new security review be done to ameliorate or=20 eliminate this problem in terms of WebRTC leaking this information.=C2=A0 I= t is my view that WebRTC should be further designed and developed with an e= ye to mitigating this serious problem, so that users of services which migh= t rely partially or wholly upon WebRTC would not have to be concerned about= such information leakage.

Respectfully,

Colin Gallagher

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




--001a11462f7cda6be80550714e65-- From nobody Fri May 26 14:08:26 2017 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 5B444126B6E for ; Fri, 26 May 2017 14:08: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 9EzWpDE_1SIF for ; Fri, 26 May 2017 14:08:19 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 A79DD126C2F for ; Fri, 26 May 2017 14:08:19 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id k91so16447796ioi.1 for ; Fri, 26 May 2017 14:08:19 -0700 (PDT) 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=o6d3FpGaeGhPsrE7WPAL2UjeEaoOsY632QhuRJOwVJA=; b=vB4fYc3kK0s46rdcdCtf6LNk+NGFG407WxUm9qPCkxkgr8HzfZQkkcvw6rdCg3VV6m XHT3tLCq84kU2LASvHLzbBMbIpYWv9XgT8dquHrYQz7LODD7f0fpl35tt1bTQKtF4T80 7zlZLiiJBdCCuZNB6+uik1buafJ5QGMQ5Ddqw6Zl7lMvwOrY6xn2AdoCUc+m6JrpuCF6 Q9DKqAYf1+AsIgCmo29w7ZH432C++7ZsirPRcsB1hvFmswb3NRJAkuTa61qViyLfa/aR /gqX1zSNLX7acZWUM4pVrFHCEcEppIbFsc6Mb3BZE9G1eB+YwKI0FroNX+Wu7uwF3g7S 3cxg== 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=o6d3FpGaeGhPsrE7WPAL2UjeEaoOsY632QhuRJOwVJA=; b=IXLl5tWGM5kyleBZAAKgnFPyxYkrlqC31Ec7Zbc3ga/xlsJTaVAqVQ4/zCqq1BStSp aNrzlICqMMMXIX23oAZWAxKtnZTLoGwwYXoIUCqlePp/9aqKGeB6cKQRNIANjBVegEu5 f/jppqAaxA0+5XC82+Ayo92IoQn7OqIhd/eLhEXeubGSg/Q18uFmQ4KP2Yu8qrFfd+yv ALTgGY0vMBzPMeoR59U3o8LGYpd6qMsTX7TpAEM577bYPZZSwFdZMa8PUljoB5DDibb2 48VCMLu4XvH0VPw2L9Jyt/jXadYgGQiNzcKQj20eNBwqWuV1gH0oBImU8Twhng1+jf// EQIQ== X-Gm-Message-State: AODbwcDBUycC5t7qCW68PagDnUIvWyf83SYFeb0u1UjRPye9Nq8TSwo5 rxIKFDpZEfspEKSlD9dSMN965sjKt6pf X-Received: by 10.107.133.106 with SMTP id h103mr3784208iod.230.1495832898698; Fri, 26 May 2017 14:08:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.11.149 with HTTP; Fri, 26 May 2017 14:07:58 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Fri, 26 May 2017 14:07:58 -0700 Message-ID: To: Colin Gallagher Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="001a113ff9a692cd96055073bc66" Archived-At: Subject: Re: [rtcweb] Request for New Security Review of WebRTC based on observed vulnerabilities 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, 26 May 2017 21:08:24 -0000 --001a113ff9a692cd96055073bc66 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Colin, The group is absolutely willing to consider new evidence and arguments. However it is not enough to say that there are "obvious security issues" without any explanation of why these issues are serious and/or why the existing document's treatment of them is flawed. Help us understand your specific technical concerns. Justin On Fri, May 26, 2017 at 11:14 AM, Colin Gallagher < colingallagher.rpcv@gmail.com> wrote: > It seems the consensus of the group here is essentially a refusal to > further review and potentially redesign WebRTC to remove the serious > security vulnerabilities that it presents to its users. > > Thank you for your time. I will not further respond to this thread. > > > > On Fri, May 26, 2017 at 10:49 AM, Justin Uberti > wrote: > >> Colin, >> >> As Eric mentioned, the group has reviewed this exact issue, and the >> aforementioned document represents the result of the review. >> >> I am still not quite clear on the exact technical issue you would like t= o >> see addressed and why it is, as you claim, a serious vulnerability. >> >> Comments inline. >> >> On Fri, May 26, 2017 at 12:58 AM, Colin Gallagher < >> colingallagher.rpcv@gmail.com> wrote: >> >>> Justin, >>> >>> It's my understanding that various browsers have made an attempt to >>> conform to the recommendations in the document that you have provided >>> . >>> Unfortunately, at least in Firefox (the most current version) so far as= I >>> can tell, there is a serious vulnerability. To be more specific, the >>> problem was observed in my operating system with my current browser, wh= ich >>> is Ubuntu 16.10 64-bit with Firefox 53.0.2 (64-bit). The browser does = not >>> address the WebRTC problems by default. >>> >>> The stackexchange page that I cited originally is actually not outdated >>> in the sense that its method of measuring whether or not the WebRTC >>> vulnerability exists on a given system is still intact and works. The >>> stackexchange page suggests two pages to determine whether or not you h= ave >>> leakage / WebRTC related vulnerability. These pages are: >>> >>> 1) Browser leaks test for WebRTC https://browserleaks.com/webrtc >>> 2) IP Leaks https://ipleak.net/ >>> >>> Currently for Browser leaks test for WebRTC (due to that I have again >>> changed settings in my system so that I will not have to be exposed to = this >>> vulnerability) the settings show up on the page as: >>> RTCPeerConnection=C3=97False >>> RTCDataChannel=C3=97False >>> ORTC (Microsoft Edge)=C3=97False (for example....) >>> >>> And under IP leaks, it currently shows "No leak, RTCPeerConnection not >>> available." >>> >>> *That is because:* >>> >>> (A) I have (again) changed my settings in about:config back to the >>> following >>> >>> >>> 1. I typed *about:config* in the address bar >>> 2. I found the setting *media.peerconnection.enabled* >>> 3. I set it to *false (it was previously set at true, so as to >>> allow WebRTC to work, but this exposed information which I would not= have >>> wanted to be exposed)* >>> >>> (B) And I also have changed my settings back to the following >>> >>> in the WebRTC 0.1.3 extension for Firefox I have set it to no longer >>> expose my real IP address as well as no longer allowing the following: >>> >>> a. navigator.getUserMedia >>> b. window.MediaStreamTrack >>> c. window.RTCPeerConnection >>> d. window.RTCSessionDescription >>> >>> To be clear, *these mitigations that I have employed above would be >>> unnecessary if WebRTC had not been designed in such a manner that it so >>> clearly exposes so much user information.* >>> >>> In the document you provided >>> , titled >>> "WebRTC IP Address Handling Requirements - draft-ietf-rtcweb-ip-handlin= g-03," >>> it is stated that: >>> >>> *"1. If the client is behind a NAT, the client's private IP addresses, >>> typically [RFC1918 ] addresses, ca= n be >>> learned. * >>> >>> >>> >>> * 2. If the client tries to hide its physical location through a VPN, >>> and the VPN and local OS support routing over multiple interface= s >>> (i.e., a "split-tunnel" VPN), WebRTC will discover the public >>> address for the VPN as well as the ISP public address that the >>> VPN runs over. >>> >>> 3. If the client is behind a proxy (a client-configured "classical >>> application proxy", as defined in [RFC1919], Section 3 ), but >>> direct access to the Internet is also supported, WebRTC's STUN >>> [RFC5389 ]checks will bypas= s the proxy and reveal the public >>> address of the client."* >>> >>> All of these are obvious vulnerabilities and serious problems (not only= #2 as the document suggests). >>> >>> >> The document discusses #1 and #3 in detail, and outlines mechanisms that >> can be used to address these cases if needed. >> >> If, despite the findings in the document, you think that these are indee= d >> serious problems, it would be good to outline exactly why. >> >>> >>> It is stated in the document that, >>> >>> >>> >>> *"we want to avoid solutions that disable WebRTC or make it harder to u= se."* >>> >>> Yet, so far as my observations of WebRTC in the current version of Fire= fox with Ubuntu 16.10 have shown, >>> >>> there appears to be no other choice other than to disable WebRTC becaus= e its use completely compromises >>> >>> privacy and thus makes all other aspects of your system more difficult = generally. >>> >>> >>> It is stated in the document you cited that the goals here are to "Prov= ide a privacy-friendly default behavior which strikes the >>> right balance between privacy and media performance for most user= s >>> and use cases. (and) For users who care more about one versus the= other, provide a >>> means to customize the experience." >>> >>> This has clearlly not been accomplished in the context of Ubuntu 16.10 = 64-bit with Firefox 53.0.2 (64-bit). >>> >>> Hence my request for a new security review of WebRTC based on observed = vulnerabilities. >>> >>> >> To my knowledge, the document addresses these goals. If you believe >> Firefox is not conforming, please file a bug; if you think the document = is >> in error, please point out where and why. >> >>> >>> >>> >>> On Thu, May 25, 2017 at 1:04 PM, Justin Uberti >>> wrote: >>> >>>> Colin, >>>> >>>> This is an important topic, and the group has reviewed this situation >>>> in detail. The results have been written up in this document >>>> , and to >>>> my knowledge most browsers that support WebRTC currently conform to it= s >>>> recommendations. >>>> >>>> However, I'm not totally clear on your specific technical concern. You >>>> linked to an (now outdated) stackexchange page, but could you provide = more >>>> detail about the specific situation you are concerned about? >>>> >>>> Justin >>>> >>>> On Wed, May 24, 2017 at 5:35 PM, Colin Gallagher < >>>> colingallagher.rpcv@gmail.com> wrote: >>>> >>>>> To: IETF RTCWeb WG >>>>> >>>>> From: Colin Gallagher >>>>> https://www.linkedin.com/in/colingallagher >>>>> https://lifeboat.com/ex/bios.colin.gallagher >>>>> >>>>> Request for New Security Review of WebRTC based on observed >>>>> vulnerabilities in certain examples >>>>> >>>>> Dear IETF RTCWeb WG, >>>>> >>>>> This request relates to WebRTC. The WebRTC is in draft at >>>>> https://w3c.github.io/webrtc-pc/ and is described also at >>>>> https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API# >>>>> WebRTC_interfaces >>>>> >>>>> There are certain examples where the use of WebRTC has presented >>>>> security vulnerabilities. While not exhaustive, there are two I want= ed to >>>>> mention that I had been exposed to recently. >>>>> >>>>> 1) The use of a video conferencing service which relies upon WebRTC >>>>> (that is a well established service) >>>>> 2) The examination of a browser based WebRTC version of a >>>>> decentralized exchange (that is currently under development) >>>>> >>>>> In both cases the security vulnerability which is described below was >>>>> the result of the use of WebRTC. >>>>> >>>>> The problem under consideration is as follows: >>>>> >>>>> As per the first example (the video conferencing service), recently I >>>>> came upon a vendor who shall remain unnamed who uses WebRTC as the ba= ckbone >>>>> for their video conferencing service. As a result, I found I was una= ble to >>>>> access the service in question without disabling some security settin= gs >>>>> which I would have preferred to leave intact. >>>>> >>>>> My system is (based on what the aforementioned service detects) >>>>> Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 >>>>> Firefox/53.0. This is Ubuntu 16.10 64-bit with Firefox 53.0.2. >>>>> >>>>> However, quite some *long* while back I disabled WebRTC because of >>>>> the security vulnerability (described in part here on information >>>>> security stack exchange >>>>> ). >>>>> So as to mitigate this vulnerability, I changed settings in Firefox a= s >>>>> follows: >>>>> >>>>> >>>>> 1. I typed *about:config* in the address bar >>>>> 2. I found the setting *media.peerconnection.enabled* >>>>> 3. I set it to *false* >>>>> >>>>> Unfortunately, this setting does not allow Firefox to work with the >>>>> video conferencing service in question, which relies entirely on WebR= TC. >>>>> >>>>> So I had to go back in and change the media.peerconnection.enabled >>>>> setting to *true* in Firefox in order to get it to work with the >>>>> service in question. While this enabled me to conference with teams t= hat >>>>> desire to use the video conferencing service that rely wholly upon We= bRTC, >>>>> it concerns me because of the security vulnerability. >>>>> >>>>> One suggested mitigation was having NoScript, but using NoScript was >>>>> not helpful (you generally need to disable it for the site you are vi= ewing >>>>> that relies upon WebRTC, in order to obtain any functionality, and wh= ether >>>>> NoScript is off or on, WebRTC still causes the vulnerability of leaki= ng >>>>> information as previously described). >>>>> >>>>> Furthermore, upon reload of the browser, even after setting >>>>> media.peerconnection.enabled to *true*, the video conferencing >>>>> service wouldn't work until I installed the WebRTC 0.1.3 extension fo= r >>>>> Firefox and set it to expose my real IP address as well as allowing t= he >>>>> following: >>>>> >>>>> a. navigator.getUserMedia >>>>> b. window.MediaStreamTrack >>>>> c. window.RTCPeerConnection >>>>> d. window.RTCSessionDescription >>>>> >>>>> That seemed to me to be a direct consequence of the persistent and >>>>> ongoing security vulnerability in WebRTC. >>>>> >>>>> I contacted the video conferencing service provider and their solutio= n >>>>> was simply to state that "If the peer to peer connection is of concer= n, you >>>>> can utilize our premium version which will route traffic through a >>>>> forwarding server with in our environment that handles the processing= of >>>>> the video and sound of all users in the conference and send it to eac= h user >>>>> individually rather than using a peer to peer connection." In other = words, >>>>> they expect that people should have to pay in order to mitigate this >>>>> WebRTC security vulnerability >>>>> , >>>>> because they are unwilling to design to protect all users from it. >>>>> >>>>> In a similar fashion, in the second example of the browser based >>>>> WebRTC version of a decentralized exchange, the user's financial >>>>> information is periodically exposed as a result of the information le= akage >>>>> which is presently caused by WebRTC. (Fortunately, this browser base= d >>>>> WebRTC decentralized exchange is under development and is not current= ly >>>>> open to actual usage.) >>>>> >>>>> Although undoubtedly this has been discussed here before, I am asking >>>>> that WebRTC security issues be reconsidered and that a new security r= eview >>>>> be done to ameliorate or eliminate this problem in terms of WebRTC le= aking >>>>> this information. It is my view that WebRTC should be further design= ed and >>>>> developed with an eye to mitigating this serious problem, so that use= rs of >>>>> services which might rely partially or wholly upon WebRTC would not h= ave to >>>>> be concerned about such information leakage. >>>>> >>>>> Respectfully, >>>>> Colin Gallagher >>>>> >>>>> >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>> >>>>> >>>> >>> >> > --001a113ff9a692cd96055073bc66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Colin,

The group is absolutely willing = to consider new evidence and arguments.=C2=A0

Howe= ver it is not enough to say that there are "obvious security issues&qu= ot; without any explanation of why these issues are serious and/or why the = existing document's treatment of them is flawed.

Help us understand your specific technical concerns.

<= /div>
Justin

On Fri, May 26, 2017 at 11:14 AM, Colin Gallagher <= colingallagher.rpcv@gmail.com> wrote:
It seems the consensus of the group here i= s essentially a refusal to further review and potentially redesign WebRTC t= o remove the serious security vulnerabilities that it presents to its users= .

Thank you for your time.=C2=A0 I will not further respond to= this thread.



On Fri, M= ay 26, 2017 at 10:49 AM, Justin Uberti <juberti@google.com>= wrote:
Colin,

<= /div>
As Eric mentioned, the group has reviewed this exact issue, and t= he aforementioned document represents the result of the review.
<= br>
I am still not quite clear on the exact technical issue you w= ould like to see addressed and why it is, as you claim, a serious vulnerabi= lity.

Comments inline.

On Fri, May 26, 2017 at 12:58 AM, Colin Gallagher &= lt;colin= gallagher.rpcv@gmail.com> wrote:
Justin,=

It's my understanding that various browsers have made an = attempt to conform to the recommendations in the document t= hat you have provided.=C2=A0 Unfortunately, at least in Firefox (the mo= st current version) so far as I can tell, there is a serious vulnerability.= =C2=A0 To be more specific, the problem was observed in my operating system= with my current browser, which is Ubuntu 16.10 64-bit with Firefox=20 53.0.2 (64-bit).=C2=A0 The browser does not address the WebRTC problems by = default.

The stackexchange page that I cited originally is act= ually not outdated in the sense that its method of measuring whether or not= the WebRTC vulnerability exists on a given system is still intact and work= s.=C2=A0 The stackexchange page suggests two pages to determine whether or = not you have leakage / WebRTC related vulnerability.=C2=A0 These pages are:=

1) Browser leaks test for WebRTC https://browserleaks.com/webrtc<= br>
2) IP Leaks http= s://ipleak.net/

Currently for Browser leaks test for WebRT= C (due to that I have again changed settings in my system so that I will no= t have to be exposed to this vulnerability) the settings show up on the pag= e as:
RTCPeerConnection=C3=97False
RTCDataChann= el=C3=97False
ORTC (Microsoft Edge)= =C3=97False (for example....)

And under IP leaks, it cu= rrently shows "No leak, RTCPeerConnection not available."=C2=A0 <= br>
That is because:

(A) I have (again) change= d my settings in about:config back to the following

  1. I = typed about:config in the address bar
  2. I found the setting = media.peerconnection.enabled
  3. I set it to fa= lse=C2=A0 (it was previously set at true, so as to allow WebRTC to work, bu= t this exposed information which I would not have wanted to be exposed)

(B) And I also have changed my settings back to the follo= wing

in the WebRTC 0.1.3 extension for Firefox I have set it to no lo= nger expose my real IP=20 address as well as no longer allowing the following:

a. navigat= or.getUserMedia
b. window.MediaStreamTrack
c. window.RTCPeerConnectio= n
d. window.RTCSessionDescription

To be clear, these mit= igations that I have employed above would be unnecessary if WebRTC had not = been designed in such a manner that it so clearly exposes so much user info= rmation.

In the document you provided, titled= "WebRTC IP Address Handling Requirements - draft-ietf-rtcweb-ip-handl= ing-03," it is stated that:

"1. If the client is behind a NAT, the cli= ent's private IP addresses, typically [RFC1918] addresses, can be learned. 

 2.  If the client tries to hide its physical location thro=
ugh a VPN,
       and the VPN and local OS support routing over multiple interfaces
       (i.e., a "split-tunnel" VPN), WebRTC will discover the pub=
lic
       address for the VPN as well as the ISP public address that the
       VPN runs over.

   3.  If the client is behind a proxy (a client-configured "classical
       application proxy", as defined in [RFC1919], Section=C2=A03), but
       direct access to the Internet is also supported, WebRTC's STUN
       [RFC5389=
]checks will bypass the proxy and reveal the public
       address of the client."

All of these are =
obvious vulnerabilities and serious problems (not only #2 as the document s=
uggests).

The document discusses #1 and #3 in detail, and outlines mechanisms that = can be used to address these cases if needed.

If, = despite the findings in the document, you think that these are indeed serio= us problems, it would be good to outline exactly why.

It is stated in the docu=
ment that, 

"we want to avoid solutions that disable WebRTC =
or make it harder to use."

<=
span style=3D"font-family:arial,helvetica,sans-serif">Yet, so far as my obs=
ervations of WebRTC in the current version of Firefox with Ubuntu 16.10 hav=
e shown,
there appears to be no other choice other than to di=
sable WebRTC because its use completely compromises 
privacy =
and thus makes all other aspects of your system more difficult generally.

It is stated in the document you cited that the goals here =
are to "Provide a privacy-friendly default behavior which strik=
es the
      right balance between privacy and media performance for most users
      and use cases. (and) For users who care more about one versus the oth=
er, provide a
      means to customize the experience."
This has clearlly not bee=
n accomplished in the context of Ubuntu 16.10 64-bit with Firefox 53.0.2 (6=
4-bit).

Hence my request for a new security review of Web=
RTC based on observed vulnerabilities.
<= div>
To my knowledge, the document addresses these goa= ls. If you believe Firefox is not conforming, please file a bug; if you thi= nk the document is in error, please point out where and why.




On Thu, May 25, = 2017 at 1:04 PM, Justin Uberti <juberti@google.com> wrote:<= br>
Colin,

This is an important topic, and the group has reviewed this situation in = detail. The results have been written up in this document, and to my knowledge most browsers that support WebRTC currently conform= to its recommendations.



<= div>
To:=C2=A0 IETF RTCWeb WG

From:=C2=A0 Colin Gallagher<= br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https:/= /www.linkedin.com/in/colingallagher
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://lifeboat.com/ex/bios.colin.g= allagher

Request for New Security Review of WebRTC based o= n observed vulnerabilities in certain examples

Dear IETF RTCWe= b WG,

This request relates to WebRTC.=C2=A0 The WebRTC is= in draft at https://w3c.github.io/webrtc-pc/ and is=20 described also at=20 https://developer.mozilla.org/en-US/d= ocs/Web/API/WebRTC_API#WebRTC_interfaces

There= are certain examples where the use of WebRTC has presented security vulner= abilities.=C2=A0 While not exhaustive, there are two I wanted to mention th= at I had been exposed to recently.

1) The use of a = video conferencing service which relies upon WebRTC (that is a well establi= shed service)
2) The examination of a browser based WebRTC version= of a decentralized exchange (that is currently under development)

<= /div>In both cases the security vulnerability which is described below was = the result of the use of WebRTC.

The problem under consideration is = as follows:

As per the first example (the video conferencing service= ), recently I came upon a vendor who shall remain unnamed who uses WebRTC as the=20 backbone for their video conferencing service.=C2=A0 As a result, I found I= =20 was unable to access the service in question without disabling some=20 security settings which I would have preferred to leave intact.

My = system is (based on what the aforementioned service detects) Mozilla/5.0 (X= 11; Ubuntu; Linux x86_64; rv:53.0)=20 Gecko/20100101 Firefox/53.0.=C2=A0 This is Ubuntu 16.10 64-bit with Firefox= =20 53.0.2.

However, quite some long while back I disabled WebRTC= because of the security vulnerability (described in part here = on information security stack exchange).=C2=A0 So as to mitigate this v= ulnerability, I changed settings in Firefox as follows:

  1. I ty= ped about:config in the address bar
  2. I found the setting media.peerconnection.enabled
  3. I set it to false

Unfortunately, this setting does not allow Firefox to work with the video conferencing service in question, which relies entirely on WebRTC.

So I had t= o go back in and change the media.peerconnection.enabled setting to true= in Firefox in order to get it to work with the service in question.=20 While this enabled me to conference with teams that desire to use the=20 video conferencing service that rely wholly upon WebRTC, it concerns me=20 because of the security vulnerability.

One suggested mitigation was h= aving NoScript, but using NoScript was not helpful (you generally need to d= isable it for the site you are viewing that relies upon WebRTC, in order to= obtain any functionality, and whether NoScript is off or on, WebRTC still = causes the vulnerability of leaking information as previously described).

Furthermore, upon reload of the browser, even after setting media.= peerconnection.enabled to true, the video conferencing service wouldn't work until I installed the=20 WebRTC 0.1.3 extension for Firefox and set it to expose my real IP=20 address as well as allowing the following:

a. navigator.getUserMedia<= br>b. window.MediaStreamTrack
c. window.RTCPeerConnection
d. window.R= TCSessionDescription

That seemed to me to be a direct consequence= of the persistent and ongoing security vulnerability in WebRTC.

= I contacted the video conferencing service provider and their solution=20 was simply to state that "If the peer to peer connection is of concern= ,=20 you can utilize our=20 premium version which will route traffic through a forwarding server=20 with in our environment that handles the processing of the video and=20 sound of all users in the conference and send it to each user=20 individually rather than using a peer to peer connection."=C2=A0 In ot= her=20 words, they expect that people should have to pay in order to mitigate this WebRTC security vulnerability, because they are unwilling = to design to protect all users from it.

In a similar fashion, in the = second example of the browser based WebRTC version of a decentralized excha= nge, the user's financial information is periodically exposed as a resu= lt of the information leakage which is presently caused by WebRTC.=C2=A0 (F= ortunately, this browser based WebRTC decentralized exchange is under devel= opment and is not currently open to actual usage.)

Although undoubtedly this has been discussed here before, I am asking that WebRTC s= ecurity issues be reconsidered and that a new security review be done to ameliorate or=20 eliminate this problem in terms of WebRTC leaking this information.=C2=A0 I= t is my view that WebRTC should be further designed and developed with an e= ye to mitigating this serious problem, so that users of services which migh= t rely partially or wholly upon WebRTC would not have to be concerned about= such information leakage.

Respectfully,

Colin Gallagher

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





--001a113ff9a692cd96055073bc66-- From nobody Fri May 26 17:34:28 2017 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 4052F1288B8 for ; Fri, 26 May 2017 17:34:27 -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, MIME_QP_LONG_LINE=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 CMBscJkdfmqD for ; Fri, 26 May 2017 17:34:24 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 0CD4E126D05 for ; Fri, 26 May 2017 17:34:24 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id 9so23954320pfj.1 for ; Fri, 26 May 2017 17:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oXwq+K32QugOMIL0jHaFmF2LI+FSq/DlykSkz2oWZ3g=; b=Ir92NivXeoDDBzVXvkR4GcQySL7pQ85Hx95fIcSKUSKdoxblY2onifOphd6yAAFV8a PbiQX7uB5xrFykSYcLH80A0SL7FWbzIemBikaS/l5RGp++p0GNn/rsvovgj28wacrLPr HiiTIqhNwC2re8fLKpSAsP7UANK8vcU04BPqF6/9Z5pOR7r027043wB1c8FRat2foEuA KlnOYG99aQa3qfmRgQTGGfNzwyjs75ekDma65X91purPrXfUzRMetLOUFFLSbmOnsmJU fm1kgbDpzyqKTvqN17CTHK1gMuuLppLpJ2O5a7TUX+NarJ2FMp+On3vXALoCtA7rzHB4 6rdw== 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=oXwq+K32QugOMIL0jHaFmF2LI+FSq/DlykSkz2oWZ3g=; b=sXlGeIMp9mYgLzDJCW9qHNksuIc2UIDM458V71fYUtz5NXkI9/qpLxAwe5IM5SFX64 Jv8ql3zLZ1L8itNw2PpKE4lRcZl43w1iF+0yFQVaVG5jjpO22XNNYZx0dQeSG/bC+Qp9 Hf1xptPFDLHFEfJt2nY0ggy/GMFa+9K95rl8jQ6FUzpzc3uD0PrSA82IJOEppOts0hHg aGa4YNorggq7DdJkPToPXEq8QfTc7ZLbh0xTC+q1jRY0SuNZvlmT7t2Edkjs3nb+lhy2 j7lvWYBV7cFGvn3HWDzk3clzJm80V376k4hPmwsloaHP2d05Uae2tOo4x0OZyPm1/1fc PSBw== X-Gm-Message-State: AODbwcAGOHsp61Zfp90cbhyaum3cHjUXd5YqSaIN0hGqNO138GgQW/KC GhWp76SLNdFjtsSMf+o= X-Received: by 10.98.209.22 with SMTP id z22mr5212944pfg.95.1495845263298; Fri, 26 May 2017 17:34:23 -0700 (PDT) Received: from [10.235.54.162] (mobile-166-176-186-86.mycingular.net. [166.176.186.86]) by smtp.gmail.com with ESMTPSA id p89sm4150426pfk.67.2017.05.26.17.34.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 May 2017 17:34:22 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-A12E5498-9FE5-41BD-9DA8-A1B8519F0018 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Fri, 26 May 2017 17:34:20 -0700 Cc: Colin Gallagher , Justin Uberti , Shijun Sun Content-Transfer-Encoding: 7bit Message-Id: References: To: rtcweb@ietf.org Archived-At: Subject: Re: [rtcweb] Request for New Security Review of WebRTC based on observed vulnerabilities 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, 27 May 2017 00:34:27 -0000 --Apple-Mail-A12E5498-9FE5-41BD-9DA8-A1B8519F0018 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Colin -=20 Are you claiming that the recommendations of the document Justin refers to a= re inadequate, or just that some browsers have not fully or correctly implem= ented it?=20 If the former, what would you propose to change? > On May 26, 2017, at 10:49 AM, Justin Uberti wrote: >=20 > Colin, >=20 > As Eric mentioned, the group has reviewed this exact issue, and the aforem= entioned document represents the result of the review. >=20 > I am still not quite clear on the exact technical issue you would like to s= ee addressed and why it is, as you claim, a serious vulnerability. >=20 > Comments inline. >=20 >> On Fri, May 26, 2017 at 12:58 AM, Colin Gallagher wrote: >> Justin, >>=20 >> It's my understanding that various browsers have made an attempt to confo= rm to the recommendations in the document that you have provided. Unfortuna= tely, at least in Firefox (the most current version) so far as I can tell, t= here is a serious vulnerability. To be more specific, the problem was obser= ved in my operating system with my current browser, which is Ubuntu 16.10 64= -bit with Firefox 53.0.2 (64-bit). The browser does not address the WebRTC p= roblems by default. >>=20 >> The stackexchange page that I cited originally is actually not outdated i= n the sense that its method of measuring whether or not the WebRTC vulnerabi= lity exists on a given system is still intact and works. The stackexchange p= age suggests two pages to determine whether or not you have leakage / WebRTC= related vulnerability. These pages are: >>=20 >> 1) Browser leaks test for WebRTC https://browserleaks.com/webrtc >> 2) IP Leaks https://ipleak.net/ >>=20 >> Currently for Browser leaks test for WebRTC (due to that I have again cha= nged settings in my system so that I will not have to be exposed to this vul= nerability) the settings show up on the page as: >> RTCPeerConnection=C3=97False >> RTCDataChannel=C3=97False >> ORTC (Microsoft Edge)=C3=97False (for example....) >>=20 >> And under IP leaks, it currently shows "No leak, RTCPeerConnection not av= ailable." =20 >>=20 >> That is because: >>=20 >> (A) I have (again) changed my settings in about:config back to the follow= ing >>=20 >> I typed about:config in the address bar >> I found the setting media.peerconnection.enabled >> I set it to false (it was previously set at true, so as to allow WebRTC t= o work, but this exposed information which I would not have wanted to be exp= osed) >> (B) And I also have changed my settings back to the following >>=20 >> in the WebRTC 0.1.3 extension for Firefox I have set it to no longer expo= se my real IP address as well as no longer allowing the following: >>=20 >> a. navigator.getUserMedia >> b. window.MediaStreamTrack >> c. window.RTCPeerConnection >> d. window.RTCSessionDescription >>=20 >> To be clear, these mitigations that I have employed above would be unnece= ssary if WebRTC had not been designed in such a manner that it so clearly ex= poses so much user information. >>=20 >> In the document you provided, titled "WebRTC IP Address Handling Requirem= ents - draft-ietf-rtcweb-ip-handling-03," it is stated that: >>=20 >> "1. If the client is behind a NAT, the client's private IP addresses, typ= ically [RFC1918] addresses, can be learned. >>=20 >> 2. If the client tries to hide its physical location through a VPN, >> and the VPN and local OS support routing over multiple interfaces >> (i.e., a "split-tunnel" VPN), WebRTC will discover the public >> address for the VPN as well as the ISP public address that the >> VPN runs over. >>=20 >> 3. If the client is behind a proxy (a client-configured "classical >> application proxy", as defined in [RFC1919], Section 3), but >> direct access to the Internet is also supported, WebRTC's STUN >> [RFC5389]checks will bypass the proxy and reveal the public >> address of the client." >>=20 >> All of these are obvious vulnerabilities and serious problems (not only #= 2 as the document suggests). >=20 > The document discusses #1 and #3 in detail, and outlines mechanisms that c= an be used to address these cases if needed. >=20 > If, despite the findings in the document, you think that these are indeed s= erious problems, it would be good to outline exactly why. >>=20 >> It is stated in the document that,=20 >>=20 >> "we want to avoid solutions that disable WebRTC or make it harder to use.= " >>=20 >> Yet, so far as my observations of WebRTC in the current version of Firefo= x with Ubuntu 16.10 have shown, >> there appears to be no other choice other than to disable WebRTC because i= ts use completely compromises=20 >> privacy and thus makes all other aspects of your system more difficult ge= nerally. >>=20 >> It is stated in the document you cited that the goals here are to "Provid= e a privacy-friendly default behavior which strikes the >> right balance between privacy and media performance for most users >> and use cases. (and) For users who care more about one versus the o= ther, provide a >> means to customize the experience." >> This has clearlly not been accomplished in the context of Ubuntu 16.10 64= -bit with Firefox 53.0.2 (64-bit). >>=20 >> Hence my request for a new security review of WebRTC based on observed vu= lnerabilities. >=20 > To my knowledge, the document addresses these goals. If you believe Firefo= x is not conforming, please file a bug; if you think the document is in erro= r, please point out where and why. >>=20 >>=20 >>=20 >>> On Thu, May 25, 2017 at 1:04 PM, Justin Uberti wrot= e: >>> Colin, >>>=20 >>> This is an important topic, and the group has reviewed this situation in= detail. The results have been written up in this document, and to my knowle= dge most browsers that support WebRTC currently conform to its recommendatio= ns. >>>=20 >>> However, I'm not totally clear on your specific technical concern. You l= inked to an (now outdated) stackexchange page, but could you provide more de= tail about the specific situation you are concerned about? >>>=20 >>> Justin >>>=20 >>>> On Wed, May 24, 2017 at 5:35 PM, Colin Gallagher wrote: >>>> To: IETF RTCWeb WG >>>>=20 >>>> From: Colin Gallagher >>>> https://www.linkedin.com/in/colingallagher >>>> https://lifeboat.com/ex/bios.colin.gallagher >>>>=20 >>>> Request for New Security Review of WebRTC based on observed vulnerabili= ties in certain examples >>>>=20 >>>> Dear IETF RTCWeb WG, >>>>=20 >>>> This request relates to WebRTC. The WebRTC is in draft at https://w3c.= github.io/webrtc-pc/ and is described also at https://developer.mozilla.org/= en-US/docs/Web/API/WebRTC_API#WebRTC_interfaces >>>>=20 >>>> There are certain examples where the use of WebRTC has presented securi= ty vulnerabilities. While not exhaustive, there are two I wanted to mention= that I had been exposed to recently. >>>>=20 >>>> 1) The use of a video conferencing service which relies upon WebRTC (th= at is a well established service) >>>> 2) The examination of a browser based WebRTC version of a decentralized= exchange (that is currently under development) >>>>=20 >>>> In both cases the security vulnerability which is described below was t= he result of the use of WebRTC. >>>>=20 >>>> The problem under consideration is as follows: >>>>=20 >>>> As per the first example (the video conferencing service), recently I c= ame upon a vendor who shall remain unnamed who uses WebRTC as the backbone f= or their video conferencing service. As a result, I found I was unable to a= ccess the service in question without disabling some security settings which= I would have preferred to leave intact.=20 >>>>=20 >>>> My system is (based on what the aforementioned service detects) Mozilla= /5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0. This= is Ubuntu 16.10 64-bit with Firefox 53.0.2. >>>>=20 >>>> However, quite some long while back I disabled WebRTC because of the se= curity vulnerability (described in part here on information security stack e= xchange). So as to mitigate this vulnerability, I changed settings in Firef= ox as follows: >>>>=20 >>>> I typed about:config in the address bar >>>> I found the setting media.peerconnection.enabled >>>> I set it to false >>>> Unfortunately, this setting does not allow Firefox to work with the vid= eo conferencing service in question, which relies entirely on WebRTC. >>>>=20 >>>> So I had to go back in and change the media.peerconnection.enabled sett= ing to true in Firefox in order to get it to work with the service in questi= on. While this enabled me to conference with teams that desire to use the vi= deo conferencing service that rely wholly upon WebRTC, it concerns me becaus= e of the security vulnerability. >>>>=20 >>>> One suggested mitigation was having NoScript, but using NoScript was no= t helpful (you generally need to disable it for the site you are viewing tha= t relies upon WebRTC, in order to obtain any functionality, and whether NoSc= ript is off or on, WebRTC still causes the vulnerability of leaking informat= ion as previously described). >>>>=20 >>>> Furthermore, upon reload of the browser, even after setting media.peerc= onnection.enabled to true, the video conferencing service wouldn't work unti= l I installed the WebRTC 0.1.3 extension for Firefox and set it to expose my= real IP address as well as allowing the following: >>>>=20 >>>> a. navigator.getUserMedia >>>> b. window.MediaStreamTrack >>>> c. window.RTCPeerConnection >>>> d. window.RTCSessionDescription >>>>=20 >>>> That seemed to me to be a direct consequence of the persistent and ongo= ing security vulnerability in WebRTC. >>>>=20 >>>> I contacted the video conferencing service provider and their solution w= as simply to state that "If the peer to peer connection is of concern, you c= an utilize our premium version which will route traffic through a forwarding= server with in our environment that handles the processing of the video and= sound of all users in the conference and send it to each user individually r= ather than using a peer to peer connection." In other words, they expect th= at people should have to pay in order to mitigate this WebRTC security vulne= rability, because they are unwilling to design to protect all users from it.= >>>>=20 >>>> In a similar fashion, in the second example of the browser based WebRTC= version of a decentralized exchange, the user's financial information is pe= riodically exposed as a result of the information leakage which is presently= caused by WebRTC. (Fortunately, this browser based WebRTC decentralized ex= change is under development and is not currently open to actual usage.) >>>>=20 >>>> Although undoubtedly this has been discussed here before, I am asking t= hat WebRTC security issues be reconsidered and that a new security review be= done to ameliorate or eliminate this problem in terms of WebRTC leaking thi= s information. It is my view that WebRTC should be further designed and dev= eloped with an eye to mitigating this serious problem, so that users of serv= ices which might rely partially or wholly upon WebRTC would not have to be c= oncerned about such information leakage. >>>>=20 >>>> Respectfully, >>>>=20 >>>> Colin Gallagher >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-A12E5498-9FE5-41BD-9DA8-A1B8519F0018 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Colin - 
Are you claiming that the recommendations of the document Justin= refers to are inadequate, or just that some browsers have not fully or corr= ectly implemented it? 

If the former, what wou= ld you propose to change?

On May 26, 2017, at 10:49 AM, Justin= Uberti <juberti@google.com>= wrote:

Colin,<= div>
As Eric mentioned, the group has reviewed this exact issu= e, and the aforementioned document represents the result of the review.

I am still not quite clear on the exact technical issue= you would like to see addressed and why it is, as you claim, a serious vuln= erability.

Comments inline.

On Fri, May 26, 2017 at 12:58 AM, Co= lin Gallagher <colingallagher.rpcv@gmail.com> wrot= e:
Justin,

It's my understanding that various bro= wsers have made an attempt to conform to the recommendations in the document that you have provided.  Unfortunately, at least in= Firefox (the most current version) so far as I can tell, there is a serious= vulnerability.  To be more specific, the problem was observed in my op= erating system with my current browser, which is Ubuntu 16.10 64-bit with Fi= refox=20 53.0.2 (64-bit).  The browser does not address the WebRTC problems by d= efault.

The stackexchange page that I cited originally is actua= lly not outdated in the sense that its method of measuring whether or not th= e WebRTC vulnerability exists on a given system is still intact and works.&n= bsp; The stackexchange page suggests two pages to determine whether or not y= ou have leakage / WebRTC related vulnerability.  These pages are:
1) Browser leaks test for WebRTC https://browserleaks.com/webrtc
2) IP Leaks https://iplea= k.net/

Currently for Browser leaks test for WebRTC (due to t= hat I have again changed settings in my system so that I will not have to be= exposed to this vulnerability) the settings show up on the page as:
RTCP= eerConnection=C3=97Fal= se
RTCDataChannel=C3=97False
ORTC (Microsoft Edge)=C3=97False (for example....)

And under IP leaks, i= t currently shows "No leak, RTCPeerConnection not available." 

=
That is because:

(A) I have (again) changed my set= tings in about:config back to the following

  1. = I typed about:config in the address bar
  2. I found the setting= media.peerconnection.enabled
  3. I set it to fa= lse  (it was previously set at true, so as to allow WebRTC to work, but= this exposed information which I would not have wanted to be exposed)

(B) And I also have changed my settings back to the followin= g

in the WebRTC 0.1.3 extension for Firefox I have set it to no longer= expose my real IP=20 address as well as no longer allowing the following:

= a. navigator.getUserMedia
b. window.MediaStreamTrack
c. window.RTCPeer= Connection
d. window.RTCSessionDescription

To be clear, t= hese mitigations that I have employed above would be unnecessary if WebRTC h= ad not been designed in such a manner that it so clearly exposes so much use= r information.

In the document you provided, ti= tled "WebRTC IP Address Handling Requirements - draft-ietf-rtcweb-ip-handlin= g-03," it is stated that:

"1. If the client is behind a NAT, the client's private I= P addresses, typically [RFC1918] addresses, can be learned. 

 2.  If the client tries to h=
ide its physical location through a VPN,
       and the VPN and local OS support routing over multiple interfaces
       (i.e., a "split-tunnel" VPN), WebRTC will discover the public
       address for the VPN as well as the ISP public address that the
       VPN runs over.

   3.  If the client is behind a proxy (a client-configured "classical
       application proxy", as defined in [RFC1919], Section 3), but=

       direct access to the Internet is also supported, WebRTC's STUN
       [RFC5389]c=
hecks will bypass the proxy and reveal the public
       address of the client."

All of these are obvious vulnerabilities and serious problems (not o=
nly #2 as the document suggests).
The document discusses #1 and #3 in detail, and outlines mechan= isms that can be used to address these cases if needed.

=
If, despite the findings in the document, you think that these are inde= ed serious problems, it would be good to outline exactly why.

It is stated in the document that, 
=

"we want to avoid solutions that disable WebRTC or make it harder to u=
se."

Yet, so far as my o=
bservations of WebRTC in the current version of Firefox with Ubuntu 16.10 ha=
ve shown,
=
there appears to be n=
o other choice other than to disable WebRTC because its use completely compr=
omises 
privacy and thus makes a=
ll other aspects of your system more difficult generally.
= 

It is stated in t=
he document you cited that the goals here are to "Provide a privacy-f=
riendly default behavior which strikes the
      right balance between privacy and media performance for most users
      and use cases. (and) For users who care more about one versus the othe=
r, provide a
      means to customize the experience."
=
This has clearlly not been accomplished in the context of Ubuntu 16.10 64-bi=
t with Firefox 53.0.2 (64-bit).

Hence my request for a new security review of WebRTC based on observed v=
ulnerabilities.

To my= knowledge, the document addresses these goals. If you believe Firefox is no= t conforming, please file a bug; if you think the document is in error, plea= se point out where and why.


<= div>


On Thu= , May 25, 2017 at 1:04 PM, Justin Uberti <juberti@google.com>= wrote:
Colin,

This is an important topic, and the group has reviewed this situatio= n in detail. The results have been written up in this documen= t, and to my knowledge most browsers that support WebRTC currently confo= rm to its recommendations.

However, I'm not totally= clear on your specific technical concern. You linked to an (now outdated) s= tackexchange page, but could you provide more detail about the specific situ= ation you are concerned about?

Justin

On Wed, May 24, 2017 at 5:35 PM, Colin Gallagher <colingallagher.rpcv@gmail.com> wrote:
<= /div>
To:  IETF R= TCWeb WG

From:  Colin Gallagher
   = ;        https://www.linkedin.com/in/co= lingallagher
         &n= bsp; https://lifeboat.com/ex/bios.colin.gallagher

Reque= st for New Security Review of WebRTC based on observed vulnerabilities in ce= rtain examples

Dear IETF RTCWeb WG,

This requ= est relates to WebRTC.  The WebRTC is in draft at https://w3c.github.io/webrtc-pc/ and is=20 described also at=20 https://developer.mozilla.org/en-US/doc= s/Web/API/WebRTC_API#WebRTC_interfaces

There ar= e certain examples where the use of WebRTC has presented security vulnerabil= ities.  While not exhaustive, there are two I wanted to mention that I h= ad been exposed to recently.

1) The use of a video c= onferencing service which relies upon WebRTC (that is a well established ser= vice)
2) The examination of a browser based WebRTC version of a dec= entralized exchange (that is currently under development)

In bo= th cases the security vulnerability which is described below was the result o= f the use of WebRTC.

The problem under consideration is as follows:
As per the first example (the video conferencing service), recently I came upon a vendor who shall remain unnamed who uses WebRTC as the=20 backbone for their video conferencing service.  As a result, I found I=20= was unable to access the service in question without disabling some=20 security settings which I would have preferred to leave intact.

My s= ystem is (based on what the aforementioned service detects) Mozilla/5.0 (X11= ; Ubuntu; Linux x86_64; rv:53.0)=20 Gecko/20100101 Firefox/53.0.  This is Ubuntu 16.10 64-bit with Firefox=20= 53.0.2.

However, quite some long while back I disabled WebRTC b= ecause of the security vulnerability (described in part here on in= formation security stack exchange).  So as to mitigate this vulnera= bility, I changed settings in Firefox as follows:

  1. I typed about:config in the address bar
  2. I found the setting media.= peerconnection.enabled
  3. I set it to false
    4. <= /ol>

    Unfortunately, this setting does not allow Firefox to work with the video conferencing service in question, which relies entirely on WebRTC.

    So I had to= go back in and change the media.peerconnection.enabled setting to true in Firefox in order to get it to work with the service in question.=20 While this enabled me to conference with teams that desire to use the=20 video conferencing service that rely wholly upon WebRTC, it concerns me=20 because of the security vulnerability.

    One suggested mitigation was ha= ving NoScript, but using NoScript was not helpful (you generally need to dis= able it for the site you are viewing that relies upon WebRTC, in order to ob= tain any functionality, and whether NoScript is off or on, WebRTC still caus= es the vulnerability of leaking information as previously described).

    Furthermore, upon reload of the browser, even after setting media.peerco= nnection.enabled to true, the video conferencing service wouldn't work until I installed the=20 WebRTC 0.1.3 extension for Firefox and set it to expose my real IP=20 address as well as allowing the following:

    a. navigator.getUserMediab. window.MediaStreamTrack
    c. window.RTCPeerConnection
    d. window.RTC= SessionDescription

    That seemed to me to be a direct consequence of= the persistent and ongoing security vulnerability in WebRTC.

    I contacted the video conferencing service provider and their solution=20 was simply to state that "If the peer to peer connection is of concern,=20 you can utilize our=20 premium version which will route traffic through a forwarding server=20 with in our environment that handles the processing of the video and=20 sound of all users in the conference and send it to each user=20 individually rather than using a peer to peer connection."  In other=20= words, they expect that people should have to pay in order to mitigate this WebRTC security vulnerability, because they are unwilling to d= esign to protect all users from it.

    In a similar fashion, in the secon= d example of the browser based WebRTC version of a decentralized exchange, t= he user's financial information is periodically exposed as a result of the i= nformation leakage which is presently caused by WebRTC.  (Fortunately, t= his browser based WebRTC decentralized exchange is under development and is n= ot currently open to actual usage.)

    Although undoubtedly this has been discussed here before, I am asking that WebRTC se= curity issues be reconsidered and that a new security review be done to ameliorate or=20 eliminate this problem in terms of WebRTC leaking this information.  It= is my view that WebRTC should be further designed and developed with an eye= to mitigating this serious problem, so that users of services which might r= ely partially or wholly upon WebRTC would not have to be concerned about suc= h information leakage.

    Respectfully,

    Colin Gallagher


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




____________________= ___________________________
rtcweb mailing list
rtcweb@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/rtcweb">https://www.ietf.org= /mailman/listinfo/rtcweb
= --Apple-Mail-A12E5498-9FE5-41BD-9DA8-A1B8519F0018-- From nobody Fri May 26 17:41:18 2017 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 B1E371292F5 for ; Fri, 26 May 2017 17:41:16 -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, MIME_QP_LONG_LINE=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 Or2gPKr4hUql for ; Fri, 26 May 2017 17:41:12 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::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 B03DC1288B8 for ; Fri, 26 May 2017 17:41:12 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id 8so543191pgc.2 for ; Fri, 26 May 2017 17:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RzIPnB92w8p5Kbsszu0hp7khHuNYtO/mkSD5Kyi6VII=; b=XEfVWr5FLrrlkR4EL9VJQZEEKrriWfrq4lB5EHbEPip5kj/F5rb3FA05F5YfSV+0WD Qr09tmavjafGfePTywqQBcihlag++l8HTRWUi9TBYw9D9j4MGXtSSo3ezfdOWWIbKOwY lxi8mwYnZoTTJrAjeuGQdfTls7ZBCitJpsfEdLVCssz8A9iT6x2nkqWAW0MpRTsBKHZs HxMBqMYxUytwWGjSRCNp6YGqRfFiiANWTPlpZ3YA8gGZPpUXH9QV7HZJC4Tu7TjPslhn Y8D1E9s/wFuSzjrd7PxNOtm2Gg+bScEB+bZrqi2o0sSWimEjFYLvoJvSPDK5W67Z01kQ enow== 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=RzIPnB92w8p5Kbsszu0hp7khHuNYtO/mkSD5Kyi6VII=; b=keVbzzDh7ZkEWHMw5Q9ucpTs+W4x1i5QzBNMM4MUh8HX2/vjJYxn2EQgj5AuEkxbYL y3zuUtLGNY06NM9muzr1xeC9NKSwWlmnZQHWjvNYIL7UjuolfH9iBuuuQBoAjYjZOaks XwRRbJQoxvFfN+9NEJMHv7WwZDBBWWyQ7NSkop77QQpkTI6/+jL8TgsfWHkE48YPY2Vu BvNBwRykGBZo8aJaaSuEojYn1ksLk0ag6G9P7soFfyDminv31jep0kMugQ1pD5C8U2Cl DBme3UtV+Clucqb1efzwYJ0cDQcD/oPbsh4bUZd8RjmmKSwYQasnIDLV2NgPiZ0XrB4/ iAhg== X-Gm-Message-State: AODbwcCGTCM3JjDu2F1PLJbFw+mWBSgftKoVUUOX+gTwdvkxz+U5UQAi L8MUHxGS63ysmbsKS2o= X-Received: by 10.101.73.7 with SMTP id p7mr5715136pgs.144.1495845672078; Fri, 26 May 2017 17:41:12 -0700 (PDT) Received: from [10.235.54.162] (mobile-166-176-186-86.mycingular.net. [166.176.186.86]) by smtp.gmail.com with ESMTPSA id s63sm3457123pgb.40.2017.05.26.17.41.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 May 2017 17:41:11 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-94BC0043-9133-4009-BD1E-EED78C1D5BFA Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Fri, 26 May 2017 17:41:09 -0700 Cc: Justin Uberti , "rtcweb@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <5404A195-3D7C-4A7C-B39F-BE97AD3C9382@gmail.com> References: To: Colin Gallagher Archived-At: Subject: Re: [rtcweb] Request for New Security Review of WebRTC based on observed vulnerabilities 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, 27 May 2017 00:41:17 -0000 --Apple-Mail-94BC0043-9133-4009-BD1E-EED78C1D5BFA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Based on your messages so far I am not clear what you are asking for the IET= F RTCWEB WG to do. You have not filed any issues against the IP Handling doc= ument so it is not clear if you feel it needs to be changed or even what it i= s may sdonf. Nor are you posting your request to the SDO (W3C) that actually= owns the API and reviews its privacy and security implications.=20 > On May 26, 2017, at 11:14 AM, Colin Gallagher wrote: >=20 > It seems the consensus of the group here is essentially a refusal to furth= er review and potentially redesign WebRTC to remove the serious security vul= nerabilities that it presents to its users. >=20 > Thank you for your time. I will not further respond to this thread. >=20 >> On Fri, May 26, 2017 at 10:49 AM, Justin Uberti wrot= e: >> Colin, >>=20 >> As Eric mentioned, the group has reviewed this exact issue, and the afore= mentioned document represents the result of the review. >>=20 >> I am still not quite clear on the exact technical issue you would like to= see addressed and why it is, as you claim, a serious vulnerability. >>=20 >> Comments inline. >>=20 >>> On Fri, May 26, 2017 at 12:58 AM, Colin Gallagher wrote: >>> Justin, >>>=20 >>> It's my understanding that various browsers have made an attempt to conf= orm to the recommendations in the document that you have provided. Unfortun= ately, at least in Firefox (the most current version) so far as I can tell, t= here is a serious vulnerability. To be more specific, the problem was obser= ved in my operating system with my current browser, which is Ubuntu 16.10 64= -bit with Firefox 53.0.2 (64-bit). The browser does not address the WebRTC p= roblems by default. >>>=20 >>> The stackexchange page that I cited originally is actually not outdated i= n the sense that its method of measuring whether or not the WebRTC vulnerabi= lity exists on a given system is still intact and works. The stackexchange p= age suggests two pages to determine whether or not you have leakage / WebRTC= related vulnerability. These pages are: >>>=20 >>> 1) Browser leaks test for WebRTC https://browserleaks.com/webrtc >>> 2) IP Leaks https://ipleak.net/ >>>=20 >>> Currently for Browser leaks test for WebRTC (due to that I have again ch= anged settings in my system so that I will not have to be exposed to this vu= lnerability) the settings show up on the page as: >>> RTCPeerConnection=C3=97False >>> RTCDataChannel=C3=97False >>> ORTC (Microsoft Edge)=C3=97False (for example....) >>>=20 >>> And under IP leaks, it currently shows "No leak, RTCPeerConnection not a= vailable." =20 >>>=20 >>> That is because: >>>=20 >>> (A) I have (again) changed my settings in about:config back to the follo= wing >>>=20 >>> I typed about:config in the address bar >>> I found the setting media.peerconnection.enabled >>> I set it to false (it was previously set at true, so as to allow WebRTC= to work, but this exposed information which I would not have wanted to be e= xposed) >>> (B) And I also have changed my settings back to the following >>>=20 >>> in the WebRTC 0.1.3 extension for Firefox I have set it to no longer exp= ose my real IP address as well as no longer allowing the following: >>>=20 >>> a. navigator.getUserMedia >>> b. window.MediaStreamTrack >>> c. window.RTCPeerConnection >>> d. window.RTCSessionDescription >>>=20 >>> To be clear, these mitigations that I have employed above would be unnec= essary if WebRTC had not been designed in such a manner that it so clearly e= xposes so much user information. >>>=20 >>> In the document you provided, titled "WebRTC IP Address Handling Require= ments - draft-ietf-rtcweb-ip-handling-03," it is stated that: >>>=20 >>> "1. If the client is behind a NAT, the client's private IP addresses, ty= pically [RFC1918] addresses, can be learned. >>>=20 >>> 2. If the client tries to hide its physical location through a VPN, >>> and the VPN and local OS support routing over multiple interfaces= >>> (i.e., a "split-tunnel" VPN), WebRTC will discover the public >>> address for the VPN as well as the ISP public address that the >>> VPN runs over. >>>=20 >>> 3. If the client is behind a proxy (a client-configured "classical >>> application proxy", as defined in [RFC1919], Section 3), but >>> direct access to the Internet is also supported, WebRTC's STUN >>> [RFC5389]checks will bypass the proxy and reveal the public >>> address of the client." >>>=20 >>> All of these are obvious vulnerabilities and serious problems (not only #= 2 as the document suggests). >>=20 >> The document discusses #1 and #3 in detail, and outlines mechanisms that c= an be used to address these cases if needed. >>=20 >> If, despite the findings in the document, you think that these are indeed= serious problems, it would be good to outline exactly why. >>>=20 >>> It is stated in the document that,=20 >>>=20 >>> "we want to avoid solutions that disable WebRTC or make it harder to use= ." >>>=20 >>> Yet, so far as my observations of WebRTC in the current version of Firef= ox with Ubuntu 16.10 have shown, >>> there appears to be no other choice other than to disable WebRTC because= its use completely compromises=20 >>> privacy and thus makes all other aspects of your system more difficult g= enerally. >>>=20 >>> It is stated in the document you cited that the goals here are to "Provi= de a privacy-friendly default behavior which strikes the >>> right balance between privacy and media performance for most users= >>> and use cases. (and) For users who care more about one versus the o= ther, provide a >>> means to customize the experience." >>> This has clearlly not been accomplished in the context of Ubuntu 16.10 6= 4-bit with Firefox 53.0.2 (64-bit). >>>=20 >>> Hence my request for a new security review of WebRTC based on observed v= ulnerabilities. >>=20 >> To my knowledge, the document addresses these goals. If you believe Firef= ox is not conforming, please file a bug; if you think the document is in err= or, please point out where and why. >>>=20 >>>=20 >>>=20 >>>> On Thu, May 25, 2017 at 1:04 PM, Justin Uberti wro= te: >>>> Colin, >>>>=20 >>>> This is an important topic, and the group has reviewed this situation i= n detail. The results have been written up in this document, and to my knowl= edge most browsers that support WebRTC currently conform to its recommendati= ons. >>>>=20 >>>> However, I'm not totally clear on your specific technical concern. You l= inked to an (now outdated) stackexchange page, but could you provide more de= tail about the specific situation you are concerned about? >>>>=20 >>>> Justin >>>>=20 >>>>> On Wed, May 24, 2017 at 5:35 PM, Colin Gallagher wrote: >>>>> To: IETF RTCWeb WG >>>>>=20 >>>>> From: Colin Gallagher >>>>> https://www.linkedin.com/in/colingallagher >>>>> https://lifeboat.com/ex/bios.colin.gallagher >>>>>=20 >>>>> Request for New Security Review of WebRTC based on observed vulnerabil= ities in certain examples >>>>>=20 >>>>> Dear IETF RTCWeb WG, >>>>>=20 >>>>> This request relates to WebRTC. The WebRTC is in draft at https://w3c= .github.io/webrtc-pc/ and is described also at https://developer.mozilla.org= /en-US/docs/Web/API/WebRTC_API#WebRTC_interfaces >>>>>=20 >>>>> There are certain examples where the use of WebRTC has presented secur= ity vulnerabilities. While not exhaustive, there are two I wanted to mentio= n that I had been exposed to recently. >>>>>=20 >>>>> 1) The use of a video conferencing service which relies upon WebRTC (t= hat is a well established service) >>>>> 2) The examination of a browser based WebRTC version of a decentralize= d exchange (that is currently under development) >>>>>=20 >>>>> In both cases the security vulnerability which is described below was t= he result of the use of WebRTC. >>>>>=20 >>>>> The problem under consideration is as follows: >>>>>=20 >>>>> As per the first example (the video conferencing service), recently I c= ame upon a vendor who shall remain unnamed who uses WebRTC as the backbone f= or their video conferencing service. As a result, I found I was unable to a= ccess the service in question without disabling some security settings which= I would have preferred to leave intact.=20 >>>>>=20 >>>>> My system is (based on what the aforementioned service detects) Mozill= a/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0. Thi= s is Ubuntu 16.10 64-bit with Firefox 53.0.2. >>>>>=20 >>>>> However, quite some long while back I disabled WebRTC because of the s= ecurity vulnerability (described in part here on information security stack e= xchange). So as to mitigate this vulnerability, I changed settings in Firef= ox as follows: >>>>>=20 >>>>> I typed about:config in the address bar >>>>> I found the setting media.peerconnection.enabled >>>>> I set it to false >>>>> Unfortunately, this setting does not allow Firefox to work with the vi= deo conferencing service in question, which relies entirely on WebRTC. >>>>>=20 >>>>> So I had to go back in and change the media.peerconnection.enabled set= ting to true in Firefox in order to get it to work with the service in ques= tion. While this enabled me to conference with teams that desire to use the v= ideo conferencing service that rely wholly upon WebRTC, it concerns me becau= se of the security vulnerability. >>>>>=20 >>>>> One suggested mitigation was having NoScript, but using NoScript was n= ot helpful (you generally need to disable it for the site you are viewing th= at relies upon WebRTC, in order to obtain any functionality, and whether NoS= cript is off or on, WebRTC still causes the vulnerability of leaking informa= tion as previously described). >>>>>=20 >>>>> Furthermore, upon reload of the browser, even after setting media.peer= connection.enabled to true, the video conferencing service wouldn't work unt= il I installed the WebRTC 0.1.3 extension for Firefox and set it to expose m= y real IP address as well as allowing the following: >>>>>=20 >>>>> a. navigator.getUserMedia >>>>> b. window.MediaStreamTrack >>>>> c. window.RTCPeerConnection >>>>> d. window.RTCSessionDescription >>>>>=20 >>>>> That seemed to me to be a direct consequence of the persistent and ong= oing security vulnerability in WebRTC. >>>>>=20 >>>>> I contacted the video conferencing service provider and their solution= was simply to state that "If the peer to peer connection is of concern, you= can utilize our premium version which will route traffic through a forwardi= ng server with in our environment that handles the processing of the video a= nd sound of all users in the conference and send it to each user individuall= y rather than using a peer to peer connection." In other words, they expect= that people should have to pay in order to mitigate this WebRTC security vu= lnerability, because they are unwilling to design to protect all users from i= t. >>>>>=20 >>>>> In a similar fashion, in the second example of the browser based WebRT= C version of a decentralized exchange, the user's financial information is p= eriodically exposed as a result of the information leakage which is presentl= y caused by WebRTC. (Fortunately, this browser based WebRTC decentralized e= xchange is under development and is not currently open to actual usage.) >>>>>=20 >>>>> Although undoubtedly this has been discussed here before, I am asking t= hat WebRTC security issues be reconsidered and that a new security review be= done to ameliorate or eliminate this problem in terms of WebRTC leaking thi= s information. It is my view that WebRTC should be further designed and dev= eloped with an eye to mitigating this serious problem, so that users of serv= ices which might rely partially or wholly upon WebRTC would not have to be c= oncerned about such information leakage. >>>>>=20 >>>>> Respectfully, >>>>>=20 >>>>> Colin Gallagher >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-94BC0043-9133-4009-BD1E-EED78C1D5BFA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Based on your messages so f= ar I am not clear what you are asking for the IETF RTCWEB WG to do. You have= not filed any issues against the IP Handling document so it is not clear if= you feel it needs to be changed or even what it is may sdonf. Nor are you p= osting your request to the SDO (W3C) that actually owns the API and reviews i= ts privacy and security implications. 

On May 26, 2017, a= t 11:14 AM, Colin Gallagher <colingallagher.rpcv@gmail.com> wrote:

It seems the consensus of the group h= ere is essentially a refusal to further review and potentially redesign WebR= TC to remove the serious security vulnerabilities that it presents to its us= ers.

Thank you for your time.  I will not further respond t= o this thread.

On Fri, May 26, 2017 at 10:49 AM, Justin Uberti <juberti@go= ogle.com> wrote:
Colin,

As Eric mentioned, the group has reviewed thi= s exact issue, and the aforementioned document represents the result of the r= eview.

I am still not quite clear on the exact tech= nical issue you would like to see addressed and why it is, as you claim, a s= erious vulnerability.

Comments inline.

On= Fri, May 26, 2017 at 12:58 AM, Colin Gallagher <colingallagher.= rpcv@gmail.com> wrote:
<= div dir=3D"ltr">
Justin,

It's my understanding that various browsers have made an attempt to conform= to the recommendations in the document that you have provide= d.  Unfortunately, at least in Firefox (the most current version) s= o far as I can tell, there is a serious vulnerability.  To be more spec= ific, the problem was observed in my operating system with my current browse= r, which is Ubuntu 16.10 64-bit with Firefox=20 53.0.2 (64-bit).  The browser does not address the WebRTC problems by d= efault.

The stackexchange page that I cited originally is actua= lly not outdated in the sense that its method of measuring whether or not th= e WebRTC vulnerability exists on a given system is still intact and works.&n= bsp; The stackexchange page suggests two pages to determine whether or not y= ou have leakage / WebRTC related vulnerability.  These pages are:
1) Browser leaks test for WebRTC https://browserleaks.com/webrtc
2) IP Leaks https://iplea= k.net/

Currently for Browser leaks test for WebRTC (due to t= hat I have again changed settings in my system so that I will not have to be= exposed to this vulnerability) the settings show up on the page as:
RTCP= eerConnection=C3=97False
RTCDataChannel=C3=97False
ORTC (Microsoft Edge)= =C3=97False (for example....)

And under IP leaks, it currently s= hows "No leak, RTCPeerConnection not available." 

That= is because:

(A) I have (again) changed my settings in abou= t:config back to the following

  1. I typed about:config= in the address bar
  2. I found the setting media.peerconnectio= n.enabled
  3. I set it to false  (it was previo= usly set at true, so as to allow WebRTC to work, but this exposed informatio= n which I would not have wanted to be exposed)

(B) And I= also have changed my settings back to the following

in the WebRTC 0.1= .3 extension for Firefox I have set it to no longer expose my real IP=20 address as well as no longer allowing the following:

a. navigato= r.getUserMedia
b. window.MediaStreamTrack
c. window.RTCPeerConnection<= br>d. window.RTCSessionDescription

To be clear, these mitiga= tions that I have employed above would be unnecessary if WebRTC had not been= designed in such a manner that it so clearly exposes so much user informati= on.

In the document you provided, titled "WebRT= C IP Address Handling Requirements - draft-ietf-rtcweb-ip-handling-03,"= it is stated that:

"1. If the client is behind a NAT, the client's private IP addresse= s, typically [RFC1918] addresses, can be learned. 

 2.  If t=
he client tries to hide its physical location through a VPN,
       and the VPN and local OS support routing over multiple interfaces
       (i.e., a "split-tunnel" VPN), WebRTC will discover the public
       address for the VPN as well as the ISP public address that the
       VPN runs over.

   3.  If the client is behind a proxy (a client-configured "classical
       application proxy", as defined in [RFC1919], Section 3), but=

       direct access to the Internet is also supported, WebRTC's STUN
       [RFC5389]c=
hecks will bypass the proxy and reveal the public
       address of the client."

All of these are obvious vulnerabilities and se=
rious problems (not only #2 as the document suggests).

The document discusses #1 and #= 3 in detail, and outlines mechanisms that can be used to address these cases= if needed.

If, despite the findings in the documen= t, you think that these are indeed serious problems, it would be good to out= line exactly why.

It is stated in the docu=
ment that, 

"we want to avoid solutions that disable WebRTC or mak=
e it harder to use."

Yet, so far as my observations of WebRTC in the current v=
ersion of Firefox with Ubuntu 16.10 have shown,
there appears to be no other choice oth=
er than to disable WebRTC because its use completely compromises 
=

privacy and thus mak=
es all other aspects of your system more difficult generally.

It is stated in the document you cited that the g=
oals here are to "Provide a privacy-friendly default behavior which s=
trikes the
      right balance between privacy and media performance for most users
      and use cases. (and) For users who care more about one versus the othe=
r, provide a
      means to customize the experience."
This has clearlly not been accomplished in the context o=
f Ubuntu 16.10 64-bit with Firefox 53.0.2 (64-bit).

Hence my request for a new sec= urity review of WebRTC based on observed vulnerabilities.

To my knowledge, the document ad= dresses these goals. If you believe Firefox is not conforming, please file a= bug; if you think the document is in error, please point out where and why.=
=




On Thu, May 25, 2017 a= t 1:04 PM, Justin Uberti <juberti@google.com> wrote:
Colin,

This is a= n important topic, and the group has reviewed this situation in detail. The r= esults have been written up in this document, and to my k= nowledge most browsers that support WebRTC currently conform to its recommen= dations.

However, I'm not totally clear on your spe= cific technical concern. You linked to an (now outdated) stackexchange page,= but could you provide more detail about the specific situation you are conc= erned about?

Justin

On Wed, May 24, 2017 at 5:35 PM, Colin Gallagher <= span dir=3D"ltr"><colingallagher.rpcv@gmail.com> wrote:

There ar= e certain examples where the use of WebRTC has presented security vulnerabil= ities.  While not exhaustive, there are two I wanted to mention that I h= ad been exposed to recently.

1) The use of a video c= onferencing service which relies upon WebRTC (that is a well established ser= vice)
2) The examination of a browser based WebRTC version of a dec= entralized exchange (that is currently under development)

In bo= th cases the security vulnerability which is described below was the result o= f the use of WebRTC.

The problem under consideration is as follows:
As per the first example (the video conferencing service), recently I came upon a vendor who shall remain unnamed who uses WebRTC as the=20 backbone for their video conferencing service.  As a result, I found I=20= was unable to access the service in question without disabling some=20 security settings which I would have preferred to leave intact.

My s= ystem is (based on what the aforementioned service detects) Mozilla/5.0 (X11= ; Ubuntu; Linux x86_64; rv:53.0)=20 Gecko/20100101 Firefox/53.0.  This is Ubuntu 16.10 64-bit with Firefox=20= 53.0.2.

However, quite some long while back I disabled WebRTC b= ecause of the security vulnerability (described in part here on in= formation security stack exchange).  So as to mitigate this vulnera= bility, I changed settings in Firefox as follows:

  1. I typed about:config in the address bar
  2. I found the setting media.= peerconnection.enabled
  3. I set it to false
    4. <= /ol>

    Unfortunately, this setting does not allow Firefox to work with the video conferencing service in question, which relies entirely on WebRTC.

    So I had to= go back in and change the media.peerconnection.enabled setting to true in Firefox in order to get it to work with the service in question.=20 While this enabled me to conference with teams that desire to use the=20 video conferencing service that rely wholly upon WebRTC, it concerns me=20 because of the security vulnerability.

    One suggested mitigation was ha= ving NoScript, but using NoScript was not helpful (you generally need to dis= able it for the site you are viewing that relies upon WebRTC, in order to ob= tain any functionality, and whether NoScript is off or on, WebRTC still caus= es the vulnerability of leaking information as previously described).

    Furthermore, upon reload of the browser, even after setting media.peerco= nnection.enabled to true, the video conferencing service wouldn't work until I installed the=20 WebRTC 0.1.3 extension for Firefox and set it to expose my real IP=20 address as well as allowing the following:

    a. navigator.getUserMediab. window.MediaStreamTrack
    c. window.RTCPeerConnection
    d. window.RTC= SessionDescription

    That seemed to me to be a direct consequence of= the persistent and ongoing security vulnerability in WebRTC.

    I contacted the video conferencing service provider and their solution=20 was simply to state that "If the peer to peer connection is of concern,=20 you can utilize our=20 premium version which will route traffic through a forwarding server=20 with in our environment that handles the processing of the video and=20 sound of all users in the conference and send it to each user=20 individually rather than using a peer to peer connection."  In other=20= words, they expect that people should have to pay in order to mitigate this WebRTC security vulnerability, because they are unwilling to d= esign to protect all users from it.

    In a similar fashion, in the secon= d example of the browser based WebRTC version of a decentralized exchange, t= he user's financial information is periodically exposed as a result of the i= nformation leakage which is presently caused by WebRTC.  (Fortunately, t= his browser based WebRTC decentralized exchange is under development and is n= ot currently open to actual usage.)

    Although undoubtedly this has been discussed here before, I am asking that WebRTC se= curity issues be reconsidered and that a new security review be done to ameliorate or=20 eliminate this problem in terms of WebRTC leaking this information.  It= is my view that WebRTC should be further designed and developed with an eye= to mitigating this serious problem, so that users of services which might r= ely partially or wholly upon WebRTC would not have to be concerned about suc= h information leakage.

    Respectfully,

    Colin Gallagher


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





____________________= ___________________________
rtcweb mailing list
rtcweb@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/rtcweb">https://www.ietf.org= /mailman/listinfo/rtcweb
= --Apple-Mail-94BC0043-9133-4009-BD1E-EED78C1D5BFA--