Re: [rtcweb] Consent alternative

tim panton <tim@phonefromhere.com> Fri, 22 November 2013 18:08 UTC

Return-Path: <tim@phonefromhere.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 7986F1ADBE5 for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 10:08:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ribJ2xWtlNjG for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 10:08:30 -0800 (PST)
Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) by ietfa.amsl.com (Postfix) with ESMTP id 375F51AD959 for <rtcweb@ietf.org>; Fri, 22 Nov 2013 10:08:30 -0800 (PST)
Received: (qmail 98868 invoked from network); 22 Nov 2013 18:08:22 -0000
X-AV-Scan: clean
X-APM-Authkey: 83769 11158
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 22 Nov 2013 18:08:22 -0000
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id D7E9118A027C; Fri, 22 Nov 2013 18:08:21 +0000 (GMT)
Received: from [10.10.5.18] (205.158.164.101.ptr.us.xo.net [205.158.164.101]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id E602118A0A89; Fri, 22 Nov 2013 18:08:19 +0000 (GMT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: tim panton <tim@phonefromhere.com>
In-Reply-To: <CABkgnnVNnT8uoWM8T=TqbTmy11CGTeHLP=_7z5KSMSpAsp9SyQ@mail.gmail.com>
Date: Fri, 22 Nov 2013 10:08:21 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <9E5D7D59-0536-469E-8CB7-440FF27F0B41@phonefromhere.com>
References: <CABkgnnVNnT8uoWM8T=TqbTmy11CGTeHLP=_7z5KSMSpAsp9SyQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.1822)
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: Fri, 22 Nov 2013 18:08:32 -0000

On 22 Nov 2013, at 09:55, Martin Thomson <martin.thomson@gmail.com> wrote:

> I know that I've been a fan of consent via ICE, but with the decision
> in Berlin to move to DTLS only, several of us have observed that
> perhaps RFC 6520 might be a better alternative.
> 
> We've put together an exploration of the idea here:
> 
> http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00
> 
> The best part of this is that it changes the dynamics (for the better,
> I think).  You don't need to send extra packets if you are actively
> using the flow.  That means that 1:1 sessions won't need to spend
> extra cycles or bytes on keeping the session live.
> 
> There are some gotchas for multiparty sessions, but I believe those to
> be manageable.

I have misgivings about this - It feels to me to force a mixing of layers in the 
packet handling - At the moment in the implementation I’m familiar with, the ICE/DTLS/SRTP 
state machines are almost completely isolated. This proposal seems (at first glance)
to make them intertwine in a quite complex way - consent is generated (if I understand it correctly)
by any of the layers. Likewise each of the layers needs to know if the others have generated consent 
granting packets. 

If we are to blur the boundaries like this, we should go the whole hog and get some real benefits - like
for example remove some round-trips in session establishment by (say) carrying the DTLS hello in the
same STUN packet as has ICE USE-CANDIDATE set - for example.

I’m against including this sort of change at this stage in the standards process.

T.


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