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.
- [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative tim panton
- Re: [rtcweb] Consent alternative Bernard Aboba
- Re: [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative tim panton
- Re: [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative Lorenzo Miniero
- Re: [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative Magnus Westerlund
- Re: [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative Dan Wing
- Re: [rtcweb] Consent alternative Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative Dan Wing
- Re: [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] Consent alternative Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] Consent alternative Harald Alvestrand
- Re: [rtcweb] Consent alternative Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] Consent alternative Martin Thomson
- Re: [rtcweb] Consent alternative Tirumaleswar Reddy (tireddy)