Re: [rtcweb] Tunnelling DTLS in SDP

Roman Shpount <> Mon, 04 April 2016 16:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 27D4612D0E2 for <>; Mon, 4 Apr 2016 09:47:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kMk9rvZGgM8o for <>; Mon, 4 Apr 2016 09:47:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 77F2012D119 for <>; Mon, 4 Apr 2016 09:47:28 -0700 (PDT)
Received: by with SMTP id g8so37947220igr.0 for <>; Mon, 04 Apr 2016 09:47:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=91mUTEh72TwhEGiMU8iFIfbnHKuIfKM9m8ffc/oqI64=; b=sPPnexc5y7/41tNxPoFbCDMWhO52TzT98oekz747UwESXu3qlhD4tzvMy0ciNmkZDu ublCdd87yaJp/rQZPA96o83r9yD1YzUZCAhjzB6QD8v7nsnFOurE3FO1e9UxE44FTxoa 1UfpVQ5X7UeLFoU7Yo/KCT0bAU2K71FnBXvwY+Z5lvhrOral9swIcRoaJseIlwvDCbKV tOS+Jg7jhG5niaXJfIPwHG+vE0rESqStq5gp6WrM4GJcUCBYfy/VfmNpZesF1hxj0M+6 /42tWh0Bj4XSv36e02LA/RKaq0BekPnnIdgKorAbB+yac4c2agcfXk81u9+buUNMU8vq kkcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=91mUTEh72TwhEGiMU8iFIfbnHKuIfKM9m8ffc/oqI64=; b=NwTfmWMC3hzKltt9A4xfb84PiWjuFxoC8BhxuamTy0UFhEbSmnX5FBFjVp+oDGgcwl riICVWUzDGAwFlN1LGXfQFEjAy7ztLecXXxyFSLYHwDhavev5vTaE6ZRtg+bK5TVGC2T oBtCXuYWWj0cDNoMYmqzD4wiOn456tUWYnp4bYBJz/iNFLl24snls1ZvnFFTUTkPXVx7 Gp/TOIIBloJ74A4aWYHGfGV4yfQjXk6488aJ7HGpblaENwo2zAcNz5P6gNNAW8y/FZfz AcCn+yTLbqqBxyWi3Wdmf30nAodpFqgbC0hkSDuAB60DjP9IEqUZpTdz79poro+nN3++ pEOg==
X-Gm-Message-State: AD7BkJLNt/JaG5IUrTwctT5lGpeTXtERFQD5FTa/uUgc/4dZy9ibYpvJiIuRqNQA/5Rcsg==
X-Received: by with SMTP id w5mr12152187igk.17.1459788447517; Mon, 04 Apr 2016 09:47:27 -0700 (PDT)
Received: from ( []) by with ESMTPSA id 99sm11961903ior.16.2016. for <> (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2016 09:47:27 -0700 (PDT)
Received: by with SMTP id f1so79803582igr.1 for <>; Mon, 04 Apr 2016 09:47:27 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id e68mr8309382ioe.145.1459788446309; Mon, 04 Apr 2016 09:47:26 -0700 (PDT)
Received: by with HTTP; Mon, 4 Apr 2016 09:47:26 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Mon, 04 Apr 2016 12:47:26 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
From: Roman Shpount <>
To: pfh <>
Content-Type: multipart/alternative; boundary="001a1140d71eca2468052fab7bd4"
Archived-At: <>
Cc: "" <>
Subject: Re: [rtcweb] Tunnelling DTLS in SDP
X-Mailman-Version: 2.1.17
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: Mon, 04 Apr 2016 16:47:32 -0000

On Mon, Apr 4, 2016 at 12:14 PM, pfh <> wrote:

> On 4 Apr 2016, at 16:52, Roman Shpount <> wrote:
> I think sending certificate in the answer instead of data path does not
> compromise security since if signaling path is compromised, data traffic
> can be redirected to MITM agent which can collect exactly the same data.
> That isn’t quite the same, currently in a MITM’d scenario you have the
> option of not completing the DTLS handshake (assuming you had a way
> to verify the fingerprints.). With this change you’ll have all the certs
> logged in a web server somewhere.

In the scenario I had in mind MTIM will not modify fingerprints, it will
modify the transport addresses or put itself on the media path using a
compromised router so that it can log the DTLS handshake (and subsequent
media). This will provide exactly the same security risk as logging
signaling exchange when certificate is sent in the signaling path. In order
to compromise media, attacker needs access to the media path. Once it gets
access to the media path, it gets access to DTLS handshake and
certificates. If one of those certificates is sent over signaling channel,
it does not make the whole flow any less secure. Actually you might argue
it makes it more secure, since now attacker needs to compromise both media
and signaling paths in order to decode.
Roman Shpount