Re: [rtcweb] Areas of security concern

[Eric Rescorla <[e-mail]>]

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?



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





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.


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.

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.




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

-Ekr