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

[Christer Holmberg <[e-mail]>]

What security do we avoid by avoiding CapNeg?

Regards,

Christer 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Dzonatas Sol
Sent: 9. syyskuuta 2011 23:56
To: [e-mail]
Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]

On 09/09/2011 01:22 PM, Christer Holmberg wrote:
> Hi,
>
> In general I agree with Alan that we should try to avoid CapNeg.
>    

The only security needed "to avoid" that is the guarantee/certificate of the pure software VM process (i.e. OSI); otherwise, CapNeg is hardware hacking.

The stateless API is the default capabilities, so there is no carrier for some secure state otherwise. Discovery of further capabilities is ideal in duration of the carrier.

I find it helpful to munge client and server APIs into one API set instead of separate definitions as proof. Capabilities then are just driver issues, not application issues.


> Regarding AVPF vs AVP, we also first need to decide whether AVP will be supported in the first place. Then, if we decide to support AVP, we have to make a similar decision whether to use CapNeg or to rely on a "fallback" offer/answer.
>
> Regards,
>
> Christer
>
>
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Alan Johnston
> Sent: 9. syyskuuta 2011 22:24
> To: Eric Rescorla
> Cc: Randell Jesup; Jonathan Lennox; [e-mail]
> Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and 
> offer/answer)]
>
> Ekr is correct.  If we allow RTP, which I think is a mistake, then there is always a downgrade attack.
>
> 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.
>
> - Alan -
>
> On Fri, Sep 9, 2011 at 1:35 PM, Eric Rescorla<[e-mail]>  wrote:
>    
>> On Fri, Sep 9, 2011 at 11:11 AM, Matthew Kaufman 
>> <[e-mail]>  wrote:
>>      
>>> On 9/9/11 10:47 AM, Alan Johnston wrote:
>>>        
>>>>   The default will be SRTP - this can be expressed in SDP without 
>>>> CapNeg.  Should the RTCWEB clients choose to instead negotiate RTP, 
>>>> then this could be done with a second SDP Offer/Answer exchange.
>>>>          
>>> I believe you've just designed a downgrade vulnerability.
>>>        
>> 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
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>    


--
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant

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