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

[Christer Holmberg <[e-mail]>]

Hi,

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

Well, it depends. If you are supposed to be able to provide different alternatives (SRTP vs RTP and AVPF vs AVP) simultanously, it might have impact on the browser requirement, and the browser/app API.

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

A send-a-new-offer-if-the-first-offers-fails mechanism would be backward compatible - assuming the offerer can guess why the first offer failed.

Also, using the AVP and RTP profiles, together with attributes that specifies the AVPF and SRTP stuff would also work. Of course, it goes against the current AVPF and SRTP specifications, and since current legacy deployments would not understand such attributes, they would always end up using AVP and RTP.

Regards,

Christer


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

_______________________________________________
rtcweb mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtcweb