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

[Dzonatas Sol <[e-mail]>]

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