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

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 09 September 2011 21:12 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B897D21F869E for <rtcweb@ietfa.amsl.com>; Fri, 9 Sep 2011 14:12:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.525
X-Spam-Level:
X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xbed4GOhbSUn for <rtcweb@ietfa.amsl.com>; Fri, 9 Sep 2011 14:12:09 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9D82C21F869C for <rtcweb@ietf.org>; Fri, 9 Sep 2011 14:12:08 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-ce-4e6a819b7b27
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E7.B9.20773.B918A6E4; Fri, 9 Sep 2011 23:14:04 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 9 Sep 2011 23:14:04 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: 'Dzonatas Sol' <dzonatas@gmail.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Date: Fri, 9 Sep 2011 23:14:03 +0200
Thread-Topic: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]
Thread-Index: AcxvMpLjgFQ/kh6FS+O488IfjuKOsAAAsE9g
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233D45F98@ESESSCMS0356.eemea.ericsson.se>
References: <A444A0F8084434499206E78C106220CA0B00FDB08B@MCHP058A.global-ad.net> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <E4EC1B17-0CC4-4F79-96DD-84E589FCC4F0@edvina.net> <4E67C3F7.7020304@jesup.org> <BE60FA11-8FFF-48E5-9F83-4D84A7FBE2BE@vidyo.com> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <C3759687E4991243A1A0BD44EAC8230339CA68F054@BE235.mail.lan> <CAOJ7v-2u0UuNXh7bzmZFwiSucbsh=Ps=C3ZM5M3cJrXRmZgODA@mail.gmail.com> <CAKhHsXHXCkNdjtpxCSCk+ABbtxY15GEgouE6X6-sn-LqhnidQw@mail.gmail.com> <4E6A56D4.2030602@skype.net> <CABcZeBOdP6cAqBoiSV-Vdv1_EK3DfgnMamT3t3ccjDOMfELfBw@mail.gmail.com> <CAKhHsXFdU1ZaKQF8hbsOxwTS-_RfmFqQhgzGe=K4mRp+wz+_nQ@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45F96@ESESSCMS0356.eemea.ericsson.se> <4E6A7D47.5020201@gmail.com>
In-Reply-To: <4E6A7D47.5020201@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Sep 2011 21:12:09 -0000

What security do we avoid by avoiding CapNeg?

Regards,

Christer 

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Dzonatas Sol
Sent: 9. syyskuuta 2011 23:56
To: rtcweb@ietf.org
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: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On 
> Behalf Of Alan Johnston
> Sent: 9. syyskuuta 2011 22:24
> To: Eric Rescorla
> Cc: Randell Jesup; Jonathan Lennox; rtcweb@ietf.org
> 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<ekr@rtfm.com>  wrote:
>    
>> On Fri, Sep 9, 2011 at 11:11 AM, Matthew Kaufman 
>> <matthew.kaufman@skype.net>  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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>    


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

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb