Re: [rtcweb] End-to-end encryption vs end-to-end authentication (DTLS-SRTP / SDES-SRTP)

"Fabio Pietrosanti (naif)" <> Thu, 05 April 2012 18:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 68D5721F85A5 for <>; Thu, 5 Apr 2012 11:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v0boIlyFbUyU for <>; Thu, 5 Apr 2012 11:10:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 42CCA21F8601 for <>; Thu, 5 Apr 2012 11:10:45 -0700 (PDT)
Received: by werb10 with SMTP id b10so1237257wer.31 for <>; Thu, 05 Apr 2012 11:10:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=CX0pxSyFOr1quaXTMgnhK7MC3RP5vd0wW49JlJplk3U=; b=Uii6/UVn6qu66bXXJ6V4cTqs31ovz+4oa4T5QVE6ouososSD41/s/d/b+ivxatrWN0 vd0gtLwRnxPPMyMJj3y3feofdcqGBRIRnHqP6zd6oZZRx1gHBTlWT+6bT3tgvPsWw87K Xa8zOYwuHX1uvWEoNGwvRHRuqcJ0g945TtBh1XK+aNUvndVtsgjxhePf/EWkLcTBbNSX hArvctJVer/zs40RJz1EYPj5bta8rLGGlqrex6Eq3RmYG+bPtLlv7nwARWOtIcExU4Bd roROSE1m/VSNb024fNL3GufolCDJlDAKSBSnGxN+EmtGyvd56F9yXVv9LZ2M1zeMjINg RXEQ==
Received: by with SMTP id y21mr2231286wei.110.1333649440356; Thu, 05 Apr 2012 11:10:40 -0700 (PDT)
Received: from sonyvaiop13.local ( []) by with ESMTPS id ff2sm19963404wib.9.2012. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 11:10:38 -0700 (PDT)
Sender: Fabio Pietrosanti <>
Message-ID: <>
Date: Thu, 05 Apr 2012 20:10:36 +0200
From: "Fabio Pietrosanti (naif)" <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Roman Shpount <>
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQlXj/ju5czVNJOaJIF9PvHh3zmOi1VxhmqvP5pzQ3yerI/ppvTiqLcWxDZZ/NZw4iUuAbsa
Subject: Re: [rtcweb] End-to-end encryption vs end-to-end authentication (DTLS-SRTP / SDES-SRTP)
X-Mailman-Version: 2.1.12
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: Thu, 05 Apr 2012 18:10:47 -0000

On 4/5/12 7:42 PM, Roman Shpount wrote:
> On Thu, Apr 5, 2012 at 1:07 PM, Fabio Pietrosanti (naif)
> < <>> wrote:
>     This means that DTLS-SRTP, from a trust-model point of view, does not
>     provide end-to-end security because there will always be a trusted third
>     party able to authorize Man in the Middle to do eavesdropping.
> Incorrect. If fingerprint is exposed and can be verified, DTLS-SRTP does
> provide end-to-end security. No third parties involved.

No, you are wrong in the understanding.

The fingerprint is always delivered from the signaling services, so by
the HTTPS website providing the JS calling application.

>From :
                      RTCWEB Security Architecture

4.1.  Initial Signaling

In either case, it will contain:

   o  Media channel information
   o  ICE candidates
   o  A fingerprint attribute binding the communication to Alice's
      public key [RFC5763]

   This message is sent to the signaling server, e.g., by XMLHttpRequest
   [XmlHttpRequest] or by WebSockets [RFC6455] The signaling server
   processes the message from Alice's browser

So basically the "signaling service" provide the fingerprint information.

Additionally, in case you want to trust the fingerprint verification via
an identity provider, please read below:
		RTCWEB Generic Identity Provider Interface  Authenticating Party
   o  If a IdP is provided by the calling application use that.

The IdP is provide *by the signaling service*.

So basically:

- The user get the calling application from signaling service
- The user get the fingerprint from signaling service
- The user get the IdP from the signaling service

So basically the signaling service can ALWAYS do MITM and provide
eavesdropping services to authorized and non-authorized users.

>From a trust model point of view:


Because in both case the "signaling service" is a trusted third party
able to intercept phone calls.

It's important to define clearly somewhere that "WebRTC does not provide
end-to-end security"