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

Randell Jesup <randell-ietf@jesup.org> Fri, 09 September 2011 21:16 UTC

Return-Path: <randell-ietf@jesup.org>
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 609FC21F86A1 for <rtcweb@ietfa.amsl.com>; Fri, 9 Sep 2011 14:16:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 J55aOCgCAsk9 for <rtcweb@ietfa.amsl.com>; Fri, 9 Sep 2011 14:16:44 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 68DF121F8569 for <rtcweb@ietf.org>; Fri, 9 Sep 2011 14:16:28 -0700 (PDT)
Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1R28Su-0002gZ-HJ for rtcweb@ietf.org; Fri, 09 Sep 2011 16:18:24 -0500
Message-ID: <4E6A81EC.3080002@jesup.org>
Date: Fri, 09 Sep 2011 17:15:24 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <A444A0F8084434499206E78C106220CA0B00FDB08B@MCHP058A.global-ad.net> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <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>
In-Reply-To: <CAKhHsXFdU1ZaKQF8hbsOxwTS-_RfmFqQhgzGe=K4mRp+wz+_nQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
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:16:45 -0000

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
>>

-- 
Randell Jesup
randell-ietf@jesup.org