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

[Paul Kyzivat <[e-mail]>]

This isn't really an rtcweb issue - its a secure media O/A issue.

The exact same thing could arise if we had somebody with an urgent 
desire to do secure media with fallback to insecure media in SIP.
All the arguments against capneg would be exactly the same.

The problem is that people aren't finding capneg a usable solution to 
this problem, just the way that people didn't find SDPng a solution to 
the inadequacies of SDP.

While it is possible for rtcweb to adopt its own solution to the 
problem, that only solves half the problem. And it then creates an 
interop problem with SIP.

The "right" solution is to go back to mmusic for an O/A mechanism for 
secure/insecure media that is more usable than capneg. If its deemed 
that doing this would take too long, and its necessary to do something 
special for rtcweb, then a parallel effort ought to be started to sort 
out how it can interoperate with SIP or anything else that uses O/A.

(The "good" news is that I doubt there are many (any?) deployed uses of 
capneg in SIP for negotiation of secure/insecure media.)

	Thanks,
	Paul

On 9/9/11 5:15 PM, Randell Jesup wrote:
> 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
>>>
>