[rtcweb] DTLS-SRTP with end-to-end security: Short Authentication String

"Fabio Pietrosanti (naif)" <lists@infosecurity.ch> Thu, 05 April 2012 17:05 UTC

Return-Path: <lists@infosecurity.ch>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8260321F8767 for <rtcweb@ietfa.amsl.com>; Thu, 5 Apr 2012 10:05:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id vmXpOO1rxJUJ for <rtcweb@ietfa.amsl.com>; Thu, 5 Apr 2012 10:05:01 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 918A521F8749 for <rtcweb@ietf.org>; Thu, 5 Apr 2012 10:05:01 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so1037794wgb.13 for <rtcweb@ietf.org>; Thu, 05 Apr 2012 10:05:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding :x-gm-message-state; bh=2vs9r8D/JnlFr+0tu0eOpzuMn4ud5GpOCXR2tEaFtWo=; b=jDG48IdpJMk5mYBqVUZU7d4QqrskclYtcQKZeyZSh/Nid4KxszvLJF6c2qh805OccD c6cvhFMfWI/a6O2GD2ciRQVw7ldaNM7277dEkM8DDwMD2EQ3lkx1bdng5Fh6n8zqMU8U jNacwG771H0YVCg/pRdOZ1A0gR9wOthSjwDbDUaYUpraql54n/VOb12Z10JhSCBRGCw6 Y9hHsCGG0wpiSs/hF2tS/U3J+iKQx8X/QfDFVGQ7tEfqM8DC5JIxzLwA23uNgi4Exu8q YovKKq3jXCUna+cJGKPmleu18dLKoIxgeecf9iz4cLl+QIgPKsz5raXTYpGHKdcreQW2 w61Q==
Received: by with SMTP id y12mr2085532wep.39.1333645500606; Thu, 05 Apr 2012 10:05:00 -0700 (PDT)
Received: from sonyvaiop13.local (93-57-41-37.ip162.fastwebnet.it. []) by mx.google.com with ESMTPS id n20sm19276161wiw.5.2012. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 10:04:58 -0700 (PDT)
Sender: Fabio Pietrosanti <naif@infosecurity.ch>
Message-ID: <4F7DD0B8.2030900@infosecurity.ch>
Date: Thu, 05 Apr 2012 19:04:56 +0200
From: "Fabio Pietrosanti (naif)" <lists@infosecurity.ch>
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: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQlm8daVQ1La+M4/eJ4HPGybXA3D+G7DzMlNNqjj3mpdmahHwckE2PhK0EAuB/DljjQ/Zgrq
Subject: [rtcweb] DTLS-SRTP with end-to-end security: Short Authentication String
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 05 Apr 2012 17:05:02 -0000


i've been reviewing the WebRTC security architecture and it seems to me
that the authors did not considered the value of end-to-end security.

DTLS-SRTP does not provide end-to-end security because it rely on third
party of key authentication.

In the RTCWeb security there is a proposed solution, to use SAS:

SAS, Short authentication string, allow to achieve end-to-end security
within the DTLS-SRTP end-to-end encryption protocol.

Unfortunately the author of rtcweb-security described the SAS as a bad
way to verify fingerprints.

I would like to argue that SAS are instead a valuable, secure mechanism
to provide end-to-end authentication to an end-to-end encryption system,
thus realizing end-to-end security.

I would like to bring the attention of the WG to provide a MANDATORY
requirement to enable SAS verification.

RFC 6189 (ZRTP) explain the reason why SAS are secure enough and the
comments on the rtcweb-security draft should be reconsidered:

  "Some questions have been raised about voice spoofing during the short
   authentication string (SAS) comparison.  But it is a mistake to think
   this is simply an exercise in voice impersonation (perhaps this could
   be called the "Rich Little" attack).  Although there are digital
   signal processing techniques for changing a person's voice, that does
   not mean a MiTM attacker can safely break into a phone conversation
   and inject his own SAS at just the right moment.  He doesn't know
   exactly when or in what manner the users will choose to read aloud
   the SAS, or in what context they will bring it up or say it, or even
   which of the two speakers will say it, or if indeed they both will
   say it.  In addition, some methods of rendering the SAS involve using
   a list of words such as the PGP word list[Juola2], in a manner
   analogous to how pilots use the NATO phonetic alphabet to convey
   information.  This can make it even more complicated for the
   attacker, because these words can be worked into the conversation in
   unpredictable ways.  If the session also includes video (an
   increasingly common usage scenario), the MiTM may be further deterred
   by the difficulty of making the lips sync with the voice-spoofed SAS.
   The PGP word list is designed to make each word phonetically
   distinct, which also tends to create distinctive lip movements.
   Remember that the attacker places a very high value on not being
   detected, and if he makes a mistake, he doesn't get to do it over.

   A question has been raised regarding the safety of the SAS procedure
   for people who don't know each other's voices, because it may allow
   an attack from a MiTM even if he lacks voice impersonation
   capabilities.  This is not as much of a problem as it seems, because
   it isn't necessary that users recognize each other by their voice.
   It is only necessary that they detect that the voice used for the SAS
   procedure doesn't match the voice in the rest of the phone

In any crypto-system if the user is not able to INDEPENDENTLY verify the
integrity of the key exchange we refer it to END-TO-SITE SECURITY.

In any crypto-system if the user is able to INDEPENDENTLY verify the
integrity of the key exchange, we refer it to END-TO-END SECURITY.

So basically WebRTC currently does NOT guarantee end-to-end security.
But making SAS mandatory will allow independent way to verify the keys.