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

Paul Kyzivat <pkyzivat@alum.mit.edu> Sun, 11 September 2011 01:42 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 6E2A821F8476 for <rtcweb@ietfa.amsl.com>; Sat, 10 Sep 2011 18:42:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.526
X-Spam-Level:
X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599]
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 X-BVsjwZmXNl for <rtcweb@ietfa.amsl.com>; Sat, 10 Sep 2011 18:42:11 -0700 (PDT)
Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 73D7A21F8472 for <rtcweb@ietf.org>; Sat, 10 Sep 2011 18:42:11 -0700 (PDT)
Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta06.westchester.pa.mail.comcast.net with comcast id XDex1h0011HzFnQ56DkBk9; Sun, 11 Sep 2011 01:44:11 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta14.westchester.pa.mail.comcast.net with comcast id XDk91h01j0tdiYw3aDkAee; Sun, 11 Sep 2011 01:44:11 +0000
Message-ID: <4E6C1267.3030100@alum.mit.edu>
Date: Sat, 10 Sep 2011 21:44:07 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <A444A0F8084434499206E78C106220CA0B00FDB08B@MCHP058A.global-ad.net> <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> <4E6A81EC.3080002@jesup.org>, <4E6AE22A.2070106@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7C5@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233C3B7C5@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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: Sun, 11 Sep 2011 01:42:12 -0000

On 9/10/11 8:16 PM, Christer Holmberg wrote:
> Hi,
>
>> This isn't really an rtcweb issue - its a secure media O/A issue.
>
> Well, it depends. If you are supposed to be able to provide different alternatives (SRTP vs RTP and AVPF vs AVP) simultanously, it might have impact on the browser requirement, and the browser/app API.

I didn't mean it had no impact on rtcweb. Only that the O/A issues are 
not unique to rtcweb.

>> The exact same thing could arise if we had somebody with an urgent
>> desire to do secure media with fallback to insecure media in SIP.
>> All the arguments against capneg would be exactly the same.
>>
>> The problem is that people aren't finding capneg a usable solution to
>> this problem, just the way that people didn't find SDPng a solution to
>> the inadequacies of SDP.
>>
>> While it is possible for rtcweb to adopt its own solution to the
>> problem, that only solves half the problem. And it then creates an
>> interop problem with SIP.
>
> A send-a-new-offer-if-the-first-offers-fails mechanism would be backward compatible - assuming the offerer can guess why the first offer failed.

It *might* work in some cases, but it would be iffy.
If the connection is being federated via SIP, I don't know if the intent 
is that both O/As be done in the same INVITE or int separate INVITEs. 
Each has its own limitations:

If done in a single INVITE, its quite possible that the INVITE with the 
first offer will be rejected entirely, without giving chance for a 2nd 
INVITE. If done as separate INVITEs, there is chance that they might not 
go to the same destination. At the least, that could lead to extended 
setup times.

And, IIRC, that approach was discussed before going with the capneg, and 
was rejected. So that approach *may* violate some RFC, though I don't 
know which one.

	Thanks,
	Paul

> Also, using the AVP and RTP profiles, together with attributes that specifies the AVPF and SRTP stuff would also work. Of course, it goes against the current AVPF and SRTP specifications, and since current legacy deployments would not understand such attributes, they would always end up using AVP and RTP.
>
> Regards,
>
> Christer
>
>
> On 9/9/11 5:15 PM, Randell Jesup wrote:
>> On 9/9/2011 3:23 PM, Alan Johnston wrote:
>>> Ekr is correct. If we allow RTP, which I think is a mistake, then
>>> there is always a downgrade attack.
>>
>> Yes, that's true. The same issue was involved in the best-effort-srtp
>> draft, which unfortunately
>> was dropped because CapNeg would "solve" it. (For historical note, it's
>> still not "solved"
>> because CapNeg support is>>>>  more complex than best-effort-srtp and
>> not generally deployed,
>> and I doubt ever will be ala SDPng (though I'm not close to status on
>> CapNeg.)
>>
>> Hmmm. A real downgrade attack requires that the signalling be
>> compromised. I wonder if there
>> are characteristics of a webrtc transaction that could help avoid this
>> sort of attack (for example,
>> a secondary way out-of-scope here for the app to know ahead of time if
>> the target will need to
>> be downgraded). Or some way for the service to vouch for the downgrade
>> (i.e. wasn't a MITM).
>> You have to trust the service, but in this case you're doing so to this
>> degree anyways.
>>
>>> 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.
>>
>> There is another option. I talked about services that wanted to support
>> PSTN could decide if they
>> were willing to support a downgrade. The application could know it's
>> calling a PSTN gateway and
>> if it does know that, avoid a media gateway by not offering encrypted
>> media.
>>
>> I see a significant use-case for some services will be calling PSTN
>> numbers and services, much
>> as it is now for VoIP.
>> Yes, a bunch of new non-legacy services wouldn't use/want it. But the
>> app for a PSTN-using service
>> could specifically allow it.
>>
>> So the question comes down to what's the advantage to using unencrypted
>> RTP?
>> 1) No media gateway needed. This is the big one. Saves on $$$, saves on
>> delay (sometimes a lot),
>> may save on complexity in a PBX type of situation.
>> But is there an issue due to ICE requirements? If those can't be turned
>> off safely too, that kills this
>> whole discussion I think.
>> 2) Debug/etc tools work better with RTP. Not important.
>> 3) May simplify/improve some E911 cases. Might be important; likely not.
>>
>> So, effectively it comes down to "is advantage 1 worth the
>> complexity/risk?" Anyone want to defend that
>> case?
>>
>>> - Alan -
>>>
>>> On Fri, Sep 9, 2011 at 1:35 PM, Eric Rescorla<ekr@rtfm.com>  wrote:
>>>> 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