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

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Thu, 05 Apr 2012 19:04:56 +0200

Hi,

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:
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.

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:
		
		http://tools.ietf.org/html/rfc6189#section-15

  "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
   conversation."

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.

Fabio

---

From: Randell Jesup <[email-masked]>
Date: Fri, 06 Apr 2012 00:57:35 -0400

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.

> 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.

> 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
[email-masked]

---

From: Justin Uberti <[email-masked]>
Date: Fri, 6 Apr 2012 12:12:54 -0400

On Fri, Apr 6, 2012 at 12:57 AM, Randell Jesup <[email-masked]>wrote:

> 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.

>> 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>
>>
> 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.
>
> 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.
>
> 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.
>
>
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Sun, 15 Apr 2012 14:31:10 +0200

> 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
security.

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
standard.

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

Fabio