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

Dzonatas Sol <dzonatas@gmail.com> Fri, 09 September 2011 20:51 UTC

Return-Path: <dzonatas@gmail.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 A359621F86A2 for <rtcweb@ietfa.amsl.com>; Fri, 9 Sep 2011 13:51:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.938
X-Spam-Level:
X-Spam-Status: No, score=-3.938 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 n1jBAoPykA8F for <rtcweb@ietfa.amsl.com>; Fri, 9 Sep 2011 13:51:48 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1CA21F8559 for <rtcweb@ietf.org>; Fri, 9 Sep 2011 13:51:42 -0700 (PDT)
Received: by yxt33 with SMTP id 33so559848yxt.31 for <rtcweb@ietf.org>; Fri, 09 Sep 2011 13:53:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=JqCCeT55stODZmt4a9ZVDrYQG7ZQDmkvr9SJBs6SPB8=; b=QO1KrrLU8fYTVClCWibPQ+Hf6kejJw5rSf+13xlWcrRr0nroRMMOJfgqFjxtKJRN0R /lbWH7eeeDpeREv+cam9Y1uXboOF9qOhj7+44dDduTNH4jxyPQepH7bYDLFFLrXFwjwZ +jULnAdnp1oP+Q8uTttKHDEzT2SVtNmfVGjgE=
Received: by 10.42.96.68 with SMTP id i4mr1316188icn.354.1315601618012; Fri, 09 Sep 2011 13:53:38 -0700 (PDT)
Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id d8sm9858365ibl.1.2011.09.09.13.53.36 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Sep 2011 13:53:37 -0700 (PDT)
Message-ID: <4E6A7D47.5020201@gmail.com>
Date: Fri, 09 Sep 2011 13:55:35 -0700
From: Dzonatas Sol <dzonatas@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11
MIME-Version: 1.0
To: rtcweb@ietf.org
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>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233D45F96@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
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 20:51:48 -0000

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