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

[Randell Jesup <[e-mail]>]

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.

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