Re: [rtcweb] Consent alternative

Martin Thomson <> Fri, 22 November 2013 18:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1F4381AE1C7 for <>; Fri, 22 Nov 2013 10:41:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3eD54IF36VAN for <>; Fri, 22 Nov 2013 10:41:15 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c00::229]) by (Postfix) with ESMTP id 31E791AE1C5 for <>; Fri, 22 Nov 2013 10:41:15 -0800 (PST)
Received: by with SMTP id b13so1675264wgh.4 for <>; Fri, 22 Nov 2013 10:41:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=SoC3+/KJaPvlYkWP0aETFXCnBczaKEh1lloKDDnvtGo=; b=PWQSNJQrTWgGVxF1mYdsbJM/U27vc8OLppoB7FH28Ts8vAqbXrCaVcb+JyaMVKI7E2 Ep+tBf84DzPMK2u1QrbhmPLwizulpxhKOrJXzLzqFR5PPmctI79+b5yGKZHE4IkaqvI3 uf1Xkmv6Jqa6Rf0vQ4BIfx2oEjY8PK3qELAcoezUFJoYtV7t5vCvudVNfBqnEE0mLXcU O+oSfc/B5ukaxS2YXnO2QNSQZ5Z/PTJVyx5m2BNrkXbsKFtZ5yh4CbII+AztpH4SKncy ypZEQUG9/XswyPhAPBjRsQaRpYa4B9ltbGil9fDUff7nDyBbwEoIH9X3/78fmSoIpxVf VpOw==
MIME-Version: 1.0
X-Received: by with SMTP id ia10mr11852648wjb.3.1385145667519; Fri, 22 Nov 2013 10:41:07 -0800 (PST)
Received: by with HTTP; Fri, 22 Nov 2013 10:41:07 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Fri, 22 Nov 2013 10:41:07 -0800
Message-ID: <>
From: Martin Thomson <>
To: tim panton <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Cullen Jennings <>, "" <>
Subject: Re: [rtcweb] Consent alternative
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Nov 2013 18:41:17 -0000

Actually, this removes some of the complication.  At worst, it just moves it.

This concentrates all of the logic at the DTLS layer.  If you choose
to treat it so, ICE no longer needs to play any role in determining

DTLS already has a consent mechanism in place (that's the function of
the cookie in the handshake, a feature we don't tend to use when
running ICE).   This expands that to include an ongoing process.  The
only complications come from the interaction between DTLS and SRTP, a
relationship that is already complicated somewhat on the keying layer.

I don't know whether anyone implementing DTLS-SRTP also implements
DTLS renegotiation and EKT at the same time, but those are the areas
where things get tricky.  Otherwise, you have a DTLS (or DTLS-SRTP)
layer that manages consent.

On 22 November 2013 10:08, tim panton <> wrote:
> On 22 Nov 2013, at 09:55, Martin Thomson <> 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:
>> 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