Re: [rtcweb] Consent alternative

Dan Wing <dwing@cisco.com> Wed, 04 December 2013 19:12 UTC

Return-Path: <dwing@cisco.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 4862D1ADFC2 for <rtcweb@ietfa.amsl.com>; Wed, 4 Dec 2013 11:12:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 PCzgrz7kuH2S for <rtcweb@ietfa.amsl.com>; Wed, 4 Dec 2013 11:12:00 -0800 (PST)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 49B841AE1A8 for <rtcweb@ietf.org>; Wed, 4 Dec 2013 11:11:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1955; q=dns/txt; s=iport; t=1386184316; x=1387393916; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/jVKHfq1VYWeJwQtlOkplCr5J0J7T1vGVRbaYok8j+s=; b=b2kc+Zt88wE+dGqQJfz4s3uWpU/ssMRD6U25H4oKCwtiSVia2u2T6iU3 deOuHPyFZvDzpPZtg+tovPgZU+4ECzYCFN0I9oG+gEz8c1+CxaVWGYnHI vPEsW5oaCfoaM6kV0zct4qNgDL60QTt3Y+yCY67X8J7ymsG56MsZLpKV3 M=;
X-IronPort-AV: E=Sophos;i="4.93,826,1378857600"; d="scan'208";a="96225418"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 04 Dec 2013 19:11:56 +0000
Received: from [10.155.144.195] ([10.155.144.195]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB4JBFDP021312; Wed, 4 Dec 2013 19:11:30 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Dan Wing <dwing@cisco.com>
In-Reply-To: <CABkgnnWbf0WYsy9XLyqrg70YdbuePgHF=Yu0wnSLUW6iZB=Mzg@mail.gmail.com>
Date: Wed, 4 Dec 2013 11:11:16 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <4B0EF025-8288-490D-887C-1A4103239CA2@cisco.com>
References: <CABkgnnVNnT8uoWM8T=TqbTmy11CGTeHLP=_7z5KSMSpAsp9SyQ@mail.gmail.com> <52989933.6000907@ericsson.com> <CABkgnnUX3OFUyc5PXeN0ydykBwL0HyRuaigfJKMBbuWnuhnVJg@mail.gmail.com> <02F053C4-ADD9-40D4-BE58-AD9997CFF390@cisco.com> <CABkgnnWbf0WYsy9XLyqrg70YdbuePgHF=Yu0wnSLUW6iZB=Mzg@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.1510)
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: Wed, 04 Dec 2013 19:12:01 -0000

On Dec 4, 2013, at 10:59 AM, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 3 December 2013 16:24, Dan Wing <dwing@cisco.com> wrote:
>> Requiring sending an ICE request (and receiving an ICE response) would also _almost_ work -- that is, when remote party claims to change their IP address not only is an ICE request from their IP address needed, but also need to send an ICE request to their new IP address and get an ICE response (same as you are saying to send them a DTLS heartbeat to their new address).
> 
> Yes, almost.  If ICE restart didn't also correspond with a change in
> ufrag/pwd it might.  As it stands, ICE restart and new victim look
> exactly the same.
> 
>> To thwart that, an ICE attacker would need to be on-path and we could envision places where B (the attacker in your enumerated list above) is on a shared network with C (victim), such as shared WiFi.
> 
> In general, I find that on-path attackers aren't especially
> interesting when it comes to DoS attacks.  Shared WiFi seems like it
> might avoid the "directly on path" part, though since the attacker
> disadvantages themselves as much as their victim, I don't worry.

Sure.  But the attacker doesn't need to remain on that shared network to continue the attack, so the attacker is not (necessarily) disadvantaging themselves -- the attacker just needed to see the packets on the wire and send a command-and-control message to another host that generates the spoofed ICE consent packets.  

> 
>> DTLS heartbeat prevents that attack because B (the attacker) doesn't know the necessary secrets to generate the DTLS heartbeat message (whereas with ICE, B would know the ICE username and ICE password).  If I have all that correct for how ICE consent could be attacked, it shows a security advantage of DTLS consent over ICE consent.
> 
> Yes.  That is definitely an advantage.

-d