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

Roman Shpount <roman@telurix.com> Fri, 09 September 2011 19:37 UTC

Return-Path: <roman@telurix.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 200FE21F86C1 for <rtcweb@ietfa.amsl.com>; Fri, 9 Sep 2011 12:37:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.768
X-Spam-Level:
X-Spam-Status: No, score=-2.768 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Nhc6eMexccTL for <rtcweb@ietfa.amsl.com>; Fri, 9 Sep 2011 12:37:55 -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 5AC0321F86A6 for <rtcweb@ietf.org>; Fri, 9 Sep 2011 12:37:55 -0700 (PDT)
Received: by yie12 with SMTP id 12so600159yie.31 for <rtcweb@ietf.org>; Fri, 09 Sep 2011 12:39:51 -0700 (PDT)
Received: by 10.90.232.12 with SMTP id e12mr2125976agh.114.1315597190824; Fri, 09 Sep 2011 12:39:50 -0700 (PDT)
Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by mx.google.com with ESMTPS id b4sm2603054ank.3.2011.09.09.12.39.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Sep 2011 12:39:50 -0700 (PDT)
Received: by gxk9 with SMTP id 9so1570908gxk.40 for <rtcweb@ietf.org>; Fri, 09 Sep 2011 12:39:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.8.36 with SMTP id o4mr404878pba.255.1315597186211; Fri, 09 Sep 2011 12:39:46 -0700 (PDT)
Received: by 10.68.43.136 with HTTP; Fri, 9 Sep 2011 12:39:46 -0700 (PDT)
In-Reply-To: <CAKhHsXFdU1ZaKQF8hbsOxwTS-_RfmFqQhgzGe=K4mRp+wz+_nQ@mail.gmail.com>
References: <A444A0F8084434499206E78C106220CA0B00FDB08B@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <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>
Date: Fri, 9 Sep 2011 15:39:46 -0400
Message-ID: <CAD5OKxtCMXzWLg40wV3teyh0TdiD1Xv4taW+BSguoDpAE46oJA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Alan Johnston <alan.b.johnston@gmail.com>
Content-Type: multipart/alternative; boundary=bcaec52157b3f3a14604ac875661
Cc: Randell Jesup <randell-ietf@jesup.org>, Jonathan Lennox <jonathan@vidyo.com>, "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: Fri, 09 Sep 2011 19:37:56 -0000

I think RTP vs SRTP should be handled similarly to HTTP vs HTTPS. 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. If the session is started by HTTP, unsecure media should be allowed
since all the signaling is insecure in the first place. 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>wrote;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> 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
>