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

Justin Uberti <> Fri, 06 April 2012 16:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 617A821F853E for <>; Fri, 6 Apr 2012 09:13:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -100.382
X-Spam-Status: No, score=-100.382 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ee+Z9RGHF63z for <>; Fri, 6 Apr 2012 09:13:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 537E321F8539 for <>; Fri, 6 Apr 2012 09:13:15 -0700 (PDT)
Received: by qcsq13 with SMTP id q13so1756315qcs.31 for <>; Fri, 06 Apr 2012 09:13:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=pAX51332wrxqbCgfLp4J7t6csb/TIyHYoDRFhgOOpRU=; b=hrbE770MNLohFtBGwxuGXxDUbvOc4Hvt709catjEagO+Xo/KCg1JDM2vGkwRd5qh/T Q8+zNLG71lIc97PQtqwh/dCiMLVUCgP0g557NnlXGfRNi+c3SOJZHrxNPjaLR3Pw//xY rLyCY1dTD2OvGc0RR9jtGl6uP3zC6iZHPqaPBb5nGIU8RErvF8zBwPxFSzx/irbWTgBq ZAo5egD92FHtRGSjMtHSrVdqn9A70xrOcxn9liq2NpVLZNi0zPaGgvtcr9eul1LQNStf uJ1sut5B0ybB2ha621pleUdj3ne3UXVjHVHj/IIxMORPJc/ftRWtKNZRV+GhZlGccGdM 7uNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=pAX51332wrxqbCgfLp4J7t6csb/TIyHYoDRFhgOOpRU=; b=c8uUybLfjRGIIHih4FioQgZjw4exwoUqPFVR0TGee75r5A9oic49u4hOWEwQXeKub9 IOcjlJfXCYAxD3E5BXbC2cjvoTwNflQTbawlA6Ke2YrOGtilGcHalc42+vu5S9VgfqGe 5UmGMUKQDEo1cLrOp3ei2LmNO/XeeLATUzRory4uFnW4wDQHAMv6VS8ZCT/V1jwkosjX doAmjTAx9VgKAOtQF3KTs53gTrUukS931ZAqJpmlPJ8o82+0ygHTzeYTFn7dospjqiXO oYnGbnojRR5YTI786aUrC91KQuj4mEIHRQWjquqPIHvqTQR4wNuvZJorfq6oXIaVz5WM DHow==
Received: by with SMTP id z5mr10001768qac.26.1333728794732; Fri, 06 Apr 2012 09:13:14 -0700 (PDT)
Received: by with SMTP id z5mr10001756qac.26.1333728794606; Fri, 06 Apr 2012 09:13:14 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 6 Apr 2012 09:12:54 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Justin Uberti <>
Date: Fri, 06 Apr 2012 12:12:54 -0400
Message-ID: <>
To: Randell Jesup <>
Content-Type: multipart/alternative; boundary="20cf306f72ee077b4d04bd04efe2"
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQnCznz7L4UR6iDt5lp0HW2CRrzaMDAZOQa5uZI8z6O4ZpobiYsLQ8PJLKOhXabX7s/hjDbokcLlKjyi7ahIFgPodbTxVkisFfPtfJkm/mzT7n2nA4ZXfE65C0nilXwGm+ApgAuN
Subject: Re: [rtcweb] DTLS-SRTP with end-to-end security: Short Authentication String
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: Fri, 06 Apr 2012 16:13:16 -0000

On Fri, Apr 6, 2012 at 12:57 AM, Randell Jesup <>wrote:

> tl;dr:  I believe SAS should be supported by the browser (or non-browser
> app/device) UI, and I believe that's the current plan though perhaps it's
> not written as a MUST.  I am much more hesitant to endorse key-chaining due
> to usability issues.

+1 for browsers presenting the digest information to the user on demand, so
that they can perform a manual verification step, if desired.

> On 4/5/2012 1:04 PM, Fabio Pietrosanti (naif) wrote:
>> In the RTCWeb security there is a proposed solution, to use SAS:
>> section-<>
>> 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.
> The reason the document described it that way (and it was a subject of
> discussion at IETF 81 or an interim phone call since then) is that users
> generally don't use or understand SAS.  Yes, extremely security-conscious
> individuals can use it to verify a given connection.  The ZRTP key-chaining
> is somewhat problematic in a modern world where destinations are people who
> may use one of N devices, not hard-coded numbers tied to a specific piece
> of hardware.
> ZRTP was designed to lower the bar for encryption, by making it possible
> to ignore SAS initially under the assumption that the first connection is
> safe.  That assumption might not hold.  And the occasional key-chaining
> failure caused by either loss of key-chain info (device reset, etc) or by
> substitution of devices or forwarding of a call will cause an ongoing level
> of false-positives that will weaken any response to a real MITM.  If in
> response to a failure they don't do SAS, but instead just accept it, then
> they are now silently MITM'd until they do SAS.
> Fundamentally, though, as stated in the meetings, the ease-of-use bar for
> ZRTP-like SAS+chaining is just too high for non-security-experts (or the
> non-paranoid (whether rightfully non-paranoid or not)).  We could run
> chaining with the current design, and that has been discussed, but when I
> call you from my tablet instead of my PC, the chain won't match and the
> MITM flag would fire.
> This is why we explored and suggested to allow for an Idp to allow
> authentication of the other party to a call.  Does this provide the same
> level of security by default as a working PKI infrastructure, or of
> ZRTP+SAS?  No.  But SAS is still supported (I believe this question was
> asked at IETF 83), so the truly security knowledgeable can verify
> end-to-end security anytime they want, while general users can get
> considerably more security (if the Idp is not also their service/app
> provider) than they would with SDES.
> Note that if the cert used by an attacker is the result of a hack like
> Diginotar (or government-sponsored spoofing via a captive CA), then the
> user is severely at risk in any scenario due to injection of compromised JS
> code from a supposedly trusted source, doubly so if the app has been
> granted the right to turn on cameras and mics.  SDES is totally broken at
> that point.
>  I would like to bring the attention of the WG to provide a MANDATORY
>> requirement to enable SAS verification.
> I think the question was asked at IETF (paraphrased): will SAS be
> available through the UI in some manner?  Yes.
> So I don't think there's any problem with this request.  Chaining may be
> more problematical.
> --
> Randell Jesup
> ______________________________**_________________
> rtcweb mailing list