Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]

[Randell Jesup <[e-mail]>]

On 9/9/2011 3:23 PM, Alan Johnston wrote:
> Ekr is correct.  If we allow RTP, which I think is a mistake, then
> there is always a downgrade attack.

Yes, that's true.  The same issue was involved in the best-effort-srtp 
draft, which unfortunately
was dropped because CapNeg would "solve" it.  (For historical note, it's 
still not "solved"
because CapNeg support is >>>> more complex than best-effort-srtp and 
not generally deployed,
and I doubt ever will be ala SDPng (though I'm not close to status on 
CapNeg.)

Hmmm.  A real downgrade attack requires that the signalling be 
compromised.  I wonder if there
are characteristics of a webrtc transaction that could help avoid this 
sort of attack (for example,
a secondary way out-of-scope here for the app to know ahead of time if 
the target will need to
be downgraded).  Or some way for the service to vouch for the downgrade 
(i.e. wasn't a MITM).
You have to trust the service, but in this case you're doing so to this 
degree anyways.

> My point was that if we must support insecure media, we could avoid
> the complexity of CapNeg by not requiring a single pass non-secure
> media negotiation.

There is another option.  I talked about services that wanted to support 
PSTN  could decide if they
were willing to support a downgrade.  The application could know it's 
calling a PSTN gateway and
if it does know that, avoid a media gateway by not offering encrypted 
media.

I see a significant use-case for some services will be calling PSTN 
numbers and services, much
as it is now for VoIP.
Yes, a bunch of new non-legacy services wouldn't use/want it.  But the 
app for a PSTN-using service
could specifically allow it.

So the question comes down to what's the advantage to using unencrypted 
RTP?
1) No media gateway needed.  This is the big one.  Saves on $$$, saves 
on delay (sometimes a lot),
     may save on complexity in a PBX type of situation.
     But is there an issue due to ICE requirements?  If those can't be 
turned off safely too, that kills this
     whole discussion I think.
2) Debug/etc tools work better with RTP.  Not important.
3) May simplify/improve some E911 cases.  Might be important; likely not.

So, effectively it comes down to "is advantage 1 worth the 
complexity/risk?"  Anyone want to defend that
case?

> - Alan -
>
> On Fri, Sep 9, 2011 at 1:35 PM, Eric Rescorla<[e-mail]>  wrote:
>> Unless I'm missing something, if you (a) support an insecure mode and (b) allow
>> negotiation of insecure vs. secure, there's not really any way to
>> avoid a downgrade
>> issue; the attacker can always pretend not to support security and how do you
>> know better? Obviously, it helps if you can negotiate the use or non-use of
>> media security over a secure-ish signaling channel, but that doesn't reduce
>> the threat from the signaling service.
>>
>> Best,
>> -Ekr
>>

-- 
Randell Jesup
[e-mail]