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

[Justin Uberti <[e-mail]>]

On Fri, Apr 6, 2012 at 12:57 AM, Randell Jesup <[e-mail]>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:
>> http://tools.ietf.org/html/**draft-ietf-rtcweb-security-02#**
>> section-4.3.2.2<http://tools.ietf.org/html/draft-ietf-rtcweb-security-02#section-4.3.2.2>
>>
>> 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
> [e-mail]
>
> ______________________________**_________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>