Re: [rtcweb] No Interim on SDES at this juncture

"Parthasarathi R" <partha@parthasarathi.co.in> Thu, 27 June 2013 17:04 UTC

Return-Path: <partha@parthasarathi.co.in>
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 70DC721F9E77 for <rtcweb@ietfa.amsl.com>; Thu, 27 Jun 2013 10:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.666
X-Spam-Level:
X-Spam-Status: No, score=-0.666 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_111=0.6]
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 hzjZ3WzQUYm1 for <rtcweb@ietfa.amsl.com>; Thu, 27 Jun 2013 10:04:54 -0700 (PDT)
Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.230]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBEE21F9E4D for <rtcweb@ietf.org>; Thu, 27 Jun 2013 10:04:54 -0700 (PDT)
Received: from userPC (unknown [122.178.223.166]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id E13F7190810D; Thu, 27 Jun 2013 16:56:10 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1372352174; bh=T7lCRsysuAhPPF45eqcjQmStI2Og8B0Cqxaq3Xw9LPc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=UPCmpXCtLi8+e9APU9tNTm3KlWsDFdFeUIVnhsh47yxLiDrw8tuEcwQKw68ZaM2Ph awtgKtEsTdcEmDP5Uzu03Wlip3HBY7+5MYtA53hnHqpSNAA+5BIBBGkx1GizakXxyJ fHmUY832CINAhlINBjZ9upVP3c6MKnPPB4ZpG/90=
From: "Parthasarathi R" <partha@parthasarathi.co.in>
To: "'Dan Wing'" <dwing@cisco.com>, "'Hadriel Kaplan'" <hadriel.kaplan@oracle.com>
References: <CA+9kkMDnjCNXGV0GU7x6gbbZMf4WiEuVvCRY8_Fix5tmdOB-Kg@mail.gmail.com> <AD220324-EEE7-4800-8512-FD7BADA9EC34@oracle.com> <CA+9kkMDY2Z_5_1uYJ1K_ZmrJB2a1-RE7V3aPqNHQg82DyagjCg@mail.gmail.com> <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <AE1A6B5FD507DC4FB3C5166F3A05A4841A2C78AD@TK5EX14MBXC273.redmond.corp.microsoft.com> <CAL02cgTFSbYSX7v3q37tsjzaPMshyyBroGWr=qmy-HGm82GJFg@mail.gmail.com> <AE1A6B5FD507DC4FB3C5166F3A05A4841A2C7EF8@TK5EX14MBXC273.redmond.corp.microsoft.com> <CAL02cgQMkHu-NqEeScT2ObfknJ+3OjXi7Y=7rUJtqeu3CbewMQ@mail.gmail.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <CAL02cgT3KEb0VB9kz=QCe7Mt3oj5tZvZouFe5-Uy90Cmm0H0dQ@mail.gmail.com> <30761469-F5CC-4858-8D40-4632A7D5A682@oracle.com> <CAL02cgSS1e5zH2YRh4uTb8qxXF5Ng5y8RxRw-bGP5xmQLkiQ+Q@mail.gmail.com> <529DCF4E-2A8B-475F-8CCE-7E2ABC72EFB1@oracle.com> <2C6DDF0C-201D-4CA3-8EB0-F14B! 8A2D5758@cisco.com> < CA2956C0-56B7-47E9-9EF4-9D639F8B8AD6@oracle.com> <12C17BE5-2302-48E9-A745-5B7265E83E8E@cisco.com>
In-Reply-To: <12C17BE5-2302-48E9-A745-5B7265E83E8E@cisco.com>
Date: Thu, 27 Jun 2013 22:26:03 +0530
Message-ID: <012d01ce7357$39226ef0$ab674cd0$@co.in>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac5uqSwtMb2RvJARTOiy4gR3UHmvDQEqYinw
Content-Language: en-us
X-CTCH-RefID: str=0001.0A0C0202.51CC6EAE.0154, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules:
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: partha@parthasarathi.co.in
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-BlueWhiteFlag: 0
X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] No Interim on SDES at this juncture
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: Thu, 27 Jun 2013 17:04:58 -0000

Dan,

I'm wondering whether any identity is mandatory all for WebRTC session. I'm
asking this query as lot of WebRTC demo works well without any identity. For
example: it is possible to pass URL like
https://apprtc.appspot.com/?r=06095338 and ask the participant to join the
session.

Thanks
Partha


> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Dan Wing
> Sent: Friday, June 21, 2013 11:30 PM
> To: Hadriel Kaplan
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] No Interim on SDES at this juncture
> 
> 
> On Jun 21, 2013, at 10:14 AM, Hadriel Kaplan
> <hadriel.kaplan@oracle.com>; wrote:
> 
> >
> > On Jun 21, 2013, at 12:45 PM, Dan Wing <dwing@cisco.com>; wrote:
> >
> >>> We've talked about that one before I think.  If jQuery is out to
> get you, it's game over.  It's essentially equivalent to a malicious
> web-server, except of course that the operator of the web-server isn't
> intending to be malicious (which is an important distinction).  But
> again, not only does jQuery have access to information such as who
> you're talking to and when, it can also redirect your media to a
> gateway of its choosing to terminate the DTLS-SRTP and record it, by
> fiddling with the JSON/SDP stuff.
> 
> >>
> >> For the attacker to succeed with the redirection of DTLS-SRTP to a
> server it controls, the attacker would also need to modify the SDP's
> a=fingerprint line which is as  trivial as the attacker's other SDP
> modifications.  To prevent the attacker from succeeding with such
> modification, we need cryptographic identity (to protect the
> From/To/Date/a=fingerprint and other fields), and need the browser (not
> JS) to verify the identity using an external service (e.g., local disk,
> IdP separate from the web server providing us the (compromised) JS and
> the SDP).  While it is true that today we don't have a way today to
> provide that cryptographic identity (RFC4474 does not work, draft-wing-
> rtcweb-identity-media written by me and Hadriel was met with silence)
> DTLS-SRTP creates the foundation to build cryptographic identity which
> can be verified by the browser itself.  Such cryptographic identity
> protects from this specific attack, and DTLS-SRTP protects from other
> attacks.
> >
> > I agree - when we have such a thing, using DTLS-SRTP will have much
> more meaning.  But (1) there is no such thing yet, and (2) it won't
> make DTLS-SRTP nor DTLS-EKT any stronger than SDES for the SIP-gateway
> scenarios we're talking about, since the DTLS isn't going end-to-end.
> I.e., none of the calls would successfully authenticate using such an
> out-of-band mechanism, even the good ones.
> >
> > [note though I'm not saying DTLS-SRTP is useless today - quite the
> contrary, I hummed in favor of making it MTI back when that was
> decided, and I still think it should be MTI]
> 
> Will the existence of SDES prevent WebRTC from building this more
> secure system with strong identity?  That is, when we add cryptographic
> identity will that be effective to prevent a bid-down attack from DTLS-
> SRTP to SDES?  I am thinking right now that when we add identity we can
> prevent that bid-down, so at that time SDES could become a proper
> second-class citizen.
> 
> -d
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb