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

"Fabio Pietrosanti (naif)" <> Sun, 15 April 2012 12:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B128E21F8792 for <>; Sun, 15 Apr 2012 05:31:16 -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 OFBLE0GQ8RYO for <>; Sun, 15 Apr 2012 05:31:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E7E7621F878E for <>; Sun, 15 Apr 2012 05:31:15 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so3011482wgb.13 for <>; Sun, 15 Apr 2012 05:31:14 -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=j7hCA9Nel5FlXP13V9rY/k1+fESJIKCu7NVnjMEYIOU=; b=UDErAbdOpiaR5If1ztPF4o5qaaCCIehw+0uRyNGRND7ZuaYsnR7BMyu6vsaOEiihM+ UZf+OR2TpGIp1aExNk9G5a1GxHv5DLOQk6IvXziSUpScMG2OlADRmSKkKX3xWmNi7wiE eEbvrkKFKOhNNbi78a2LSLW79NiaG5xnAP4GkDrIpNTORSFKQKSqEcZxUA5HMZTEkSo+ 7vnPIVcr5yO4aZE7byLywlfchCXWii1V0PEqjqpMAAMlaYAsPSTXSDYAby/k5vPLaY5J //elPk1EHi/5SaIA3hSSqtsgef1blcq6KSYUTtSoYsAUHFP01O0BwbuhQWNYP931GhRe /j/g==
Received: by with SMTP id gh6mr10343333wib.22.1334493074591; Sun, 15 Apr 2012 05:31:14 -0700 (PDT)
Received: from sonyvaiop13.local ( []) by with ESMTPS id ff9sm11780535wib.2.2012. (version=TLSv1/SSLv3 cipher=OTHER); Sun, 15 Apr 2012 05:31:13 -0700 (PDT)
Sender: Fabio Pietrosanti <>
Message-ID: <>
Date: Sun, 15 Apr 2012 14:31:10 +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: Randell Jesup <>
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: ALoCoQnEC0nt9jbahxvhTXg2IMJmTcMXhF3A2Fv4714Naxl3wwGeoEFGYvOcf/Lw9IzNZKDTMvSd
Cc: "<>" <>
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: Sun, 15 Apr 2012 12:31:16 -0000

On 4/6/12 6: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.

Well, that's an element of improvement that maybe strongly desiderable,
as it would enable the current DTLS-SRTP standard to provide end-to-end

Otherwise, without independent fingerprint verification method
formalized and mandatory.

The browser would just need to report whenever the communication has:
- end-to-site security (trusting google/signaling provider)
- end-to-end security (verifying it independently)

The JS API would just allow the calling app to specify whenever the
media security authentication would go trough:
- without verification
- with a third party IDP
- with end-to-end authentication (via user to user authentication)

This would really be a strong security improvement to the WebRTC
standard as it would satisfy also end-to-end encryption needs.

And user would be aware of the level of security of their call in a
simple and user-friendly way.

That way the level of security can be evaluated by the end-user, with
security options to be provided by the calling app provider by the
signaling service.

This seems to me quite a reasonable, not so complicated, but very
*powerful* security improvement as it bring end-to-end security to the

Otherwise we would never be able to say that "WebRTC provider end-to-end
>> 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.

This would be really cool.
It's just that current IETF internet-draft does not seems to reflect
this statement (but i maybe wrong, in case point me to the right
sentence highlighting the support for SAS)