Re: [rtcweb] tweaks for ip-handling language

Martin Thomson <martin.thomson@gmail.com> Wed, 16 November 2016 23:26 UTC

Return-Path: <martin.thomson@gmail.com>
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 93A721294E3 for <rtcweb@ietfa.amsl.com>; Wed, 16 Nov 2016 15:26:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGCeqWduN2mo for <rtcweb@ietfa.amsl.com>; Wed, 16 Nov 2016 15:26:16 -0800 (PST)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2D901293DB for <rtcweb@ietf.org>; Wed, 16 Nov 2016 15:26:15 -0800 (PST)
Received: by mail-qk0-x233.google.com with SMTP id x190so196665348qkb.0 for <rtcweb@ietf.org>; Wed, 16 Nov 2016 15:26:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=RD/BaeKpnmjj/xhiYN0u2z9HyKQmWM8AmOR47n/uWFc=; b=DMHKjbmz7Z4suMh4wPFY0a1/7fei+c6vRDWhFgZHBg6Q55r5b9flMZ5gEY1qUQPNa9 Hn1/vzpxH7fd/UyuywrzifyWTpH00QfFNOM3daUTir9eP+ZI5v9fVelmGTiy6a1jl0oL 0GizXb7OcD5r7ycjbZstxK6eryysDqJ8hxvrkQWHVvPBKzbANGgJt5+m9e8vNNfrrYcs UuCQt/CaU5XYQ7pwuC+ZhOZBs9p6UtqF11jumvtbaqgfRkv0J+q8ff2n2NWKpO71zQ+E 4LoGjDnXVWHtT1mKS9ZtBWwvCaVWTZbSAv+KmRpkESVLTWgnu2zI4QPYHfbMYXaxEDFI yorg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=RD/BaeKpnmjj/xhiYN0u2z9HyKQmWM8AmOR47n/uWFc=; b=G7xe5YalsjlmjRXa0Il9ljcr54zQv+S3ufmyXOCFM2PAbFK08XEzH5cCIWqnsnMSVO Jl/bOYbegaLxjUgGOqYJAXZW7dORV52PzmyQB62anVoyKeGNn6RcPfbUyoXOVQhCYjeA V5ERi8gs46UpKCu5z4erRswymJxCmF5q02uAspMHRa6t4mBqzyyRzr1tmAqOrO9acUji lXrtwJc0C+WeuMRuHNpZ1MkLCgzPHrgx/Oo68pI385nbasDTTqlVmSFzvpDSTMubv4jE E6caSHM9FQ3bhdm6DcsB7CqLuKRs1gydtJtBlReJOEjKbxHoH94QXb6uC6tTZIaQN4lq 8PYA==
X-Gm-Message-State: AKaTC01KUgt4JvPbtNBht4qh7xU5+JdAl28E8FTanPL0dhwH6XC4YBn/3JEXNkIQMqcDdbDviRErYrKtCkPBbQ==
X-Received: by 10.55.99.141 with SMTP id x135mr129418qkb.147.1479338774976; Wed, 16 Nov 2016 15:26:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Wed, 16 Nov 2016 15:26:14 -0800 (PST)
In-Reply-To: <C770F9D2-549D-4B33-94CD-6954B433F1B7@cooperw.in>
References: <C770F9D2-549D-4B33-94CD-6954B433F1B7@cooperw.in>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 17 Nov 2016 08:26:14 +0900
Message-ID: <CABkgnnUq8diBzbJF+eLtQN1s1bhhHGM3vaAMdJY=QXtQrOT9qg@mail.gmail.com>
To: Alissa Cooper <alissa@cooperw.in>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/mluOgeqMLLJeh-Ovj1ssS4R03rU>
Cc: RTCWeb IETF <rtcweb@ietf.org>
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: Wed, 16 Nov 2016 23:26:17 -0000

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> 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
> https://www.ietf.org/mailman/listinfo/rtcweb