Re: [rtcweb] Consent alternative

Harald Alvestrand <harald@alvestrand.no> Wed, 22 January 2014 14:01 UTC

Return-Path: <harald@alvestrand.no>
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 8AF691A00B6 for <rtcweb@ietfa.amsl.com>; Wed, 22 Jan 2014 06:01:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.434
X-Spam-Level:
X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] 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 K0AZ0aynQ10I for <rtcweb@ietfa.amsl.com>; Wed, 22 Jan 2014 06:01:20 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [IPv6:2001:700:1:2:213:72ff:fe0b:80d8]) by ietfa.amsl.com (Postfix) with ESMTP id 3A61F1A00B2 for <rtcweb@ietf.org>; Wed, 22 Jan 2014 06:01:20 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8015239E989 for <rtcweb@ietf.org>; Wed, 22 Jan 2014 15:01:27 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V20zJI7cKwML for <rtcweb@ietf.org>; Wed, 22 Jan 2014 15:01:26 +0100 (CET)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 55B8139E070 for <rtcweb@ietf.org>; Wed, 22 Jan 2014 15:01:26 +0100 (CET)
Message-ID: <52DFCF2D.4000707@alvestrand.no>
Date: Wed, 22 Jan 2014 15:01:17 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CABkgnnVNnT8uoWM8T=TqbTmy11CGTeHLP=_7z5KSMSpAsp9SyQ@mail.gmail.com> <52989933.6000907@ericsson.com> <CABkgnnUX3OFUyc5PXeN0ydykBwL0HyRuaigfJKMBbuWnuhnVJg@mail.gmail.com> <E721D8C6A2E1544DB2DEBC313AF54DE22436FBD9@xmb-rcd-x02.cisco.com> <CABkgnnUy3HxvsqYfwspEQ9_g1frUuFF4rwD-hTz45UzCr1fTBw@mail.gmail.com> <913383AAA69FF945B8F946018B75898A2428EFD3@xmb-rcd-x10.cisco.com>
In-Reply-To: <913383AAA69FF945B8F946018B75898A2428EFD3@xmb-rcd-x10.cisco.com>
Content-Type: multipart/alternative; boundary="------------030506000202030409060404"
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, 22 Jan 2014 14:01:22 -0000

On 01/22/2014 01:29 PM, Tirumaleswar Reddy (tireddy) wrote:
>
> Based on the discussion there are two different attacks to consider:
>
> a)The attack mentioned by Magnus which is an on-path attack. This 
> attacker can do lot more damage like dropping packets, modifying 
> packets etc. so we may have lot more problems independent of whether 
> STUN or DTLS consent is used. Further in this case since attacker 
> controls the RTCWEB signaling there seems to be no defense.
>
> b)Off-path attack that Martin had mentioned where B is only capable of 
> spoofing IP address of C. This threat can be mitigated by sending DTLS 
> heartbeat with sufficient entropy that guessing would be difficult for 
> an off-path attacker. This off-path attack can also be solved by 
> sending STUN consent whenever the IP address of the remote peer 
> changes and STUN provides strong entropy by using random Transaction 
> ID (96-bit).
>
> If we consider B attacker is also capable of sniffing packets on wire, 
> DTLS heartbeat does not have any benefit over STUN consent because B 
> can sniff the DTLS heartbeat request sent by A and generate response. 
> Since B seems be part of signaling exchange it will have access to 
> fingerprint, short-term username/password etc.
>
Assuming the signalling is encrypted (HTTPS), and B can only sniff 
packets, not be a MITM on the signalling, how does B know the 
fingerprint and short-term username/password?