Subject: [rtcweb] Areas of security concern

From: Watson Ladd <[email-masked]>
Date: Tue, 11 Mar 2014 22:11:23 -0700

Dear all,
I've jotted down the following notes when reading the drafts from here and
the W3C as potential problem areas. Maybe there are things I've missed in
the drafts that address them, but I think they are still worth thinking
about. Some of these are more W3C, but we seem to be in charge of the
security. These issues vary widely in seriousness. One of them is a
demonstrated break of confidentiality, while several are open questions
about how we communicate to users.

Problem 1: Which John Smith?

Currently IdPs link attributes to identities. But the way in which
identities are presented to the user can be misleading. Names are not
unique. Do we need a way for an IdP to indicate more about the identity?
Should IdPs be allowed to use social graph information, e.g. prevent me
from calling people who I don't "friend" on a social network, and thus
avoid the wrong John Smith? How does this information get handled? Who
decides what policy is being used?

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.

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.

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.

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.

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.

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.

Conclusion:
Some of these issues result from well-known problems in older protocols.
Others are longstanding difficult problems that have to be solved. Some are
quite dangerous, while others will only permit the occasional prank.
However, it is not enough to fix these specifically. Large areas of the
proposal have not been explored by me. If I had to rate these by
seriousness, problem 3 and 7 are the worst. They are luckily the easiest to
fix.

Sincerely,
Watson Ladd

---

From: Colin Perkins <[email-masked]>
Date: Wed, 12 Mar 2014 09:39:33 +0000

On 12 Mar 2014, at 05:11, Watson Ladd <[email-masked]> wrote:
> Dear all,
> I've jotted down the following notes when reading the drafts from here and the W3C as potential problem areas. Maybe there are things I've missed in the drafts that address them, but I think they are still worth thinking about. Some of these are more W3C, but we seem to be in charge of the security. These issues vary widely in seriousness. One of them is a demonstrated break of confidentiality, while several are open questions about how we communicate to users.
…
> 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.

The security considerations in draft-ietf-rtcweb-rtp-usage-12 refer to RFC 6562, which I believe gives recommendations to address this.

Colin

> Conclusion:
> Some of these issues result from well-known problems in older protocols. Others are longstanding difficult problems that have to be solved. Some are quite dangerous, while others will only permit the occasional prank. However, it is not enough to fix these specifically. Large areas of the proposal have not been explored by me. If I had to rate these by seriousness, problem 3 and 7 are the worst. They are luckily the easiest to fix.
> 
> Sincerely,
> Watson Ladd
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Colin Perkins
http://csperkins.org/

---

From: John Mattsson <[email-masked]>
Date: Wed, 12 Mar 2014 09:54:05 +0000

From: Watson Ladd <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 12 March 2014 05:11
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [rtcweb] Areas of security concern

Dear all,

…

>If I've chased the chain of references correctly this is the sole MAC provided.

John: Yes this is correct, (But AES-GCM and AES-CCM should  be available before WebRTC)

>Is it okay? I have no idea: SHA-1 has been significantly weakened in recent years.

John: This is ok. While SHA-1 itself is weak and should not be used for signatures, there are no attacks on HMAC-SHA-1.
NIST current recommendations say that HMAC-SHA-1 is good for use beyond 2030 (http://www.keylength.com/<http://www.keylength.com/en/4/> )

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Mar 2014 08:16:01 -0700

Watson,

Thanks for your comments. Responses below.

On Tue, Mar 11, 2014 at 10:11 PM, Watson Ladd <[email-masked]> wrote:

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

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

> provided. Is it okay? I have no idea: SHA-1 has been significantly weakened

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.

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

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

> 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

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

---

From: Watson Ladd <[email-masked]>
Date: Thu, 13 Mar 2014 10:21:43 -0700

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

> store all the identity assertions it generates in a database and retrieve

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.

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

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?

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

Yeah, punting is perfectly fine on this one. I fully expect heavy exploitation.
>> 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.
>
>

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

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