Re: [rtcweb] Comments on draft-ietf-rtcweb-security-06

[Martin Thomson <[e-mail]>]

On 20 February 2014 08:05, Magnus Westerlund
<[e-mail]> wrote:
> When I read this section, my immediate question was, doesn't RTP need
> corresponding protection. To my understanding, the answer would be yes,
> but it is more difficult to inject data and get a certain plaintext even
> without the SRTP encryption scrambling the payload part. Still, that
> assumes that an JS application, can write the payload data itself.
> Secondly, it does assume that one MUST use encryption in SRTP.


Yes, with WebAudio, I can construct an SRTP packet that contains
ciphertext that I can control, assuming that I know the session keys
(yes), and I'm prepared to do a lot of work.  SRTP doesn't have the IV
per-packet that DTLS does.  What you can't do is make it look like a
non-SRTP packet, the first byte, length and MAC would be extremely
difficult to control (for the MAC, that's more or less the point...),
if not impossible.

So the question is, is there an intermediary that might be tricked
into interpreting an SRTP packet in a way that might have negative
consequences.  When masking was added to websockets, it was because
the confusion was demonstrated as being possible: intermediaries were
searching for HTTP requests and responses in ways that were easily
exploited and then caching the results.  To a large extent, that
attack relied on the fact that TCP is a stream-based protocol - it
didn't matter where the request appeared.  In this case, the mapping
of SRTP onto UDP doesn't really lead to intermediaries looking for
goodies inside packets.

I'm not going to say that there is a risk, but I think that I'd be
willing to take the risk given the plethora of mitigating
circumstances here.