IETF Logo Mail Archive

Re: [rtcweb] Consent alternative

Martin Thomson <martin.thomson@gmail.com> Mon, 25 November 2013 17:21 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545061ADF64 for <rtcweb@ietfa.amsl.com>; Mon, 25 Nov 2013 09:21:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 3TGNx3qAN_Lt for <rtcweb@ietfa.amsl.com>; Mon, 25 Nov 2013 09:21:15 -0800 (PST)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1FA1ADF4F for <rtcweb@ietf.org>; Mon, 25 Nov 2013 09:21:06 -0800 (PST)
Received: by mail-wg0-f50.google.com with SMTP id a1so2314342wgh.5 for <rtcweb@ietf.org>; Mon, 25 Nov 2013 09:21:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6taQvWF0H37wkg7cqKrWJvSG38Sg6QNNdcbyTstdKL0=; b=fwjZ+iloNhn/218TPY+J9UtKykdt1kfUsl0uB5XQk2vU+6JRkHsOmCsw7paUrDr+pN YhWGIpW9klSToIekUgSkE3Oe36iknYuf5DnDX/MfO4IguwkRBw+RHhg5Mt2WzmEtJSGi sImh5+ODDpLJQN3je7yE2KtEANOun8LcC28wa2yOTjqO0he+Yziy42xPV/kqthb1UBfi KUDBEP6g4gHcAmihfci+vu0T4H6obZtoWoRtYV/ot1jHQy5BSfmx6b30I8mSlx/TE2ST bNkZpqyXmu4cEaUovQ9d5ymTSWH2VDkA0MsMCXuZTxFR65M33L0lBT/ZmndxswW5E++v FJ6A==
MIME-Version: 1.0
X-Received: by 10.180.105.232 with SMTP id gp8mr10417522wib.22.1385400066030; Mon, 25 Nov 2013 09:21:06 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Mon, 25 Nov 2013 09:21:05 -0800 (PST)
In-Reply-To: <20131125154352.054e60cd@lminiero>
References: <CABkgnnVNnT8uoWM8T=TqbTmy11CGTeHLP=_7z5KSMSpAsp9SyQ@mail.gmail.com> <9E5D7D59-0536-469E-8CB7-440FF27F0B41@phonefromhere.com> <CABkgnnX1jNndkjSS+FFzRd42qp4sdzVDT8f-nCGNnxgvicF+dA@mail.gmail.com> <20131125154352.054e60cd@lminiero>
Date: Mon, 25 Nov 2013 09:21:05 -0800
Message-ID: <CABkgnnWB6Wmp3jMYVCbsw=s9EdaCxkXa7kGSEaN09KwZLJcAcg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Lorenzo Miniero <lorenzo@meetecho.com>
Content-Type: text/plain; charset="UTF-8"
Cc: Cullen Jennings <fluffy@cisco.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Consent alternative
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 25 Nov 2013 17:21:17 -0000

On 25 November 2013 06:43, Lorenzo Miniero <lorenzo@meetecho.com> wrote:
> The only doubt I have is sec.3: is
> specifying an ALPN really necessary, if "any DTLS message is
> sufficient to refresh consent"? are you envisaging a scenario where it's
> the DTLS stack that filters unwanted incoming packets (e.g., SCTP where
> you only want RTP), or would it be there for a different reason?

The reason that this section is there is to place some constraints
around to consent to limit its scope.  As more and more protocols
enable (D)TLS, there is an increasing chance that the endpoint you are
talking to speaks (D)TLS, but isn't actually willing to converse with
the protocol you expect.  Rather than provide carte blanche consent,
this allows a data channels-only server to indicate that it's not
interested in SRTP, or your database server from being put on the
other end of a data channel firehose.

v2.23.0 | Report a Bug | By Email