Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00

Martin Thomson <martin.thomson@gmail.com> Wed, 20 November 2013 18:27 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 CD54F1AE471 for <rtcweb@ietfa.amsl.com>; Wed, 20 Nov 2013 10:27:13 -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 BcFUt8TGhams for <rtcweb@ietfa.amsl.com>; Wed, 20 Nov 2013 10:27:12 -0800 (PST)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC141AE434 for <rtcweb@ietf.org>; Wed, 20 Nov 2013 10:27:12 -0800 (PST)
Received: by mail-wg0-f51.google.com with SMTP id l18so1199652wgh.18 for <rtcweb@ietf.org>; Wed, 20 Nov 2013 10:27:05 -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=I73OqZ4SoC49XeP+MTFAGPDoouN5Jkwq2kj1LXCcW6A=; b=giFYvocg5owuBMWC5nubN/26F5+w1dKSeGeJM9DWD4R6U8p91KNH3PcnClT4J/nZxX 1ygXT44dHG4/KXk2up87f+COQnnohx9hpdDO/PmebktlRo1c9PE5pYLG1TZU6mdQKlTb lw7IiXomAm1ZjgjsC89JBBvR32GYftG/C3EoWb/sWzSjhGExiNTc/GQAd4zLvXm33DNA oanG1yt8LPwxngWkWn9DduZayUDrUkqulZ++G2pEyBJelGNnDlDcBD0eFvCga4NsGYow HBbnwclWzMKj8CyuArIsveK0PcAEXuj31Y3mDGcBN6ndZLBZ5z0EcnvswnDjNJtqx6LR J0Kw==
MIME-Version: 1.0
X-Received: by 10.194.61.84 with SMTP id n20mr1840023wjr.61.1384972025375; Wed, 20 Nov 2013 10:27:05 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Wed, 20 Nov 2013 10:27:05 -0800 (PST)
In-Reply-To: <BLU169-W10885AF717BCBB60830502093E60@phx.gbl>
References: <CEAB0083.6FBE3%rmohanr@cisco.com> <5285E318.3090006@ericsson.com> <BLU169-W10885AF717BCBB60830502093E60@phx.gbl>
Date: Wed, 20 Nov 2013 10:27:05 -0800
Message-ID: <CABkgnnVpikDFwzfc=6CnHDOb6rmoe5-54AdYPyrbRvU34Epfig@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>
Content-Type: text/plain; charset="UTF-8"
Cc: "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org" <draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00
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: Wed, 20 Nov 2013 18:27:14 -0000

On 20 November 2013 10:07, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
> I have a meta-question about consent freshness, which is whether it is still
> necessary if  DTLS/SRTP is both mandatory both to implement as well as to
> use (e.g. we could use DTLS heartbeat extension RFC 6520 instead).

Funny you should mention that.  You are by no means the first person
to ask this question.

In fact, I went so far as to write up a draft during the WebRTC
meeting last week.  Dan and I have been going back and forth on a
number of aspects, but I think that it's at least in good enough shape
to put up for wider discussion.

  http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00

Overall, I think that this is cleaner.  The main advantage is that any
authenticated data counts toward refreshing consent.  That means zero
overhead in many common cases.