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

Dzonatas Sol <dzonatas@gmail.com> Fri, 09 September 2011 19:50 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 0C34E21F87FC for <rtcweb@ietfa.amsl.com>; Fri, 9 Sep 2011 12:50:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.944
X-Spam-Level:
X-Spam-Status: No, score=-3.944 tagged_above=-999 required=5 tests=[AWL=-0.345, 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 1+2KAlQPqJrJ for <rtcweb@ietfa.amsl.com>; Fri, 9 Sep 2011 12:50:10 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 22C8B21F873A for <rtcweb@ietf.org>; Fri, 9 Sep 2011 12:50:10 -0700 (PDT)
Received: by yie12 with SMTP id 12so610398yie.31 for <rtcweb@ietf.org>; Fri, 09 Sep 2011 12:52:03 -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=Z2HQYqHxtJmdtXlQQXNw7wElsI0Zcb/ecCHrtewTUM0=; b=jLZ6T5tgrTDRO6Gxx1iOaJ8bsbHktmmILLg9+ddXP/InYucm6GE6BLjrqII0c/KKoe y9a1j5Nvhgq8gWMAPUKEczvMnuFz5DeQwq5nHfHUrwkuQyOD1ZK7CaBv6sgNE3flSirM njMSluR0pronJtXIeF8R0l8Ch2tQfidMKngkU=
Received: by 10.42.152.199 with SMTP id j7mr1323308icw.417.1315597923328; Fri, 09 Sep 2011 12:52:03 -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 df21sm9362752ibb.9.2011.09.09.12.52.02 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Sep 2011 12:52:02 -0700 (PDT)
Message-ID: <4E6A6ED9.4010306@gmail.com>
Date: Fri, 09 Sep 2011 12:54:01 -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> <CAD5OKxtCMXzWLg40wV3teyh0TdiD1Xv4taW+BSguoDpAE46oJA@mail.gmail.com>
In-Reply-To: <CAD5OKxtCMXzWLg40wV3teyh0TdiD1Xv4taW+BSguoDpAE46oJA@mail.gmail.com>
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 19:50:11 -0000

On 09/09/2011 12:39 PM, Roman Shpount wrote:
> I think RTP vs SRTP should be handled similarly to HTTP vs HTTPS.

Then that would be the same footsteps as HTTPS, and many of us silently 
do not want that standardized again.

We want the stateful layer, and all routes HTTPS ends that state ("this 
part is done" despite bis).


> If the current session is secure (started by HTTPS) only secure media 
> should be allowed, or unsecure connections should only be allowed 
> after the user consent.

That's like one-way street that wouldn't support "third-party" (use-cases).

> If the session is started by HTTP, unsecure media should be allowed 
> since all the signaling is insecure in the first place.

We can just use OPTIONS here, so this path is not an "attack".

> Please keep in mind that secure media is not limited to SRTP. RTP over 
> DTLS is as or more secure then SRTP.
> _____________
> Roman Shpount
>
>
> On Fri, Sep 9, 2011 at 3:23 PM, Alan Johnston 
> <alan.b.johnston@gmail.com <mailto:alan.b.johnston@gmail.com>> wrote:
>
>     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
>     <mailto:ekr@rtfm.com>> wrote:
>     > On Fri, Sep 9, 2011 at 11:11 AM, Matthew Kaufman
>     > <matthew.kaufman@skype.net <mailto: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 <mailto: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