Re: [rtcweb] Areas of security concern

[Watson Ladd <[e-mail]>]

On Thu, Mar 13, 2014 at 8:16 AM, Eric Rescorla <[e-mail]> wrote:
> Watson,
>
> Thanks for your comments. Responses below.
>
>
> On Tue, Mar 11, 2014 at 10:11 PM, Watson Ladd <[e-mail]> wrote:
>>
>>
>> Problem 1: Which John Smith?
>>
>> Currently IdPs link attributes to identities.
>
>
> The identities are phrased as RFC822-style names subordinated beneath
> the domain name of the IdP (or if the IdP is a universal trust point, then
> not subordinated). See:
>
> http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-09#section-5.6.5.3.3.1
>
> There used to be a human-readable display-name property as well but that's
> gone as of this version, precisely because of concerns of this type. Perhaps
> you are reading a pre-09 version?

No, I am reading the most recent version. Ask someone named John Smith
how much email they get not addressed to them. Address-book style
limitations might be a useful UI feature, but I don't see how to do it
here without custom integration. We can always punt on this until
later: there is nothing stopping a more extended set of interactions
with IdP in their verification process.

>
>
>>
>> Problem 2: IdP pointy bits
>>
>>
>> An IdP has to cryptographically bind a username to some data. It would be
>> nice if we could come up with a secure method to do this, and have the
>> browser take care of it for the identity provider as much as possible,
>> instead of everyone having to do it themselves in likely wrong ways. The
>> webcrypto API has been roundly critiqued as being too low-level.
>
>
> We certainly considered this, but that would basically amount to choosing
> a specific identity system or standardizing our own, neither of which seems
> totally awesome. Incidentally, cryptography isn't actually required here
> (though it's probably the method of choice). The IdP could also just
> store all the identity assertions it generates in a database and retrieve
> it on demand.

As it stands you have an open invitation for everyone to try to roll
their own, and fail miserably. Even a higher-level sign/verify API
would
assuage my complaint. Probably a W3C thing though/educating the people
implementing/writing the higher-level API.

>
>
>
>
>
>> Problem 3: Renegotiation
>>
>> The DTLS handshake being used is specified in RFC 4347. In particular, I
>> don't see anything about the renegotiation bug being fixed. This enables an
>> unknown key-share attack in which A thinks they are transmitting video to B,
>> but really are transmitting it to C who knows that they are talking to A.
>
>
> I'm certainly aware of this paper --- though as you know it just came
> out recently --- but it's not clear to me how applicable it is,
> since the client-authentication version of the attack (which I believe
> is the appropriate one here) depends on the TLS server changing
> its identity during the session, and RFC5763 requires that the
> certificates presented during the DTLS handshake match the
> fingerprints in the SDP:
>
>    o  The certificate presented during the DTLS handshake MUST match the
>       fingerprint exchanged via the signaling path in the SDP.  The
>       security properties of this mechanism are described in Section 8.
>
> RFC 5763 doesn't explicitly talk about renegotiation, so we probably
> could add something about handling renegotiation.
>
> If you think of some way in which the mechanisms above aren't sufficient
> please drop me a private e-mail so we can discuss.

If the client and server stick to the flow in RFC 5764, then all is
good, because the client's signature verify message signs the
handshake and there is only one hello.

However, it needs to be made explicit that you have to stick exactly
to this message sequence. If a client lets the server trick it into
renegotiating, we have a problem.

Because you never put a state machine into the TLS 1.1 spec, I've had
a devil of a time figuring out if this is possible. In particular, it
could be that the transition to SRTP after the finished stops
renegotiation from being possible.

How does rekeying work in DTLS+SRTP?

>
>
>> Problem 4: HMAC-SHA1 in SRTP
>>
>> If I've chased the chain of references correctly this is the sole MAC
>> provided. Is it okay? I have no idea: SHA-1 has been significantly weakened
>> in recent years.
>
>
> As far as I know, HMAC-SHA1 is sufficiently secure for this purpose. Three
> notes about this:
>
> 1. We are discussing audio and video packets so there are a lot of them
> but modifying any particular one doesn't generally get you much.

Video codecs are infamous for having exploitable bugs. Sending in a
maliciously formed packet from outside could lead to fun.
But yes, I agree that HMAC-SHA1 is probably fine, and given that we
are getting CCM I'm not too worried. (Rekeying is a necessity with all
of these because of the small MACs).
>
> 2. The MACs are truncated to 80 or 32 bits.
>
> 3. There are GCM ciphersuites in the pipeline but they haven't landed yet.
>
> This is really an issue for the IETF AVTCORE WG, however, since it applies
> to all of SRTP, not just rtcweb.
>
>
>
>
>
>>
>> Problem 5: What you see is not what I sent
>>
>> This is an area that is somewhat underspecified, depending as it does on
>> the media API's capabilities. The video frame could be silently replaced by
>> a different video frame with rather different contents. Any authentication
>> of the contents of the video frame would not carry over, but if the contents
>> were sufficiently shocking/subtle this might not be noticed. Authentication
>> independent of the website offering the video chat makes this attack worse,
>> because users will trust what they see more. Isolation doesn't help because
>> this is wholesale replacement, not editing.
>>
>> Most uses of this attack are for puerile purposes. I don't think it's a
>> big concern. Then again I could be very, very wrong.
>
>
> We certainly know about this form of attack. For instance, you can just
> pretend to operate a calling service but instead of showing the remote
> video you can just embed a YouTube video. There are effectively two
> cases here:
>
> - The call is not using isolated streams in which case you didn't have
>   any protection for the media from the site anyway.
>
> - The call is using isolated streams in which case the site will have
>   no access to the true media and so can only blindly inject their
>   own.
>
> Obviously this isn't ideal but it's pretty hard to get rid of since the Web
> already includes video and even without WebRTC, it's trivial for a site
> to play any video it wants to you. We've talked about having some sort
> of UI for showing each video element and its provenance, but it's a hard
> UX problem.

Yeah, punting is perfectly fine on this one. I fully expect heavy exploitation.
>
>
>
>>
>> Problem 6: General UI issues
>>
>> Currently quite a bit of the security model depends on UI presentations of
>> subtly different states. I don't know how well users will understand this,
>> or how well the UI will work. Past experience suggests not well. Luckily we
>> can mostly change this later/it isn't part of standardisation.
>
>
> Yes, we are aware of this. Not sure there's much to do about it.
>
>
>>
>> Problem 7: VBR privacy leaks
>>
>> I can do no better then to refer to the paper.
>> http://www.infsec.cs.uni-saarland.de/teaching/WS08/Seminar/reports/yes-we-can.pdf
>> Spoken phrases could be identified from encrypted data alone, using a Hidden
>> Markov Model when the length of packets was preserved by the encryption.
>
>
> Yeah, this is also a known issue. See RFC 6562 for some recommendations
> on how to address this. If you want to work on this issue, you should
> probably
> take it to the AVTCORE WG.

Why is RFC 6562 not cited in the security architecture document? My
method was to work back from the security architecture RFC, so I
missed that this was fixed. Hopefully an implementor doesn't do the
same.

Sincerely,
Watson Ladd

>
> -Ekr
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin