Re: [rtcweb] tweaks for ip-handling language

Harald Alvestrand <harald@alvestrand.no> Thu, 17 November 2016 03:55 UTC

Return-Path: <harald@alvestrand.no>
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 388F0129484 for <rtcweb@ietfa.amsl.com>; Wed, 16 Nov 2016 19:55:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.696
X-Spam-Level:
X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] 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 QHT6zSbrmMUQ for <rtcweb@ietfa.amsl.com>; Wed, 16 Nov 2016 19:55:05 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C178012949E for <rtcweb@ietf.org>; Wed, 16 Nov 2016 19:55:04 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id E1A737C3C3E for <rtcweb@ietf.org>; Thu, 17 Nov 2016 04:55:02 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jb9cAek0xSQ for <rtcweb@ietf.org>; Thu, 17 Nov 2016 04:54:58 +0100 (CET)
Received: from [IPv6:2001:67c:370:128:f80a:302c:408f:ee3] (t2001067c03700128f80a302c408f0ee3.v6.meeting.ietf.org [IPv6:2001:67c:370:128:f80a:302c:408f:ee3]) by mork.alvestrand.no (Postfix) with ESMTPSA id D3F7E7C3C3A for <rtcweb@ietf.org>; Thu, 17 Nov 2016 04:54:57 +0100 (CET)
To: rtcweb@ietf.org
References: <C770F9D2-549D-4B33-94CD-6954B433F1B7@cooperw.in> <CABkgnnUq8diBzbJF+eLtQN1s1bhhHGM3vaAMdJY=QXtQrOT9qg@mail.gmail.com> <CABcZeBOpsmK73xmVVSVu1d7z6Mypkitpm4nVK2LgBnp5TXy11w@mail.gmail.com>
From: Harald Alvestrand <harald@alvestrand.no>
Message-ID: <db285641-6fdd-3225-ada5-d2926f62079d@alvestrand.no>
Date: Thu, 17 Nov 2016 04:54:52 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <CABcZeBOpsmK73xmVVSVu1d7z6Mypkitpm4nVK2LgBnp5TXy11w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------2E254D80E1534836434AF20E"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/O8Hay5btkVr7TnWfI2lKrx5tHYM>
Subject: Re: [rtcweb] tweaks for ip-handling language
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Nov 2016 03:55:08 -0000

On 11/17/2016 12:57 AM, Eric Rescorla wrote:
> I generally agree with Martin's comments, with the following exception.
>
> I would remove everything after "off getUserMedia consent." It has no
> normative effect
> and is simply rationale.

If we have rough consensus that the rationale is not unreasonable, I
like leaving rationale in.


>
> -Ekr
>
>
> On Thu, Nov 17, 2016 at 8:26 AM, Martin Thomson
> <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>> wrote:
>
>     This looks like a good change on its own.  However, reading the
>     document, I find that the "all possible candidates" issue is hard to
>     fix.  This text is part of the rationale for the different modes.
>     Placing a requirement here - before we've established the baseline -
>     is probably the wrong thing to do.
>
>     I think that restructuring the corresponding section might be the best
>     plan.  The text in question isn't rationale; it doesn't really belong
>     where it is.
>
>     Thus, I would recommend this structure:
>     1. define the 4 modes
>     2. recommend that mode 2 is the default.
>     3. include this text - tweaked slightly - to explain how user consent
>     is necessary to use mode 1
>     4. explain that modes 3 and 4 might be made the default in certain
>     contexts
>     5. include the other rationale to justify the design
>
>
>     On 16 November 2016 at 16:25, Alissa Cooper <alissa@cooperw.in
>     <mailto:alissa@cooperw.in>> wrote:
>     > This still needs the fix for “all possible candidates.”
>     >
>     > OLD
>     > Gathering all possible candidates SHOULD only be performed when
>     some form of user consent has been provided; this thwarts the
>     typical drive-by enumeration attacks.  The details of this consent
>     are left to the implementation; one potential mechanism is to key
>     this off getUserMedia consent.  The getUserMedia suggestion takes
>     into account that the user has provided some consent to the
>     application already; that when doing so the user typically wants
>     to engage in a conversational session, which benefits most from an
>     optimal network path, and lastly, the fact that the underlying
>     issue is complex and difficult to explain, making explicit consent
>     for enumeration troublesome.
>     >
>     > NEW
>     > Gathering all possible candidates MUST only be performed when
>     some form of user consent has been provided; this thwarts the
>     typical drive-by enumeration attacks.  The details of this consent
>     are left to the implementation. One potential mechanism is to tie
>     this consent to getUserMedia consent. Such a mechanism might be
>     chosen based on the fact that the user has provided some consent
>     to the application already; that when doing so the user typically
>     wants to engage in a conversational session, which benefits most
>     from an optimal network path, and lastly, the fact that the
>     underlying issue is complex and difficult to explain, making
>     explicit consent for enumeration troublesome.
>     > _______________________________________________
>     > rtcweb mailing list
>     > rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>     > https://www.ietf.org/mailman/listinfo/rtcweb
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>     _______________________________________________
>     rtcweb mailing list
>     rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


-- 
Surveillance is pervasive. Go Dark.