Re: [secdir] secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-16

[Stephen Farrell <[e-mail]>]

On 25/10/10 15:04, Ali C. Begen (abegen) wrote:
> Hi Stephen,
> 
> This time, hopefully a quick answer. 

Let's keep it up while we can:-)

>> The first is that this protocol is vulnerable to off-path DoS attacks
>> unless SRTP is used, and even where SRTP is used, additional (though
>> minor) constraints on how it is used are required to prevent
>> authorized receivers messing with one another.
> 
> First of all, while RAMS could be favored more by the attackers due to the damage it can make, the same set of problems exist in any scenario where a feedback target (receiving feedback from multicast receivers) is supposed to act on them (doing retransmissions, or asking the actual media source to slow down, speed up, etc.).

Fair enough. I've no idea if this application is more likely
to be used as a potential DoS vector, compared to others with
the same issues.

> If we really need further explanation about SRTP, I will get together with my SRTP-savvy friends and work on this.

Don't think that's needed myself, its more whether or not
SRTP is a real solution that'll be used, and as I say, I've
no idea about that.

>> The -16 version is clear enough (I think) about this, so my only
>> remaining question is whether or not SRTP, with the additional
>> constraints specified, is likely to be deployed or not.
> 
> Well, I think we are only responsible to mention the problems and possible solutions. We cannot force vendors to implement everything from A to Z. The first deployment that RAMS has is the IPTV networks (for fast channel change). In such environments, the networks are managed and clients are deployed by the operator anyway. So, many of these concerns are not even relevant. I'd imagine they would not care much about SRTP.
> 
> In other areas, SRTP could be needed, but will it be always used? It is not up to me.

Sure. But I guess there are other situations where RFCs say
e.g. "use s/mime" but we know that people just don't do that.

>> I have no idea myself, but if its unlikely to really be deployed,
>> then the vulnerability could probably easily be exploited which
>> would be bad and would lead me at least to wonder whether it would
>> be wiser to try to design this so that it is less vulnerable to
>> off-path attacks. (Assuming that such a solution exists of course.)
> 
> I would not say it is very unlikely as SRTP exists today in many VoIP applications. So, the code is available. It is not rocket science, either. So, there is hope ;)

Right. And I assume that the AVT WG and the IESG might know
if that hope is likely to be realised.

To be clear, I'm not asking for a change to -16 here, I'm really
asking if -16's use of SRTP is likely to happen or not, and if
not, (which you guys may know), then whether that's considered
ok or not.

>> The second one relates to the additional SRTP constraints. The new
>> text says that the BRS needs to keep a list of receiver certs (which
>> seems unlikely) or else must ensure that all receivers are certified
>> by some "trusted" CA. I don't think that really works - if the
>> problem is that authorized receivers could DoS one another then I
>> don't see how this fixes that. Or am I missing something?
> 
> Hit by your friends? E.g., the wife's set-top can attack the husband's set-top if her channel changes are getting slower. That is a tough problem to fix, though ;)

Well, hit by anyone else who can change a channel using
that BRS, which presumably is more than just my friends.

> I think this can be only solved if each unicast session is associated with the initial requestor's cert. So, only the messages with the right cert can cause changes in that session. Would that solve the problem?

I guess so, though that then depends on each receiver having
a key pair and cert, which is probably a deployment headache.
Is there no other way that this protocol could be hardened
against off-path DoS attempts? E.g. if messages contained a
nonce that had to be present in each subsequent message if
it was present in the first? Maybe the WG considered that
and rejected it, I don't know.

Cheers,
S.

> 
> -acbegen
>  
>> S.
>>
>> PS: The text quoted is from the response to my review of -15, I
>> guess it makes life easier to change the subject line to -16 for
>> this re-review but I might be wrong. If so, sorry;-)
> 
>