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

[Dzonatas Sol <[e-mail]>]

Real-time is your default security; "to avoid" that in this WG.... 
edited: The only security needed for an API is the guarantee/certificate 
of the pure software VM process (i.e. OSI) ("to avoid CapNeg"); 
otherwise, CapNeg is hardware hacking.

[Not everybody complies with the strictness of nuclear licenses, and 
clarity only goes so far.]

On 09/09/2011 02:14 PM, Christer Holmberg wrote:
> 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
>
>    


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