From nobody Mon Jul 6 11:23:34 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74B71B2B99 for ; Mon, 6 Jul 2015 11:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xx5PXe1iWwTE for ; Mon, 6 Jul 2015 11:23:31 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD511ACD78 for ; Mon, 6 Jul 2015 11:23:30 -0700 (PDT) X-AuditID: c1b4fb2d-f79176d00000321c-d7-559ac7a04317 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B2.56.12828.0A7CA955; Mon, 6 Jul 2015 20:23:29 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.3.210.2; Mon, 6 Jul 2015 20:23:28 +0200 Message-ID: <559AC79F.7010403@ericsson.com> Date: Mon, 6 Jul 2015 20:23:27 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: References: <20150706182043.31824.87483.idtracker@ietfa.amsl.com> In-Reply-To: <20150706182043.31824.87483.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150706182043.31824.87483.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------030209010303050501090103" X-Brightmail-Tracker: H4sIAAAAAAAAA2WSfSxVYRzH99x77r3HjXlc5IeGWVryVrLGkrr1TymSKLRVdzlDcdk9usuy JWux25J37mXF8hJaJGGMeUmxVljet0LXZJVkrN1GyjmPLav/Pr/f893z/T7fc2ih7KPIho5R JjIqpSLWUSyltGG/kt1KX+lCd9cMGXvXlBagQ+hoWdlPQRCKkPpGMrExakbl4XdRGt2e/luU 0O96rWIqX5KCZndokBEN2Asa08rFhLfCwIfadZbSMtyDoLU+V0SGCgQN5StCTmWCXWDt/iKl QTRN4e2w2Kzm1mLsDeOGm/xFljgC8vRPKCI3gz7tDM8W2BwMA1kSjs3xWcjvrUYcy7AcMt5O ijg2woeh+/kbigQKgDFDpYCzEuIg6BgNI3IXSElNF2UirNvkoPur4tbC9UDaB/2IsD00zRcL CSfC6sic+P99BoLmcjMd/+A6BCkLt3gRV1F2m05IDvIE695DYjLkItA3FQqIaicUVg0gctCI oORWN0WGHAT3RudFJJ8z1LZ4/Ostxg7webFKwuktcC+C/rUiiY5vKQTSMpcQcbCAb8PTQsI2 UDTRyedD2A4ML/V8CowxrGUPUKQXOfS+qOf13IeayBvbuGdhC4zMeOr4Kp3g+7tOCdkfgIbZ yQ12ha9ZRRsv84X3PV2SzV2XIPtqZMkyLBsX5bnXnVHFXGLZeKW7kkmsR+s/ZWfDilszqvki 70KYRo7GJlOPtKEykULNJsV1IVuacrQyKXymDJXhKEUic4VhEhjVBdXVWIbtQgLayCYFxd7w C273qXsccMRUsNjaHepfm0rfqTxoJBksCd+3Tebc8bo1HP1wO2Vd7HB5Uh13JjJtOUkTZ9fX dNI/0GBr1RYSH7WErkfcPu1d5mXhFxNyLHx8ON3arHpWft4puUUTeK5jOtjBKc8mbP/gidXh HMnTgtm7cw9NfaS65fxp/afjjhQbrdizS6hiFX8AAQGIIHUDAAA= Archived-At: Subject: [Perc] Fwd: New Version Notification for draft-westerlund-perc-webrtc-use-case-00.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 18:23:33 -0000 --------------030209010303050501090103 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit WG, John and I have written an draft that discusses some of the challenges of PERC when using WebRTC endpoints. We have requested agenda time, so please review and prepare. If you have questions, don't hesitate to send comments and question to us and the list. Cheers Magnus Westerlund --------------030209010303050501090103 Content-Type: message/rfc822; name="New Version Notification for draft-westerlund-perc-webrtc-use-case-00_txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="New Version Notification for draft-westerlund-perc-webrtc-us"; filename*1="e-case-00_txt.eml" Received: from sesbmg12.ericsson.net (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.55) with Microsoft SMTP Server id 14.3.210.2; Mon, 6 Jul 2015 20:20:57 +0200 X-AuditID: c1b4fb28-f79de6d0000022d7-43-559ac7081ec6 Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by sesbmg12.ericsson.net (Symantec Mail Security) with SMTP id AB.CD.08919.907CA955; Mon, 6 Jul 2015 20:20:57 +0200 (CEST) Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62BBC1B2C8C; Mon, 6 Jul 2015 11:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klvwP8-nlWrM; Mon, 6 Jul 2015 11:20:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2B31B2EF1; Mon, 6 Jul 2015 11:20:43 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: To: John Mattsson , John Mattsson , Magnus Westerlund , Magnus Westerlund Subject: New Version Notification for draft-westerlund-perc-webrtc-use-case-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706182043.31824.87483.idtracker@ietfa.amsl.com> Date: Mon, 6 Jul 2015 11:20:43 -0700 X-Brightmail-Tracker: H4sIAAAAAAAAA11Ta1BUZRje7+y2nl320+PuAq9bpK1hVrAE+sOmplGnMX6Vg2yNWZMLHHZX 9sLs2cVlmiakJi6hICQuCxlDFBcvK3iBcSViB/AyOTEYQQyRWklSgoqJQkrnsrArf86c8zzf +zzP+573I8XKE3INSbudtMNmsGilcolkZW9cvOycV/9S8dDqDRer/MSGft8osZFInvl3QLoV vSt/NYO2mHNoR8JrO+WmyhP1kuyRCPfl3xLyUIGsGMlIoNZDeYdXLLxHQd+oT1qM5KSSOkBA iz9PInxUIig/OkEIp9aCp6kPCcRpBF/+fGxJsARB3UMf4k5hajlcqPqDLSdJMfU8+M4kcLCY WgltN2t4Oyn1NBwer+SF1FQfgjuffMs7qKhUKCibQoKbGiYGrgbzaaB6uEvKvSO2+H7v7/x5 iqLgUXmfRPDdBOe7W/nzEioWCvcNS8qQyhsWyRuK5A2LVIvEzSiSoZk0qzExSUc7zOkMY7fp bLSzFbGz7jo5u7Ydld7bFEAUibQKfKWxSq98wpDD5FoDyEgSWg1GIpFIqUqzZ+SaDIzpA8aV ZjUzjNlu00bixCNevXLpAudwWWhGq8aGHhbGC3Cay5LFCu3rZdGQkI3ezVhoJ/vjA+hJUqKN xnLFXr2SMhqcdBZNZ9MOQS+APiZJqrakbBBpJDa7jdbGCJmiHLSRdmeaLaxEeCzAhzn/5eG0 kCwau7tZhgpn+HAxmMQs8ZhieD6ClAVQOqnQrhCslUy2wcqYjeG2aryLb3ueEixVOOU7FlXM o7zdClzAzWJBJWR1EVUg8uynvxwlyEL/FfbZenl6BCn5voWn5incqWOLI7lik8v2ePOaaDzJ paDCWD6IJgofq2aJZWEEl4WVy49fJBeKM38f+1GMRiW0rmB/jNXsDLYX5MdRAcHuD+CSL7jJ m23ORcNR4SIuliLICMVKvIcDI4IgPxrAu3vCJEJRkr5B7AU5L4X+u5+LoTH/hhhKi85K4dDM hAzaKz+Tg2+uMAJauh+o2EvkXQWPPAeeAd9Y7bMwV1oTC57Ts2vA49/zHPzUMBcHF/6rj4fu 1rZEGDk4lASHro2tg4mrFS9DxcNbr8CQp/l1aD3VsgWK6m5sgeqWjmQYPT6ZDJ7jdW/BX+3N 22CieWwb9PzZkQrXSr7Sw+yd629DY1PnO+PsnhChPXEaFo9CjRvi+T0JUvN74tDxexJEg3ti 1fF7EgRD09Dkoe2y2/mRXpfpbkpvUXX6ize7Z2an3hs4MjK98/bg5vum791Zby4ZaDp1r+Kf 7YrpvXXD5qwpUWb6zN/1PZ359gzi65T9Datlg5fOTBZ/dH1jrqhkfVtVqn/d+/6lW3dkNmx+ 49KPXb+ei9s/7VfnnYScD4smrRWxD0qid0BSza4fdLcOrtFKGJMh8QWxgzH8D7TWY5/GBQAA Return-Path: internet-drafts@ietf.org X-MS-Exchange-Organization-AuthSource: ESESSHC012.ericsson.se X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 MIME-Version: 1.0 A new version of I-D, draft-westerlund-perc-webrtc-use-case-00.txt has been successfully submitted by Magnus Westerlund and posted to the IETF repository. Name: draft-westerlund-perc-webrtc-use-case Revision: 00 Title: WebRTC Use Case and Framework for Privacy Enhanced RTP Conferencing (PERC) Document date: 2015-07-06 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-westerlund-perc-webrtc-use-case-00.txt Status: https://datatracker.ietf.org/doc/draft-westerlund-perc-webrtc-use-case/ Htmlized: https://tools.ietf.org/html/draft-westerlund-perc-webrtc-use-case-00 Abstract: The work so far on Privacy Enhanced RTP Conferencing, which allows end-to-end security also in centralized switch RTP based conference, has not considered WebRTC in detail. This document looks at the use case of WebRTC based endpoints, it also considers implications of using external providers for both conference applications and centralized media distribution devices. From this a number of challenges have been determined, and requirements are derived from these. Finally the draft presents some straw man for possible solutions. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------030209010303050501090103-- From nobody Mon Jul 6 13:09:57 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D031B31A0 for ; Mon, 6 Jul 2015 13:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bElZ0IDp4bL for ; Mon, 6 Jul 2015 13:09:54 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9AFB1B319D for ; Mon, 6 Jul 2015 13:09:54 -0700 (PDT) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.14.9/8.14.9) with ESMTP id t66K9qVK008356 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 6 Jul 2015 16:09:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1436213393; bh=He8XiMrbJz9PhkUirCxMIO5/JiDDuKjtG1028UkArZM=; h=From:To:Subject:Date:Reply-To; b=qrSpROYeznyN8eHVebTsJn2I1ELhNvLbW3Gwd4DJwSUWMX3ZPsigB8nW0QtdD7WUJ EJXyzbcloeTInuySo+nLGM5Z7hIcFXmEacz6/pciuArIE4YT123tr3V07GjIenH5vb A6/84Ty39dSZXKltQtzTnuqAATDrGeBL5Jlu3hV0= From: "Paul E. Jones" To: perc@ietf.org Date: Mon, 06 Jul 2015 20:09:54 +0000 Message-Id: User-Agent: eM_Client/6.0.22344.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Perc] Fw: I-D Action: draft-jones-perc-private-media-reqts-00.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 20:09:56 -0000 Folks, A "new" version of the requirements document is now posted. Paul ------ Forwarded Message ------ From: internet-drafts@ietf.org To: i-d-announce@ietf.org Sent: 7/6/2015 4:06:13 PM Subject: I-D Action: draft-jones-perc-private-media-reqts-00.txt A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : Private Media Requirements in Privacy Enhanced= =20 RTP Conferencing Authors : Paul E. Jones Nermeen Ismail David Benham Nathan Buckles John Mattsson Richard Barnes Filename : draft-jones-perc-private-media-reqts-00.txt Pages : 19 Date : 2015-07-06 Abstract: This document specifies the requirements for ensuring the privacy and integrity of real-time transport protocol (RTP) media flows between two or more endpoints communicating through one or more centrally located media distribution devices (MDDs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-jones-perc-private-media-reqts/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-jones-perc-private-media-reqts-00 Please note that it may take a couple of minutes from the time of=20 submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Jul 6 13:10:52 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E679F1B319D for ; Mon, 6 Jul 2015 13:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xh5bSrh-jYb2 for ; Mon, 6 Jul 2015 13:10:49 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56BB01ACDF0 for ; Mon, 6 Jul 2015 13:10:49 -0700 (PDT) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.14.9/8.14.9) with ESMTP id t66KAmUZ008435 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 6 Jul 2015 16:10:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1436213448; bh=0SDBX1OTBPbFf2AdZZuB/Np1Y75NUajRok10fPx5RQ0=; h=From:To:Subject:Date:Reply-To; b=pVvMAqqUTYBI/Epag7ZJQQcCp5sqAa6j2GgMsJoKO6C/fO8Q69Vb3C8MFNbWeqUsq 7JToG7W/sNm8L9AQUDqjO2HjjjloByaQK/Bv3xcDff1+0NiTobX5s/z/pfQm9wds68 rKVBv7ZdCe0LbJ1COWlMuK9fN2XacqkLX3/jvEiQ= From: "Paul E. Jones" To: "perc@ietf.org" Date: Mon, 06 Jul 2015 20:10:51 +0000 Message-Id: User-Agent: eM_Client/6.0.22344.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Perc] Fw: I-D Action: draft-jones-perc-private-media-framework-00.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 20:10:51 -0000 Folks, We have posted an updated version of the solution framework draft for=20 consideration in the PERC meeting. Paul ------ Forwarded Message ------ From: internet-drafts@ietf.org To: i-d-announce@ietf.org Sent: 7/6/2015 4:08:34 PM Subject: I-D Action: draft-jones-perc-private-media-framework-00.txt A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : A Solution Framework for Private Media in=20 Privacy Enhanced RTP Conferencing Authors : Paul E. Jones Nermeen Ismail David Benham Filename : draft-jones-perc-private-media-framework-00.txt Pages : 18 Date : 2015-07-06 Abstract: This document describes a solution framework for ensuring that media confidentiality and integrity are maintained end-to-end within the context of a switched conferencing environment where media distribution devices are not trusted with the end-to-end media encryption keys. The solution aims to build upon existing security mechanisms defined for the real-time transport protocol (RTP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-jones-perc-private-media-framework/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-jones-perc-private-media-framework-00 Please note that it may take a couple of minutes from the time of=20 submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Sat Jul 11 17:06:06 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DAE1A00F7 for ; Sat, 11 Jul 2015 17:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_kapBh73ONB for ; Sat, 11 Jul 2015 17:06:03 -0700 (PDT) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC8DC1A00F5 for ; Sat, 11 Jul 2015 17:05:58 -0700 (PDT) Received: by lagx9 with SMTP id x9so283172183lag.1 for ; Sat, 11 Jul 2015 17:05:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=dPU00AxfprDs57bJFscSapuNRjbfhYQlcLBYI3gbNl4=; b=KFIQmT3RHxzvRZF8rFO9xuI1zjdHs93bpZGZ1N7d4bMJBGy0jfvk1dPBJ4fqtayXjG rbm2I0ydnpi9Zd6TznewPsGtxFLQMVQG+ElvKH5O+d7osryot3sBg6UBbkWbrcRz6eX7 kQH+iY9i6lFGVQ2HuHlC/QZVZKnQLrsDUWLGS9FZ6cPH60ONaAYcHoVWk+++SvsnByvC 1Ns/n9ckrEMGW2FWF1M8Q70QAONspL4FZRjAihNIWhVMXTyRoUJbzTqF9SC1uGc2MuGo pB9OTQihkeXjl2Ikn3qug3D878WfZEr+i3Ut994K4DHFY3NtDdK7bEOTTTLchWF4oaq+ PoaA== X-Gm-Message-State: ALoCoQn0VAhyKrMn2aSOF2/bLUjB6aRVTSbA2LzZu8uwjfDeerR1rnhPhKItPurGC00Vcmg/nmQ5 X-Received: by 10.152.30.4 with SMTP id o4mr25176514lah.74.1436659557141; Sat, 11 Jul 2015 17:05:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.99.103 with HTTP; Sat, 11 Jul 2015 17:05:17 -0700 (PDT) From: Eric Rescorla Date: Sat, 11 Jul 2015 20:05:17 -0400 Message-ID: To: perc@ietf.org Content-Type: multipart/alternative; boundary=089e0160b436911d9b051aa25e29 Archived-At: Subject: [Perc] Comments on draft-westerlund-perc-webrtc-use-case-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2015 00:06:04 -0000 --089e0160b436911d9b051aa25e29 Content-Type: text/plain; charset=UTF-8 I have reviewed draft-westerlund-perc-webrtc-use-case-00, but I don't think it meets either the security requirements listed in the document or the larger requirement to protect the user from the conference bridge. Section 4.2. says 4.2. Dealing with JavaScript related Attacks The JavaScript code run in the browser is a potential attack vector. Using various attacks, including cross-site scripting, the JavaScript can be compromised and perform the actions an attacker dictates. Even if the JS running in the browser is malicious it must not be able to compromise the security of the conference, only perform denial of service attacks such as preventing the user from joining the conference. However, I don't believe that the described system actually provides this property: while the EKT key may be available only to the browser (and this is actually fairly unclear given the sketchy description here), it's not bound to any particular PeerConection so nothing stops the JS from attaching it to one (or more PCs, including those which are actually connected to itself) and therefore capturing the user's traffic. Compare this to WebRTC with isolated streams and identity, where you know exactly who you are connected to. In addition, because you are sending the keys over an HTTP channel, we have to worry about the HTTP security/logging issues we have with SDES. -Ekr --089e0160b436911d9b051aa25e29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed draft-westerlund-perc-webrtc-use-case= -00, but I don't
think it meets either the security requireme= nts listed in the document
or the larger requirement to protect t= he user from the conference
bridge.

Sect= ion 4.2. says
4.2.=C2=A0 Dealing with JavaScript related Attacks<= /div>

=C2=A0 =C2=A0The JavaScript code run in the browse= r is a potential attack vector.
=C2=A0 =C2=A0Using various attack= s, including cross-site scripting, the JavaScript
=C2=A0 =C2=A0ca= n be compromised and perform the actions an attacker dictates.
= =C2=A0 =C2=A0Even if the JS running in the browser is malicious it must not= be
=C2=A0 =C2=A0able to compromise the security of the conferenc= e, only perform
=C2=A0 =C2=A0denial of service attacks such as pr= eventing the user from joining
=C2=A0 =C2=A0the conference.
=

However, I don't believe that the described system = actually provides
this property: while the EKT key may be availab= le only to the browser
(and this is actually fairly unclear given= the sketchy description
here), it's not bound to any particu= lar PeerConection so nothing stops
the JS from attaching it to on= e (or more PCs, including those which
are actually connected to i= tself) and therefore capturing the user's
traffic. Compare th= is to WebRTC with isolated streams and identity,
where you know e= xactly who you are connected to.

In addition, beca= use you are sending the keys over an HTTP channel,
we have to wor= ry about the HTTP security/logging issues we have with
SDES.

-Ekr
















--089e0160b436911d9b051aa25e29-- From nobody Sun Jul 12 14:37:36 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6C61A1BED for ; Sun, 12 Jul 2015 14:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcrUE5owkWBu for ; Sun, 12 Jul 2015 14:37:34 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E87E1A1B88 for ; Sun, 12 Jul 2015 14:37:33 -0700 (PDT) Received: by wgkl9 with SMTP id l9so12508358wgk.1 for ; Sun, 12 Jul 2015 14:37:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=GPlXBDH/GQKGaWt2IFL57oV9366bkKQT6mjSE3YxUzg=; b=DsI+HlLFRjEwsZ+Cg+Qw2Rub+dHdL4/CoRvmn89IIKnUwzIZoemHkIoN2p/+yNF6ki fQE5OoJ+7g4PWpABgkROp+hMrn9JJMbsobo4U917ZfGYW+1/K0Mg6/BXlUh6WB8rknR+ Tj6xjdySFaFCBInYFYJO2KAY2BG/ms6ipS5eS9/WKh7PPJIA/KyDYwRELMiTEf1HruCi 3C+eg63kcBhCIwar+v79LUMbcQTg56L94pkM3C7whIoiSWgFmw0/maG2nAGw8Dw7xneG 8QGo5RJhuKBSvTwHbk+jQbAB7A48yauBpQOcue3EJ6VQZPwGfAZgeWMw+oXuyK42rHbi t/gQ== X-Gm-Message-State: ALoCoQlypaT+Y2GL1PNW8D1Kh6RnMK6itPLiNNcQZmIZmmuaVIaYH/7l7b8shrEw/DfPHDF3wMyk X-Received: by 10.180.75.78 with SMTP id a14mr17824837wiw.68.1436737052307; Sun, 12 Jul 2015 14:37:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.95.211 with HTTP; Sun, 12 Jul 2015 14:36:52 -0700 (PDT) From: Eric Rescorla Date: Sun, 12 Jul 2015 14:36:52 -0700 Message-ID: To: perc@ietf.org, draft-jones-perc-private-media-reqts@tools.ietf.org Content-Type: multipart/alternative; boundary=f46d0438eb9da38702051ab46999 Archived-At: Subject: [Perc] Review of draft-jones-perc-private-media-reqts-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2015 21:37:35 -0000 --f46d0438eb9da38702051ab46999 Content-Type: text/plain; charset=UTF-8 draft-jones-perc-private-media-reqts-00 I think this document is generally going in the right direction. A few substantive comments below. If you have a github version, I can send you a PR with editorial comments. * I think it would help to be more precise about your threat model and specifically the role of the MDD and Call Processing. Here's how I would phrase things: - PERC provides defense against a passive attacker at either the MDD and the Call Processing System, since they never come in contact with the keys. - PERC prevents active attack by the MDD - PERC allows active attack by the Call Processing System to be detectable to a great extent: - The client knows the identity (i.e., the certificate) of the KMF. If WebRTC identity or a valid certificate is used, then the client can determine whether the CPS has injected itself. - The KMF knows the number of participants in the call, but nothing prevents the CPS from injecting an extra participant since the KMF has no expectation of the caller's identities. All this assumes the DTLS solution in draft-jones-perc-private-media-framework, but since we know that's achievable, it's a good goal to shoot for. Does this sound correct to you. * Section 7.1.2 is confusing when compared to 7.2.3. I think that the issue is that 7.1.2 needs to be rewritten to make clear that the guarantee is that the sending endpoint is part of the group, not that it is a particular endpoint. * The end of Section 6.2 should be rewritten to make clear that while a switching MDD can do bad stuff, this shouldn't lead to compromise of the basic comsec guarantees (i.e., forgery or content disclosure). * Section 7.1.5: the summary here is that addition to the group has to be fast but removal can be slower, right? Including retrospective removal. * Section 7.2.2 You might mention that Tor has bad performance properties here. * Section 7.2.3 It's also probably worth mentioning that EC signatures are starting to be within the plausible performance boundaries. For example you can do about 1000 verifies/sec (and 2000 signs/sec) with ECDSA P-256 on my Mac RetinaBook Pro (OpenSSL). * I am having trouble reading PM-03. Can you restate? --f46d0438eb9da38702051ab46999 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
draft-jones-perc-private-media-reqts-00
I think this document is generally going in the right direction= .

A few substantive comments below. If you have a = github version, I can
send you a PR with editorial comments.

* I think it would help to be more precise about your = threat model
and specifically the role of the MDD and Call Proces= sing. Here's
how I would phrase things:

<= div>- PERC provides defense against a passive attacker at either the MDD
=C2=A0 and the Call Processing System, since they never come in con= tact
=C2=A0 with the keys.

- PERC preven= ts active attack by the MDD

- PERC allows active a= ttack by the Call Processing System to be
=C2=A0 detectable to a = great extent:

=C2=A0 - The client knows the identi= ty (i.e., the certificate) of
=C2=A0 =C2=A0 the KMF. If WebRTC id= entity or a valid certificate is
=C2=A0 =C2=A0 used, then the cli= ent can determine whether the CPS has
=C2=A0 =C2=A0 injected itse= lf.

=C2=A0 - The KMF knows the number of participa= nts in the call, but
=C2=A0 =C2=A0 nothing prevents the CPS from = injecting an extra participant
=C2=A0 =C2=A0 since the KMF has no= expectation of the caller's identities.

All t= his assumes the DTLS solution in
draft-jones-perc-private-media-f= ramework, but since we know that's
achievable, it's a goo= d goal to shoot for.

Does this sound correct to yo= u.


* Section 7.1.2 is confusing whe= n compared to 7.2.3.
I think that the issue is that 7.1.2 needs t= o be rewritten to
make clear that the guarantee is that the sendi= ng endpoint is
part of the group, not that it is a particular end= point.


* The end of Section 6.2 sho= uld be rewritten to make clear that
while a switching MDD can do = bad stuff, this shouldn't lead to
compromise of the basic com= sec guarantees (i.e., forgery or
content disclosure).
<= br>
* Section 7.1.5: the summary here is that addition to the gro= up
has to be fast but removal can be slower, right? Including
retrospective removal.


* Sec= tion 7.2.2 You might mention that Tor has bad performance
propert= ies here.


* Section 7.2.3 It's = also probably worth mentioning that EC
signatures are starting to= be within the plausible performance
boundaries. For example you = can do about 1000 verifies/sec
(and 2000 signs/sec) with ECDSA P-= 256 on my Mac RetinaBook Pro
(OpenSSL).

= * I am having trouble reading PM-03. Can you restate?

<= div>




<= div>




<= div>
=C2=A0=C2=A0


--f46d0438eb9da38702051ab46999-- From nobody Mon Jul 13 22:30:05 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847BD1A0158 for ; Mon, 13 Jul 2015 22:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.112 X-Spam-Level: X-Spam-Status: No, score=-0.112 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFm81pVnJTcO for ; Mon, 13 Jul 2015 22:30:02 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEF731A0130 for ; Mon, 13 Jul 2015 22:30:01 -0700 (PDT) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.14.9/8.14.9) with ESMTP id t6E5TxWL006396 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jul 2015 01:30:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1436851800; bh=ka0FB0YjCWMtc6MrppryaYGsImZgAcqjUCTik35f2bw=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=nxC9aNUIL7QNkzdhOl2otm6FU7X7ejAImqTJN1W4KkjSjLHM8Z5L9KV8QCn1l/IPI nBU8Y2U7BS1bwOoW+10GZ5yzymhmsTZsL7VStaDP1rOz+QjubTuuutyzO7gMV8N46D VFEpd3b88ny7CyrWzHx5Src1Y1UNyIkIzoXVDfpE= From: "Paul E. Jones" To: "Eric Rescorla" , perc@ietf.org, draft-jones-perc-private-media-reqts@tools.ietf.org Date: Tue, 14 Jul 2015 05:30:17 +0000 Message-Id: In-Reply-To: User-Agent: eM_Client/6.0.22344.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB314F15D0-0C3D-4871-B108-CEA88F006FD7" Archived-At: Subject: Re: [Perc] Review of draft-jones-perc-private-media-reqts-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 05:30:04 -0000 --------=_MB314F15D0-0C3D-4871-B108-CEA88F006FD7 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eric, >A few substantive comments below. If you have a github version, I can >send you a PR with editorial comments. I don't, but I can. However, I'll need to do that a couple of weeks=20 following the IETF meeting. But, if you send me comments in any form, I'll take them and incorporate= =20 them. >* I think it would help to be more precise about your threat model >and specifically the role of the MDD and Call Processing. Here's >how I would phrase things: > >- PERC provides defense against a passive attacker at either the MDD > and the Call Processing System, since they never come in contact > with the keys. >- PERC prevents active attack by the MDD > >- PERC allows active attack by the Call Processing System to be > detectable to a great extent: > > - The client knows the identity (i.e., the certificate) of > the KMF. If WebRTC identity or a valid certificate is > used, then the client can determine whether the CPS has > injected itself. This would be true, but that is also true even if the attack is not on=20 the CPS. > - The KMF knows the number of participants in the call, but > nothing prevents the CPS from injecting an extra participant > since the KMF has no expectation of the caller's identities. Insofar as the PERC work goes, I think that is a correct statement. =20 Some might build a KMF that does know endpoints and does have access to= =20 a secure conference roster, but I don't think we want to force those=20 requirements into PERC. >All this assumes the DTLS solution in >draft-jones-perc-private-media-framework, but since we know that's >achievable, it's a good goal to shoot for. > >Does this sound correct to you. Yes, if you can also agree with my small interventions above. >* Section 7.1.2 is confusing when compared to 7.2.3. >I think that the issue is that 7.1.2 needs to be rewritten to >make clear that the guarantee is that the sending endpoint is >part of the group, not that it is a particular endpoint. We might want to know that it is a particular endpoint or even a=20 particular human user, and we get this by checking the client=20 certificate and validating it. However, insofar as this goal goes, I=20 think that was the intent. John Mattsson contributed this one, I think.= =20 If you don't have particular suggestions for wording changes, perhaps=20 he might weigh in? >* The end of Section 6.2 should be rewritten to make clear that >while a switching MDD can do bad stuff, this shouldn't lead to >compromise of the basic comsec guarantees (i.e., forgery or >content disclosure). Are you suggesting we add something else or modify that last paragraph? >* Section 7.1.5: the summary here is that addition to the group >has to be fast but removal can be slower, right? Including >retrospective removal. Re-keying can take time, so I think the intent is to leave it open to=20 implementations whether they want to re-key or not. However, it was=20 stated as a goal to make it possible to re-key the conference on roster=20 changes. >* Section 7.2.2 You might mention that Tor has bad performance >properties here. That's really orthogonal to the security characteristics, which are the=20 focus of that. However, I'm not opposed to saying that, particularly if=20 you think it helps to make a point. What did you have in mind, exactly? >* Section 7.2.3 It's also probably worth mentioning that EC >signatures are starting to be within the plausible performance >boundaries. For example you can do about 1000 verifies/sec >(and 2000 signs/sec) with ECDSA P-256 on my Mac RetinaBook Pro >(OpenSSL). This is a non-goals section. Are you suggesting we re-consider that in=20 light of EC performance? >* I am having trouble reading PM-03. Can you restate? Perhaps you can help with the wording. The intent was the following=20 points: * Replay protection must be enabled at each hop so as to * Ensure that a received packet is intended for the recipient (e.g.,=20 the receiving endpoint is the correct recipient); and * Ensure that the packet is not a duplicated packet. This boils down to: * If Bob receives a packet sent to Carol, Bob should detect it was not= =20 intended for him and discard it * If Bob receives a packet that he has already processed, he will know= =20 to discard it Paul --------=_MB314F15D0-0C3D-4871-B108-CEA88F006FD7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Eric,
 
A few substantive comments below. If you have a github version, I can<= /DIV>
send you a PR with editorial comments.
 
I don't, but I can.  However, I'll need to do that a couple of= weeks following the IETF meeting.
 
But, if you send me comments in any form, I'll take them and incorpora= te them.
 
* I think it would help to be more precise about your threat model
and specifically the role of the MDD and Call Processing. Here's
how I would phrase things:

- PERC provides defense against a passive attacker at either the MDD
  and the Call Processing System, since they never come in contac= t
  with the keys.
- PERC prevents active attack by the MDD

- PERC allows active attack by the Call Processing System to be
  detectable to a great extent:

  - The client knows the identity (i.e., the certificate) of
    the KMF. If WebRTC identity or a valid certificate is
    used, then the client can determine whether the CPS has<= /DIV>
    injected itself.
 
This would be true, but that is also true even if the attack is not= on the CPS.
 
  - The KMF knows the number of participants in the call, but
    nothing prevents the CPS from injecting an extra partici= pant
    since the KMF has no expectation of the caller's identit= ies.
 
Insofar as the PERC work goes, I think that is a correct statemen= t.  Some might build a KMF that does know endpoints and does &nbs= p;have access to a secure conference roster, but I don't think we want to= force those requirements into PERC.
 
 
All this assumes the DTLS solution in
draft-jones-perc-private-media-framework, but since we know that's
achievable, it's a good goal to shoot for.

Does this sound correct to you.
 
Yes, if you can also agree with my small interventions above.

 
* Section 7.1.2 is confusing when compared to 7.2.3.
I think that the issue is that 7.1.2 needs to be rewritten to
make clear that the guarantee is that the sending endpoint is
part of the group, not that it is a particular endpoint.
 
We might want to know that it is a particular endpoint or even a parti= cular human user, and we get this by checking the client certificate= and validating it.  However, insofar as this goal goes, I think that= was the intent.  John Mattsson contributed this one, I think. = If you don't have particular suggestions for wording changes, perhaps he= might weigh in?

 
* The end of Section 6.2 should be rewritten to make clear that
while a switching MDD can do bad stuff, this shouldn't lead to
compromise of the basic comsec guarantees (i.e., forgery or
content disclosure).
 
Are you suggesting we add something else or modify that last paragraph= ?
 
 
* Section 7.1.5: the summary here is that addition to the group
has to be fast but removal can be slower, right? Including
retrospective removal.
 
Re-keying can take time, so I think the intent is to leave it open = to implementations whether they want to re-key or not.  However, it= was stated as a goal to make it possible to re-key the conference on roste= r changes.
 
* Section 7.2.2 You might mention that Tor has bad performance
properties here.
 
That's really orthogonal to the security characteristics, which are= the focus of that. However, I'm not opposed to saying that, particula= rly if you think it helps to make a point.  What did you have in mind,= exactly?
 
 
* Section 7.2.3 It's also probably worth mentioning that EC
signatures are starting to be within the plausible performance
boundaries. For example you can do about 1000 verifies/sec
(and 2000 signs/sec) with ECDSA P-256 on my Mac RetinaBook Pro
(OpenSSL).
 
This is a non-goals section.  Are you suggesting we re-consider= that in light of EC performance?
 
 
* I am having trouble reading PM-03. Can you restate?
 
Perhaps you can help with the wording.  The intent was  the= following points:
* Replay protection must be enabled at each hop so as to
  * Ensure that a received packet is intended for the recipient= (e.g., the receiving endpoint is the correct recipient); and
  * Ensure that the packet is not a duplicated packet.
 
This boils down to:
 * If Bob receives a packet sent to Carol, Bob should detect it= was not intended for him and discard it
 * If Bob receives a packet that he has already processed,= he will know to discard it
 
Paul
 
--------=_MB314F15D0-0C3D-4871-B108-CEA88F006FD7-- From nobody Tue Jul 14 00:36:30 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918271A8F48 for ; Tue, 14 Jul 2015 00:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uVPvFy-sBJ8 for ; Tue, 14 Jul 2015 00:36:27 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 956861A8F46 for ; Tue, 14 Jul 2015 00:36:26 -0700 (PDT) X-AuditID: c1b4fb2d-f79176d00000321c-b7-55a4bbf84888 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 73.45.12828.8FBB4A55; Tue, 14 Jul 2015 09:36:24 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.3.210.2; Tue, 14 Jul 2015 09:36:24 +0200 Message-ID: <55A4BBF7.4060107@ericsson.com> Date: Tue, 14 Jul 2015 09:36:23 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Paul E. Jones" , Eric Rescorla , , References: In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUyM+Jvje6P3UtCDfYttraYdeUnm8WK1+fY Lc5f2MBksXrhdEYHFo8lS34yeTTsO8ruMflxG7PHl8uf2QJYorhsUlJzMstSi/TtErgytrUa FkwQr/jc4dLAuEyoi5GTQ0LAROLLlm5GCFtM4sK99WxdjFwcQgJHGSV2ftnCDOEsZ5Toa7jJ ClLFK6AtcWP5ZSYQm0VAVWLjysnsIDabgIXEzR+NbCC2qECUxNTH61gg6gUlTs58wgIySERg MqPE3dMrwIqEBVwlXv24DTZUSMBaYs6GH2BDOQVsJBp+g8Q5OJgF7CUebC0DCTMLyEs0b53N DFGuLdHQ1ME6gVFgFpIVsxA6ZiHpWMDIvIpRtDi1uDg33chYL7UoM7m4OD9PLy+1ZBMjMHQP bvmtu4Nx9WvHQ4wCHIxKPLwKuUtChVgTy4orcw8xSnOwKInzzticFyokkJ5YkpqdmlqQWhRf VJqTWnyIkYmDU6qBcZFlQ4zvs2WnjPZuDFKvSPRb7Dbx7k+lixp7jm6dG8KsIXckd/sNw7zX 2Zta1k2eqnzt1+f1lcKXm73SNnHMSYtbGqMeMK2Rd69d9IQ5e9j77tbN/3rUwcS6f2b2U55q g8NPF5f7fKtV3GnXrMv263LXkyipu9Nd7f1TnY581tdMNP46qy6hRomlOCPRUIu5qDgRANOV SFU+AgAA Archived-At: Subject: Re: [Perc] Review of draft-jones-perc-private-media-reqts-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 07:36:28 -0000 Hi, I reacted to this part of the discussion. Paul E. Jones skrev den 2015-07-14 07:30: >> - PERC allows active attack by the Call Processing System to be >> detectable to a great extent: >> >> - The client knows the identity (i.e., the certificate) of >> the KMF. If WebRTC identity or a valid certificate is >> used, then the client can determine whether the CPS has >> injected itself. > This would be true, but that is also true even if the attack is not on > the CPS. >> - The KMF knows the number of participants in the call, but >> nothing prevents the CPS from injecting an extra participant >> since the KMF has no expectation of the caller's identities. > Insofar as the PERC work goes, I think that is a correct > statement. Some might build a KMF that does know endpoints and does > have access to a secure conference roster, but I don't think we want > to force those requirements into PERC. Regarding these two bullets, I think we do need to aim at the security level that no one that can't assert an identity towards the KMF that the inviter in the conference has included in the conference invitation/rooster can retrieve the key. That verification can't be dune by the CPS, it needs to be part of the KMF or a stand alone but trusted entity. From a functional perspective the conference inviter will schedule a conference and create a rooster with identity. At the time of joining the conference the participant needs to assert its identity to the KMF. If that is done by talking to a secure rooster server that generates some credentials bound to the participants endpoint, and those are used to assert the identity when talking to the KMF, that is an open question. I have a tendency to favour the second as that will reduce the API surface on the KMF, and separate the authorization of the participant to this separate function, which then can be a bit more flexible to integrate the various identity systems used. I also note if we are going to solve the SHOULD level goal of preventing a participant prior to joining and after leaving the conference to have an possibility to decrypt, including retrospective, the end-to-end security layer, then we will be forced to go into tracking who is currently active participants within a trusted function, i.e. not the CPS. The CPS can of course be an helper, but the security can't rely on the CPS. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jul 14 01:29:34 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A521A9079 for ; Tue, 14 Jul 2015 01:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fR_vMy2_TQGQ for ; Tue, 14 Jul 2015 01:29:31 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C531A9086 for ; Tue, 14 Jul 2015 01:29:29 -0700 (PDT) X-AuditID: c1b4fb2d-f79176d00000321c-fa-55a4c8674f29 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AA.4F.12828.768C4A55; Tue, 14 Jul 2015 10:29:27 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.210.2; Tue, 14 Jul 2015 10:29:26 +0200 Message-ID: <55A4C866.3060101@ericsson.com> Date: Tue, 14 Jul 2015 10:29:26 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Eric Rescorla , References: In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUyM+JvjW76iSWhBie/a1useH2O3WL1wumM DkweS5b8ZPKY/LiNOYApissmJTUnsyy1SN8ugSuj58oP1oLFMhXzd91haWC8INbFyMkhIWAi 0fusiwXCFpO4cG89WxcjF4eQwFFGia/frjFDOMsZJd73bmcHqeIV0JY4M3UBWAeLgKrE9+M9 jCA2m4CFxM0fjWwgtqhAlMTUx+tYIOoFJU7OfAJmiwgYStycfZIZxBYW8JCYMucHmC0kECCx c9UK1i5GDg5OgUCJT5MzQExmAXuJB1vLQCqYBeQlmrfOhqrWlmho6mCdwCgwC8mCWQgds5B0 LGBkXsUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGJIHt/zW3cG4+rXjIUYBDkYlHl6F3CWh QqyJZcWVuYcYpTlYlMR5Z2zOCxUSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAaCS85kngt4rs I+tdtBcmhPgnte/6EVy0ZEvZaafyzrzuiD03+A3j7s9buMksZNnn32/WTXkw+7epiUNe+4vS 85tsp4iFN6x/J8u0or3u7y0L+Rf118/uOqafpZlVtjakM8Wt6p7wx1O+n54ouNpacl65+ePE gwfHVSZ93xUa7v7yIuPEk0qG+UosxRmJhlrMRcWJAMvFEJQqAgAA Archived-At: Subject: Re: [Perc] Comments on draft-westerlund-perc-webrtc-use-case-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 08:29:33 -0000 Hi EKR, Thanks for the review and comments. Our goal with the document is two fold. We want to ensure we have sufficient discussion about the WebRTC challenges and requirements and any constraints that may lead to. The primary goal here is to ensure we have the security we need. Secondly, we are exploring ways of solving the authorization and distribution of the EKT master key, while considering web ways of doing things. Eric Rescorla skrev den 2015-07-12 02:05: > I have reviewed draft-westerlund-perc-webrtc-use-case-00, but I don't > think it meets either the security requirements listed in the document > or the larger requirement to protect the user from the conference > bridge. > > Section 4.2. says > 4.2. Dealing with JavaScript related Attacks > > The JavaScript code run in the browser is a potential attack vector. > Using various attacks, including cross-site scripting, the JavaScript > can be compromised and perform the actions an attacker dictates. > Even if the JS running in the browser is malicious it must not be > able to compromise the security of the conference, only perform > denial of service attacks such as preventing the user from joining > the conference. > > However, I don't believe that the described system actually provides > this property: while the EKT key may be available only to the browser > (and this is actually fairly unclear given the sketchy description > here), it's not bound to any particular PeerConection so nothing stops > the JS from attaching it to one (or more PCs, including those which > are actually connected to itself) and therefore capturing the user's > traffic. Compare this to WebRTC with isolated streams and identity, > where you know exactly who you are connected to. We might not have been clear, but we see that all media streams in a context using E2E security (PERC) will be forced into the confidentiality mode. Thus, media as plain-text will not be accessible to the JS. And as a result of that any PeerConnection created will need to be required to use the end-to-end encryption. So if you would select to forward the media, it would still be secured and not accessible to an attacker. I do note that this will require keeping the keys in use within one context to keys provided by one specific KMF. Otherwise the attacker could use a key of itself and still export the media of the endpoint. However, this falls under the same general case of applying policies to a WebRTC endpoint. The endpoint when using PERC must > > In addition, because you are sending the keys over an HTTP channel, > we have to worry about the HTTP security/logging issues we have with > SDES. Yes, but that is general issue in that case for the Content Encryption mechanism. What are the HTTPS security issues, beyond the issues with PKI trust? The PKI trust issue I would claim are shared with DTLS when connecting to servers, like the KMF. The logging is a question of implementation, one that apparently needs consideration on what to logg and not logg. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jul 14 02:04:14 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6EF81A90E7 for ; Tue, 14 Jul 2015 02:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-3IT2S6uDYm for ; Tue, 14 Jul 2015 02:04:10 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A35DA1A90DB for ; Tue, 14 Jul 2015 02:04:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 659D9BE39; Tue, 14 Jul 2015 10:04:08 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O30l-mknPR-d; Tue, 14 Jul 2015 10:04:07 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.19.158]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 17509BE32; Tue, 14 Jul 2015 10:04:07 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1436864647; bh=HyMdqoFso9CMYmu/cuPGecCEzl8dHCWW6MQcO0MAc/k=; h=Date:From:To:Subject:References:In-Reply-To:From; b=eK4A/eRpQ6NTx3c2PsDtp2OggUd3W2qUVCm8B7+d5PaqW7qmgBFBHGyvhqGk0xi3m zOPt75WitfWAee7HKeH/uKs5jXnW7dHtMEuKVk/IdOYDw1+WHdoWkI7M5LyyWUB2OI IjRRn4bLKZ2RUZTRpPokzp3Fk7ynoooFe4OHcxa8= Message-ID: <55A4D07F.3040403@cs.tcd.ie> Date: Tue, 14 Jul 2015 10:03:59 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Eric Rescorla , perc@ietf.org, draft-jones-perc-private-media-reqts@tools.ietf.org References: In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Perc] Review of draft-jones-perc-private-media-reqts-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 09:04:13 -0000 Hiya, On 12/07/15 22:36, Eric Rescorla wrote: > > - The KMF knows the number of participants in the call, but > nothing prevents the CPS from injecting an extra participant > since the KMF has no expectation of the caller's identities. I'm not sure I've got all the context here but if perc conference calls allow properly implemented infrastructure nodes to add a silent monitoring participant without any of the other call participants being able to detect that then I'd say we're not meeting the chartered goals. Yes, some nodes involved in call setup or the call might be able to leak keys or media but that'd be a bad implementation and not really a protocol design issue. S. From nobody Tue Jul 14 05:49:55 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39501AC44A for ; Tue, 14 Jul 2015 05:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aV5FLX3hzRn for ; Tue, 14 Jul 2015 05:49:51 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659511AC447 for ; Tue, 14 Jul 2015 05:49:51 -0700 (PDT) Received: by widjy10 with SMTP id jy10so98441186wid.1 for ; Tue, 14 Jul 2015 05:49:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=S8O8lY4NXnMvNHTGxHBIBIT3UsVWW0BQB0FYfOC2Dtw=; b=ld0X8L/s6881k6mb+VcMBJf+SqEYlOOntrpAl68DdS0R3uNylpEJj3vQAQKDXdamR5 vt/7tlGWowB9VR++OXvblu9DvCYaFJ60n7T1tv5LlbBYdDqVp7O74xER7y9hOEqE++Za GGsYVU8ravyLIgfn427rMtSgOYfPO38lkgLk69Vdw6Q834bwsTqNquzwwVDLvLRvVN4T w5tWb2VGtq6OuWJ+sdWVXdGtp9nHjLBW8ovGscenlcGm66LH+raw0IcqLpQ18AXY1ohc 644tAbq4thqaqxEYbpz6+LK3/UGUXe9A6ThtIqwnc3OTFDgDEgL/wLZcpajUrYq+BvWz ufFA== X-Gm-Message-State: ALoCoQmBcL9jkzmAymAQTC3Mk1+LAyJ1ocbFtIE+d3csbV1J/bLHuk+Owwhq5n4E/v6V1As2YPKi X-Received: by 10.194.79.225 with SMTP id m1mr78498446wjx.8.1436878190105; Tue, 14 Jul 2015 05:49:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Tue, 14 Jul 2015 05:49:10 -0700 (PDT) In-Reply-To: <55A4C866.3060101@ericsson.com> References: <55A4C866.3060101@ericsson.com> From: Eric Rescorla Date: Tue, 14 Jul 2015 05:49:10 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=047d7b10c9031b6b57051ad5467f Archived-At: Cc: perc@ietf.org Subject: Re: [Perc] Comments on draft-westerlund-perc-webrtc-use-case-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 12:49:54 -0000 --047d7b10c9031b6b57051ad5467f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 14, 2015 at 1:29 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi EKR, > > Thanks for the review and comments. Our goal with the document is two > fold. We want to ensure we have sufficient discussion about the WebRTC > challenges and requirements and any constraints that may lead to. The > primary goal here is to ensure we have the security we need. Secondly, we > are exploring ways of solving the authorization and distribution of the E= KT > master key, while considering web ways of doing things. > > Eric Rescorla skrev den 2015-07-12 02:05: > >> I have reviewed draft-westerlund-perc-webrtc-use-case-00, but I don't >> think it meets either the security requirements listed in the document >> or the larger requirement to protect the user from the conference >> bridge. >> >> Section 4.2. says >> 4.2. Dealing with JavaScript related Attacks >> >> The JavaScript code run in the browser is a potential attack vector. >> Using various attacks, including cross-site scripting, the JavaScrip= t >> can be compromised and perform the actions an attacker dictates. >> Even if the JS running in the browser is malicious it must not be >> able to compromise the security of the conference, only perform >> denial of service attacks such as preventing the user from joining >> the conference. >> >> However, I don't believe that the described system actually provides >> this property: while the EKT key may be available only to the browser >> (and this is actually fairly unclear given the sketchy description >> here), it's not bound to any particular PeerConection so nothing stops >> the JS from attaching it to one (or more PCs, including those which >> are actually connected to itself) and therefore capturing the user's >> traffic. Compare this to WebRTC with isolated streams and identity, >> where you know exactly who you are connected to. >> > > We might not have been clear, but we see that all media streams in a > context using E2E security (PERC) will be forced into the confidentiality > mode. I don't understand what you're suggesting here at all. > Thus, media as plain-text will not be accessible to the JS. And as a > result of that any PeerConnection created will need to be required to use > the end-to-end encryption. So if you would select to forward the media, i= t > would still be secured and not accessible to an attacker. > > I do note that this wil require keeping the keys in use within one contex= t > to keys provided by one specific KMF. Otherwise the attacker could use a > key of itself and still export the media of the endpoint. > However, this falls under the same general case of applying policies to a > WebRTC endpoint. The endpoint when using PERC must In addition, because you are sending the keys over an HTTP channel, >> we have to worry about the HTTP security/logging issues we have with >> SDES. >> > > Yes, but that is general issue in that case for the Content Encryption > mechanism. What are the HTTPS security issues, beyond the issues with PKI > trust? The PKI trust issue I would claim are shared with DTLS when > connecting to servers, like the KMF. The logging is a question of > implementation, one that apparently needs consideration on what to logg a= nd > not logg. > Well, it's an issue that doesn't exit if you only use the DTLS channel. -Ekr Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --047d7b10c9031b6b57051ad5467f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 14, 2015 at 1:29 AM, Magnus Westerlund &l= t;magnu= s.westerlund@ericsson.com> wrote:
Hi EKR,

Thanks for the review and comments. Our goal with the document is two fold.= We want to ensure we have sufficient discussion about the WebRTC challenge= s and requirements and any constraints that may lead to. The primary goal h= ere is to ensure we have the security we need. Secondly, we are exploring w= ays of solving the authorization and distribution of the EKT master key, wh= ile considering web ways of doing things.

Eric Rescorla skrev den 2015-07-12 02:05:
I have reviewed draft-westerlund-perc-webrtc-use-case-00, but I don't think it meets either the security requirements listed in the document
or the larger requirement to protect the user from the conference
bridge.

Section 4.2. says
4.2.=C2=A0 Dealing with JavaScript related Attacks

=C2=A0 =C2=A0 The JavaScript code run in the browser is a potential attack = vector.
=C2=A0 =C2=A0 Using various attacks, including cross-site scripting, the Ja= vaScript
=C2=A0 =C2=A0 can be compromised and perform the actions an attacker dictat= es.
=C2=A0 =C2=A0 Even if the JS running in the browser is malicious it must no= t be
=C2=A0 =C2=A0 able to compromise the security of the conference, only perfo= rm
=C2=A0 =C2=A0 denial of service attacks such as preventing the user from jo= ining
=C2=A0 =C2=A0 the conference.

However, I don't believe that the described system actually provides this property: while the EKT key may be available only to the browser
(and this is actually fairly unclear given the sketchy description
here), it's not bound to any particular PeerConection so nothing stops<= br> the JS from attaching it to one (or more PCs, including those which
are actually connected to itself) and therefore capturing the user's traffic. Compare this to WebRTC with isolated streams and identity,
where you know exactly who you are connected to.

 We might not have been clear, but we see that all media streams in a contex= t using E2E security (PERC) will be forced into the confidentiality mode.

I don't understand what you're sugge= sting here at all.

=C2=A0
Thus, media as plain-text will not be accessible to the JS. = And as a result of that any PeerConnection created will need to be required= to use the end-to-end encryption. So if you would select to forward the me= dia, it would still be secured and not accessible to an attacker.

I do note that this wil require keeping the keys in use within one context = to keys provided by one specific KMF. Otherwise the attacker could use a ke= y of itself and still export the media of the endpoint.
However, this falls under the same general case of applying policies to a W= ebRTC endpoint. The endpoint when using PERC must



In addition, because you are sending the keys over an HTTP channel,
we have to worry about the HTTP security/logging issues we have with
SDES.

Yes, but that is general issue in that case for the Content Encryption mech= anism. What are the HTTPS security issues, beyond the issues with PKI trust= ? The PKI trust issue I would claim are shared with DTLS when connecting to= servers, like the KMF. The logging is a question of implementation, one th= at apparently needs consideration on what to logg and not logg.

Well, it's an issue that doesn't exit if y= ou only use the DTLS channel.

-Ekr

<= /div>

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--047d7b10c9031b6b57051ad5467f-- From nobody Tue Jul 14 06:00:12 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E398D1ACC7F for ; Tue, 14 Jul 2015 06:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lMsAmP0caN4 for ; Tue, 14 Jul 2015 06:00:08 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA5CF1ACAD5 for ; Tue, 14 Jul 2015 06:00:07 -0700 (PDT) Received: by wibud3 with SMTP id ud3so13771054wib.0 for ; Tue, 14 Jul 2015 06:00:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MY05gEfmYR0wouvwNOR/pmfE2t5/yGzQmoxYOkDHXko=; b=U1fcZa7Wm2PqQjCqaw5CAZXar8coV+C3c5WZ7Wh08utS7ke6/V3cYg6V9rbVCsHxT7 +fnRC6i7qY3JEeaohCrf+Mb4eEEoRIY1HQsz8tmgCQIL3698kWV/d9pMD6mZCEvl/d3u w6duwrDmL/Bzuw9L7NDp5qS16/1oVoLyUXBzrgOgs0Pb9WaytZ/YBSHCT2r/sMY/u5UJ lQJs/yEDLGV923KikDeBaDA2ENB91ekUrDEjsZfvJkaIuXAlB28RNSJ/z7Zxl8xtjCji 4j47qID3F2jao9JdMAD1xTZbHKfXC02AwyRSMcVvSAehm+PtsT9FMNfIMJsckBN+hI/f lcVw== X-Gm-Message-State: ALoCoQkZ3rBlb40Enqyl4qrhYien3Ihd/KMeWNQ5oicvlTWwNjgrgUwi6Ri16dmb/oKhVe7Pd/hL X-Received: by 10.180.83.137 with SMTP id q9mr34553150wiy.68.1436878806387; Tue, 14 Jul 2015 06:00:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Tue, 14 Jul 2015 05:59:26 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 14 Jul 2015 05:59:26 -0700 Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=f46d04440196d722eb051ad56a99 Archived-At: Cc: draft-jones-perc-private-media-reqts@tools.ietf.org, perc@ietf.org Subject: Re: [Perc] Review of draft-jones-perc-private-media-reqts-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 13:00:11 -0000 --f46d04440196d722eb051ad56a99 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 13, 2015 at 10:30 PM, Paul E. Jones wrote: > Eric, > > > A few substantive comments below. If you have a github version, I can > send you a PR with editorial comments. > > > I don't, but I can. However, I'll need to do that a couple of weeks > following the IETF meeting. > > But, if you send me comments in any form, I'll take them and incorporate > them. > > > * I think it would help to be more precise about your threat model > and specifically the role of the MDD and Call Processing. Here's > how I would phrase things: > > - PERC provides defense against a passive attacker at either the MDD > and the Call Processing System, since they never come in contact > with the keys. > - PERC prevents active attack by the MDD > > - PERC allows active attack by the Call Processing System to be > detectable to a great extent: > > - The client knows the identity (i.e., the certificate) of > the KMF. If WebRTC identity or a valid certificate is > used, then the client can determine whether the CPS has > injected itself. > > > This would be true, but that is also true even if the attack is not on the > CPS. > Yes, but the point is that the client can't automatically reject this case (the user has to actually know what the expected identity of the KMF is). By contrast, if the CPS isn't attacked but some network attacker tries to inject themselves, the fingerprint check fails. - The KMF knows the number of participants in the call, but > nothing prevents the CPS from injecting an extra participant > since the KMF has no expectation of the caller's identities. > > > Insofar as the PERC work goes, I think that is a correct statement. Some > might build a KMF that does know endpoints and does have access to a > secure conference roster, but I don't think we want to force those > requirements into PERC. > Yes, that's fine. > All this assumes the DTLS solution in > draft-jones-perc-private-media-framework, but since we know that's > achievable, it's a good goal to shoot for. > > Does this sound correct to you. > > > Yes, if you can also agree with my small interventions above. > > > > * Section 7.1.2 is confusing when compared to 7.2.3. > I think that the issue is that 7.1.2 needs to be rewritten to > make clear that the guarantee is that the sending endpoint is > part of the group, not that it is a particular endpoint. > > > We might want to know that it is a particular endpoint or even a > particular human user, and we get this by checking the client certificate > and validating it. However, insofar as this goal goes, I think that was > the intent. John Mattsson contributed this one, I think. If you don't > have particular suggestions for wording changes, perhaps he might weigh in? > That's fine as far as session establishment, but once the session is established everyone knows the sending key for Alice and so can impersonate Alice unless the MDD tags each message with the identity using the H2H key. Is that the plan? > > * The end of Section 6.2 should be rewritten to make clear that > while a switching MDD can do bad stuff, this shouldn't lead to > compromise of the basic comsec guarantees (i.e., forgery or > content disclosure). > > > Are you suggesting we add something else or modify that last paragraph? > Yes. I can send new text at some point. * Section 7.1.5: the summary here is that addition to the group > has to be fast but removal can be slower, right? Including > retrospective removal. > > > Re-keying can take time, so I think the intent is to leave it open to > implementations whether they want to re-key or not. However, it was stated > as a goal to make it possible to re-key the conference on roster changes. > OK. > > * Section 7.2.2 You might mention that Tor has bad performance > properties here. > > > That's really orthogonal to the security characteristics, which are the > focus of that. However, I'm not opposed to saying that, particularly if you > think it helps to make a point. What did you have in mind, exactly? > Well, I thought that the point here was that it was out of scope. It's out of scope because it may not have the desired security guarantees (which you do say) and it's slow (which you don't say). > > > * Section 7.2.3 It's also probably worth mentioning that EC > signatures are starting to be within the plausible performance > boundaries. For example you can do about 1000 verifies/sec > (and 2000 signs/sec) with ECDSA P-256 on my Mac RetinaBook Pro > (OpenSSL). > > > This is a non-goals section. Are you suggesting we re-consider that in > light of EC performance? > Not sure. Perhaps the WG should discuss. > * I am having trouble reading PM-03. Can you restate? > > > Perhaps you can help with the wording. The intent was the following > points: > * Replay protection must be enabled at each hop so as to > * Ensure that a received packet is intended for the recipient (e.g., the > receiving endpoint is the correct recipient); and > * Ensure that the packet is not a duplicated packet. > > This boils down to: > * If Bob receives a packet sent to Carol, Bob should detect it was not > intended for him and discard it > * If Bob receives a packet that he has already processed, he will know to > discard it > > Yes, this sounds like a reasonable goal. Will see if I can rewrite. -Ekr --f46d04440196d722eb051ad56a99 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 13, 2015 at 10:30 PM, Paul E. Jones <<= a href=3D"mailto:paulej@packetizer.com" target=3D"_blank">paulej@packetizer= .com> wrote:
Eric,
=C2=A0
A few substantive comments below. If you have a github version, I can<= /div>
send you a PR with editorial comments.
=C2=A0
I don't, but I can.=C2=A0 However, I'll need to do that= a couple of weeks following the IETF meeting.
=C2=A0
But, if you send me comments in any form, I'll take them and incor= porate them.
=C2=A0
* I think it would help to be more precise about your threat model
and specifically the role of the MDD and Call Processing. Here's
how I would phrase things:

- PERC provides defense against a passive attacker at either the MDD
=C2=A0 and the Call Processing System, since they never come in contac= t
=C2=A0 with the keys.
- PERC prevents active attack by the MDD

- PERC allows active attack by the Call Processing System to be
=C2=A0 detectable to a great extent:

=C2=A0 - The client knows the identity (i.e., the certificate) of
=C2=A0 =C2=A0 the KMF. If WebRTC identity or a valid certificate is
=C2=A0 =C2=A0 used, then the client can determine whether the CPS has<= /div>
=C2=A0 =C2=A0 injected itself.
=C2=A0
This would be true, but that is also true even if the attack is= not on the CPS.

Yes, but= the point is that the client can't automatically reject this case
(the user has to actually know what the expected identity of the KMF = is).
By contrast, if the CPS isn't attacked but some network = attacker tries
to inject themselves, the fingerprint check fails.=


=C2=A0 - The KMF knows the number of participants in the call, but
=C2=A0 =C2=A0 nothing prevents the CPS from injecting an extra partici= pant
=C2=A0 =C2=A0 since the KMF has no expectation of the caller's ide= ntities.
=C2=A0
Insofar as the PERC work goes, I think that is a=C2=A0correct s= tatement.=C2=A0=C2=A0Some might build a KMF that does know endpoints and do= es =C2=A0have access to a secure conference roster, but I don't think w= e want to force those requirements into PERC.

Yes, that's fine.

=C2=A0
All this assumes the DTLS solution in
draft-jones-perc-private-media-framework, but since we know that's=
achievable, it's a good goal to shoot for.

Does this sound correct to you.
=C2=A0
Yes, if you can also agree with my small interventions above.

=C2=A0
* Section 7.1.2 is confusing when compared to 7.2.3.
I think that the issue is that 7.1.2 needs to be rewritten to
make clear that the guarantee is that the sending endpoint is
part of the group, not that it is a particular endpoint.
=C2=A0
We might want to know that it is a particular endpoint or even = a particular human user,=C2=A0and we get this by checking the client certif= icate and validating it.=C2=A0 However, insofar as this goal goes, I think = that was the intent.=C2=A0 John Mattsson contributed this one, I think.=C2= =A0 If you don't have particular suggestions for wording changes, perha= ps he might weigh in?

That's fine= as far as session establishment, but once the session is established
=
everyone knows the sending key for Alice and so can impersonate Alice<= /div>
unless the MDD tags each message with the identity using the H2H = key.
Is that the plan?

=C2=A0
* The end of Section 6.2 should be rewritten to make clear that
while a switching MDD can do bad stuff, this shouldn't lead to
compromise of the basic comsec guarantees (i.e., forgery or
content disclosure).
=C2=A0
Are you suggesting we add something else or modify that last pa= ragraph?

Yes. I can send new text= at some point.


* Section 7.1.5: the summary here is that addition to the group
has to be fast but removal can be slower, right? Including
retrospective removal.
=C2=A0
Re-keying can take time, so I think the intent is to leave it o= pen to implementations whether they want to re-key or not.=C2=A0 However, i= t was stated as a goal to make it possible to re-key the conference on rost= er changes.

OK.=C2=A0
=C2=A0
* Section 7.2.2 You might mention that Tor has bad performance
properties here.
=C2=A0
That's really orthogonal to the security characteristics, w= hich are the focus of that.=C2=A0However, I'm not opposed to saying tha= t, particularly if you think it helps to make a point.=C2=A0 What did you h= ave in mind, exactly?

Well, I thought= that the point here was that it was out of scope. It's out
o= f scope because it may not have the desired security guarantees (which
you do say) and it's slow (which you don't say).
=C2=A0
=C2=A0
* Section 7.2.3 It's also probably worth mentioning that EC
signatures are starting to be within the plausible performance
boundaries. For example you can do about 1000 verifies/sec
(and 2000 signs/sec) with ECDSA P-256 on my Mac RetinaBook Pro
(OpenSSL).
=C2=A0
This is a non-goals section.=C2=A0 Are you suggesting we re-con= sider that in light of EC performance?

Not sure. Perhaps the WG should discuss.

=C2=A0<= /div>
* I am having trouble reading PM-03. Can you restate?
=C2=A0
Perhaps you can help with the wording.=C2=A0 The intent was=C2= =A0 the following points:
* Replay protection must be enabled at each hop so as to
=C2=A0 * Ensure that a received packet is intended for the recipient (= e.g., the receiving endpoint is the correct recipient); and
=C2=A0 * Ensure that the packet is not a duplicated packet.
=C2=A0
This boils down to:
=C2=A0* If Bob receives a packet sent to Carol, Bob should detect it w= as not intended for him and discard it
=C2=A0* If Bob receives a packet that=C2=A0he has already processed, h= e will know to discard it

Yes, this sounds like a reas= onable goal. Will see if I can rewrite.

-Ekr
=
=C2=A0

--f46d04440196d722eb051ad56a99-- From nobody Tue Jul 14 06:04:35 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A861ACC8F for ; Tue, 14 Jul 2015 06:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.977 X-Spam-Level: X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Xyom0InfmOy for ; Tue, 14 Jul 2015 06:04:32 -0700 (PDT) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 121321ACC87 for ; Tue, 14 Jul 2015 06:04:32 -0700 (PDT) Received: by wgjx7 with SMTP id x7so8290482wgj.2 for ; Tue, 14 Jul 2015 06:04:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=g9qmhaZeBLz2gpL9iCi/2ovIk5yGJ1wQ+t4RxUveOuE=; b=e7i8EJi+0DblGAWWmbffE6gmBpZB3rs3MFniyvSIkioqfY0XGp2FwT76APK6ax0Rnd 7n1gUrVWt5/vC6VVmPUGx/mur35Chc32TVEa35SD9gl9a/YCrwvFgCZnZbO4dhUay4yo 4RVvpjbYxwDkUBTz3sKCGCU+GNkWs2+XreEH5LT9AzhR9bjcPeAtFNNiXUbAcziSDtUT t2k2598TGl+D1RaNb7f8HTh8GAXF5X1TDD2l40caLCg0wJRltWiFnIFEIIBwCfHueLjG SqjAxFKVcQySL2Lc8vy1LVRKsHKE0Bk1kdBqEDa4cyqkPOs/GVnyyetw83VPEc0UEQRi JFLQ== X-Gm-Message-State: ALoCoQleG6F55gspDDvQUCTdxhPlsQZDC573LEfamPCC7H4uQ1iTj7JHLKFjIkcVtJiMhXNBfDJz X-Received: by 10.180.75.78 with SMTP id a14mr5609553wiw.68.1436879070620; Tue, 14 Jul 2015 06:04:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Tue, 14 Jul 2015 06:03:51 -0700 (PDT) In-Reply-To: <55A4BBF7.4060107@ericsson.com> References: <55A4BBF7.4060107@ericsson.com> From: Eric Rescorla Date: Tue, 14 Jul 2015 06:03:51 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=f46d0438eb9d970027051ad57a50 Archived-At: Cc: "Paul E. Jones" , perc@ietf.org, draft-jones-perc-private-media-reqts@tools.ietf.org Subject: Re: [Perc] Review of draft-jones-perc-private-media-reqts-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 13:04:34 -0000 --f46d0438eb9d970027051ad57a50 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 14, 2015 at 12:36 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > I reacted to this part of the discussion. > > Paul E. Jones skrev den 2015-07-14 07:30: > > - PERC allows active attack by the Call Processing System to be >>> detectable to a great extent: >>> >>> - The client knows the identity (i.e., the certificate) of >>> the KMF. If WebRTC identity or a valid certificate is >>> used, then the client can determine whether the CPS has >>> injected itself. >>> >> This would be true, but that is also true even if the attack is not on >> the CPS. >> >>> - The KMF knows the number of participants in the call, but >>> nothing prevents the CPS from injecting an extra participant >>> since the KMF has no expectation of the caller's identities. >>> >> Insofar as the PERC work goes, I think that is a correct >> statement. Some might build a KMF that does know endpoints and does >> have access to a secure conference roster, but I don't think we want >> to force those requirements into PERC. >> > > Regarding these two bullets, I think we do need to aim at the security > level that no one that can't assert an identity towards the KMF that the > inviter in the conference has included in the conference invitation/roost= er > can retrieve the key. That verification can't be dune by the CPS, it need= s > to be part of the KMF or a stand alone but trusted entity. > > From a functional perspective the conference inviter will schedule a > conference and create a rooster with identity. At the time of joining the > conference the participant needs to assert its identity to the KMF. If th= at > is done by talking to a secure rooster server that generates some > credentials bound to the participants endpoint, and those are used to > assert the identity when talking to the KMF, that is an open question. I > have a tendency to favour the second as that will reduce the API surface = on > the KMF, and separate the authorization of the participant to this separa= te > function, which then can be a bit more flexible to integrate the various > identity systems used. > As far as I know, standardizing the control plane communication between the KM and the CPS is out of scope for this effort, right? So it certainly should be possible that the KMF will have an independent way of knowing which identities should be allowed into the conference, but it's not something we are required to design. And there are certainly valid designs where you don't provide this. > I also note if we are going to solve the SHOULD level goal of preventing = a > participant prior to joining and after leaving the conference to have an > possibility to decrypt, including retrospective, the end-to-end security > layer, then we will be forced to go into tracking who is currently active > participants within a trusted function, i.e. not the CPS. The CPS can of > course be an helper, but the security can't rely on the CPS > See above. -Ekr > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --f46d0438eb9d970027051ad57a50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 14, 2015 at 12:36 AM, Magnus Westerlund &= lt;magn= us.westerlund@ericsson.com> wrote:
Hi,

I reacted to this part of the discussion.

Paul E. Jones skrev den 2015-07-14 07:30:

- PERC allows active attack by the Call Processing System to be
=C2=A0 detectable to a great extent:

=C2=A0 - The client knows the identity (i.e., the certificate) of
=C2=A0 =C2=A0 the KMF. If WebRTC identity or a valid certificate is
=C2=A0 =C2=A0 used, then the client can determine whether the CPS has
=C2=A0 =C2=A0 injected itself.
This would be true, but that is also true even if the attack is not on
the CPS.
=C2=A0 - The KMF knows the number of participants in the call, but
=C2=A0 =C2=A0 nothing prevents the CPS from injecting an extra participant<= br> =C2=A0 =C2=A0 since the KMF has no expectation of the caller's identiti= es.
Insofar as the PERC work goes, I think that is a correct
statement.=C2=A0 Some might build a KMF that does know endpoints and does =C2=A0 have access to a secure conference roster, but I don't think we = want
to force those requirements into PERC.

 Regarding these two bullets, I think we do need to aim at the security leve= l that no one that can't assert an identity towards the KMF that the in= viter in the conference has included in the conference invitation/rooster c= an retrieve the key. That verification can't be dune by the CPS, it nee= ds to be part of the KMF or a stand alone but trusted entity.

>From a functional perspective the conference inviter will schedule a confer= ence and create a rooster with identity. At the time of joining the confere= nce the participant needs to assert its identity to the KMF. If that is don= e by talking to a secure rooster server that generates some credentials bou= nd to the participants endpoint, and those are used to assert the identity = when talking to the KMF, that is an open question. I have a tendency to fav= our the second as that will reduce the API surface on the KMF, and separate= the authorization of the participant to this separate function, which then= can be a bit more flexible to integrate the various identity systems used.=

As far as I know, standardizing the co= ntrol plane communication between the KM
and the CPS is out of sc= ope for this effort, right? So it certainly should be possible
th= at the KMF will have an independent way of knowing which identities should = be
allowed into the conference, but it's not something we are= required to design.
And there are certainly valid designs where = you don't provide this.

=C2=A0
I also note if we are going to solve the SHOULD level goal of preventing a = participant prior to joining and after leaving the conference to have an po= ssibility to decrypt, including retrospective, the end-to-end security laye= r, then we will be forced to go into tracking who is currently active parti= cipants within a trusted function, i.e. not the CPS. The CPS can of course = be an helper, but the security can't rely on the CPS

See above.

-Ekr
=C2=A0=
Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--f46d0438eb9d970027051ad57a50-- From nobody Tue Jul 14 06:10:24 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2A41ACCDA for ; Tue, 14 Jul 2015 06:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5iac819GQXq for ; Tue, 14 Jul 2015 06:10:16 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACC6C1ACC82 for ; Tue, 14 Jul 2015 06:10:15 -0700 (PDT) X-AuditID: c1b4fb2d-f79176d00000321c-a2-55a50a35a570 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BA.C3.12828.53A05A55; Tue, 14 Jul 2015 15:10:13 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.210.2; Tue, 14 Jul 2015 15:10:12 +0200 Message-ID: <55A50A34.9070506@ericsson.com> Date: Tue, 14 Jul 2015 15:10:12 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Eric Rescorla References: <55A4C866.3060101@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM+Jvja4p19JQg2kf9C1WvD7HbrF64XRG ByaPJUt+MnlMftzGHMAUxWWTkpqTWZZapG+XwJVxp3k+e8FHlYrld0wbGJukuxg5OSQETCSa 17YwQ9hiEhfurWfrYuTiEBI4yijR/v0dO4SznFGib8NDNpAqXgFtiTnLfzKB2CwCqhIHvjWA dbMJWEjc/NEIViMqECUx9fE6Foh6QYmTM5+A2SICChK//pwAs5kFhCXerVoH1iss4CExZc4P ZohlWxklzs/tYAVJcAoESlw9/oIZosFCYub884wQtrxE89bZYHEhoIMamjpYJzAKzkKybxaS lllIWhYwMq9iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECAzYg1t+6+5gXP3a8RCjAAejEg+v Qu6SUCHWxLLiytxDjNIcLErivDM254UKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYPS2nP9R fu7pc18Eeervnv4a8+NpYOArpc8/9k1jcshxf3r3816WRc/fLtVfN8Hv9ftjRobnrIP9TT4L ynAd4NIN8Hykq7D/TniqsXeWRcSXZexvFHemPlNlc1IR1axljr3e1X7hJcuMbUxHFm0TOTiV 63DDOqM5YpN5Urm2u5X8udC5jdOk94kSS3FGoqEWc1FxIgAugTgcOQIAAA== Archived-At: Cc: perc@ietf.org Subject: Re: [Perc] Comments on draft-westerlund-perc-webrtc-use-case-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 13:10:22 -0000 Eric Rescorla skrev den 2015-07-14 14:49: > > > On Tue, Jul 14, 2015 at 1:29 AM, Magnus Westerlund > > > wrote: > > Hi EKR, > > Thanks for the review and comments. Our goal with the document is > two fold. We want to ensure we have sufficient discussion about the > WebRTC challenges and requirements and any constraints that may lead > to. The primary goal here is to ensure we have the security we need. > Secondly, we are exploring ways of solving the authorization and > distribution of the EKT master key, while considering web ways of > doing things. > > Eric Rescorla skrev den 2015-07-12 02:05: > > I have reviewed draft-westerlund-perc-webrtc-use-case-00, but I > don't > think it meets either the security requirements listed in the > document > or the larger requirement to protect the user from the conference > bridge. > > Section 4.2. says > 4.2. Dealing with JavaScript related Attacks > > The JavaScript code run in the browser is a potential > attack vector. > Using various attacks, including cross-site scripting, the > JavaScript > can be compromised and perform the actions an attacker > dictates. > Even if the JS running in the browser is malicious it must > not be > able to compromise the security of the conference, only perform > denial of service attacks such as preventing the user from > joining > the conference. > > However, I don't believe that the described system actually provides > this property: while the EKT key may be available only to the > browser > (and this is actually fairly unclear given the sketchy description > here), it's not bound to any particular PeerConection so nothing > stops > the JS from attaching it to one (or more PCs, including those which > are actually connected to itself) and therefore capturing the user's > traffic. Compare this to WebRTC with isolated streams and identity, > where you know exactly who you are connected to. > > > We might not have been clear, but we see that all media streams in a > context using E2E security (PERC) will be forced into the > confidentiality mode. > > > I don't understand what you're suggesting here at all. The media confidentiality (isolation) mode that is enabled by the ALPN tag "c-webrtc" as described in: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-alpn/ > > Thus, media as plain-text will not be accessible to the JS. And as a > result of that any PeerConnection created will need to be required > to use the end-to-end encryption. So if you would select to forward > the media, it would still be secured and not accessible to an attacker. > > I do note that this wil require keeping the keys in use within one > context to keys provided by one specific KMF. Otherwise the attacker > could use a key of itself and still export the media of the endpoint. > However, this falls under the same general case of applying policies > to a WebRTC endpoint. The endpoint when using PERC must > > > > > In addition, because you are sending the keys over an HTTP channel, > we have to worry about the HTTP security/logging issues we have with > SDES. > > > Yes, but that is general issue in that case for the Content > Encryption mechanism. What are the HTTPS security issues, beyond the > issues with PKI trust? The PKI trust issue I would claim are shared > with DTLS when connecting to servers, like the KMF. The logging is a > question of implementation, one that apparently needs consideration > on what to logg and not logg. > > > Well, it's an issue that doesn't exit if you only use the DTLS channel. Agreed, but not being alone with a problem makes it more likely that you can reach the critical mass to address the issue. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jul 14 09:22:53 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFC81A1EF1 for ; Tue, 14 Jul 2015 09:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfUpiCdTQZLm for ; Tue, 14 Jul 2015 09:22:49 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECE591A1F73 for ; Tue, 14 Jul 2015 09:22:48 -0700 (PDT) Received: by widic2 with SMTP id ic2so42517259wid.0 for ; Tue, 14 Jul 2015 09:22:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=chOkP1MdQjfJuGfBP7sOIXVGRqmtM/Hjyl4S5MfG2jg=; b=SAaB718EjpOEsEvvC2aiDU+wckvh1jzZRaVslHkLG5qrMdCgGmh5g2JHDzcCCzJnNU NPI4PrE3ihZUQLo5o/ev9Jo41Hy+wCNBTXFINJ8B7ioCj934HFgbR0yGzc6cYf28Phm4 tCp1fRvRcLHDgis+q72GlkUpBfPYLpdinQiXK5UKy0h0wM6iu0FlrOsAsJM91z2HlKVa SMn8UIbrUsNcl9stubMEf9GolCQRqqSSyp2uVg2h8qNczT1bClyVmpp/Y/Z+h5XDZ960 7yG4fWpd7yfTUhD3aJmzgf0xOdy7vCHuxQRyWWXK89xSSEP2MIbThiKrlS3n1NAdcEiy /Xig== X-Gm-Message-State: ALoCoQlz5koXvd+KeHlWeDAoNg4VnDMmy4pz0it4r7QFSfboD+mvk4mIg00k5CaYUnMsVmBwQPRp X-Received: by 10.180.99.39 with SMTP id en7mr35309269wib.31.1436890967616; Tue, 14 Jul 2015 09:22:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Tue, 14 Jul 2015 09:22:07 -0700 (PDT) In-Reply-To: <55A50A34.9070506@ericsson.com> References: <55A4C866.3060101@ericsson.com> <55A50A34.9070506@ericsson.com> From: Eric Rescorla Date: Tue, 14 Jul 2015 09:22:07 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=f46d04182808b4c29f051ad83fb8 Archived-At: Cc: perc@ietf.org Subject: Re: [Perc] Comments on draft-westerlund-perc-webrtc-use-case-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 16:22:52 -0000 --f46d04182808b4c29f051ad83fb8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 14, 2015 at 6:10 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Eric Rescorla skrev den 2015-07-14 14:49: > >> >> >> On Tue, Jul 14, 2015 at 1:29 AM, Magnus Westerlund >> > >> >> wrote: >> >> Hi EKR, >> >> Thanks for the review and comments. Our goal with the document is >> two fold. We want to ensure we have sufficient discussion about the >> WebRTC challenges and requirements and any constraints that may lead >> to. The primary goal here is to ensure we have the security we need. >> Secondly, we are exploring ways of solving the authorization and >> distribution of the EKT master key, while considering web ways of >> doing things. >> >> Eric Rescorla skrev den 2015-07-12 02:05: >> >> I have reviewed draft-westerlund-perc-webrtc-use-case-00, but I >> don't >> think it meets either the security requirements listed in the >> document >> or the larger requirement to protect the user from the conferenc= e >> bridge. >> >> Section 4.2. says >> 4.2. Dealing with JavaScript related Attacks >> >> The JavaScript code run in the browser is a potential >> attack vector. >> Using various attacks, including cross-site scripting, the >> JavaScript >> can be compromised and perform the actions an attacker >> dictates. >> Even if the JS running in the browser is malicious it must >> not be >> able to compromise the security of the conference, only >> perform >> denial of service attacks such as preventing the user from >> joining >> the conference. >> >> However, I don't believe that the described system actually >> provides >> this property: while the EKT key may be available only to the >> browser >> (and this is actually fairly unclear given the sketchy descripti= on >> here), it's not bound to any particular PeerConection so nothing >> stops >> the JS from attaching it to one (or more PCs, including those >> which >> are actually connected to itself) and therefore capturing the >> user's >> traffic. Compare this to WebRTC with isolated streams and >> identity, >> where you know exactly who you are connected to. >> >> >> We might not have been clear, but we see that all media streams in a >> context using E2E security (PERC) will be forced into the >> confidentiality mode. >> >> >> I don't understand what you're suggesting here at all. >> > > The media confidentiality (isolation) mode that is enabled by the ALPN ta= g > "c-webrtc" as described in: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-alpn/ I don't see how this solves the problem. The issue is that from the browser's perspective, the DTLS connection is to the MDD, so how does he know what the MDD is doing with the data? -Ekr > Thus, media as plain-text will not be accessible to the JS. And as a >> result of that any PeerConnection created will need to be required >> to use the end-to-end encryption. So if you would select to forward >> the media, it would still be secured and not accessible to an >> attacker. >> >> I do note that this wil require keeping the keys in use within one >> context to keys provided by one specific KMF. Otherwise the attacker >> could use a key of itself and still export the media of the endpoint= . >> However, this falls under the same general case of applying policies >> to a WebRTC endpoint. The endpoint when using PERC must >> >> >> >> >> In addition, because you are sending the keys over an HTTP >> channel, >> we have to worry about the HTTP security/logging issues we have >> with >> SDES. >> >> >> Yes, but that is general issue in that case for the Content >> Encryption mechanism. What are the HTTPS security issues, beyond the >> issues with PKI trust? The PKI trust issue I would claim are shared >> with DTLS when connecting to servers, like the KMF. The logging is a >> question of implementation, one that apparently needs consideration >> on what to logg and not logg. >> >> >> Well, it's an issue that doesn't exit if you only use the DTLS channel. >> > > > Agreed, but not being alone with a problem makes it more likely that you > can reach the critical mass to address the issue. > > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --f46d04182808b4c29f051ad83fb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 14, 2015 at 6:10 AM, Magnus Westerlund &l= t;magnu= s.westerlund@ericsson.com> wrote:
Eric Rescorla skrev den 2015-07-14 14:49:


On Tue, Jul 14, 2015 at 1:29 AM, Magnus Westerlund
 <mag= nus.westerlund@ericsson.com <mailto:magnus.westerlund@ericsson.com>&= gt;

wrote:

=C2=A0 =C2=A0 Hi EKR,

=C2=A0 =C2=A0 Thanks for the review and comments. Our goal with the documen= t is
=C2=A0 =C2=A0 two fold. We want to ensure we have sufficient discussion abo= ut the
=C2=A0 =C2=A0 WebRTC challenges and requirements and any constraints that m= ay lead
=C2=A0 =C2=A0 to. The primary goal here is to ensure we have the security w= e need.
=C2=A0 =C2=A0 Secondly, we are exploring ways of solving the authorization = and
=C2=A0 =C2=A0 distribution of the EKT master key, while considering web way= s of
=C2=A0 =C2=A0 doing things.

=C2=A0 =C2=A0 Eric Rescorla skrev den 2015-07-12 02:05:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I have reviewed draft-westerlund-perc-webrtc-us= e-case-00, but I
=C2=A0 =C2=A0 =C2=A0 =C2=A0 don't
=C2=A0 =C2=A0 =C2=A0 =C2=A0 think it meets either the security requirements= listed in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 document
=C2=A0 =C2=A0 =C2=A0 =C2=A0 or the larger requirement to protect the user f= rom the conference
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bridge.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Section 4.2. says
=C2=A0 =C2=A0 =C2=A0 =C2=A0 4.2.=C2=A0 Dealing with JavaScript related Atta= cks

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The JavaScript code run in = the browser is a potential
=C2=A0 =C2=A0 =C2=A0 =C2=A0 attack vector.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Using various attacks, incl= uding cross-site scripting, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 JavaScript
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0can be compromised and perf= orm the actions an attacker
=C2=A0 =C2=A0 =C2=A0 =C2=A0 dictates.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Even if the JS running in t= he browser is malicious it must
=C2=A0 =C2=A0 =C2=A0 =C2=A0 not be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0able to compromise the secu= rity of the conference, only perform
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0denial of service attacks s= uch as preventing the user from
=C2=A0 =C2=A0 =C2=A0 =C2=A0 joining
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the conference.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 However, I don't believe that the described= system actually provides
=C2=A0 =C2=A0 =C2=A0 =C2=A0 this property: while the EKT key may be availab= le only to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 browser
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (and this is actually fairly unclear given the = sketchy description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 here), it's not bound to any particular Pee= rConection so nothing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 stops
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the JS from attaching it to one (or more PCs, i= ncluding those which
=C2=A0 =C2=A0 =C2=A0 =C2=A0 are actually connected to itself) and therefore= capturing the user's
=C2=A0 =C2=A0 =C2=A0 =C2=A0 traffic. Compare this to WebRTC with isolated s= treams and identity,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 where you know exactly who you are connected to= .


=C2=A0 =C2=A0 We might not have been clear, but we see that all media strea= ms in a
=C2=A0 =C2=A0 context using E2E security (PERC) will be forced into the
=C2=A0 =C2=A0 confidentiality mode.


I don't understand what you're suggesting here at all.

The media confidentiality (isolation) mode that is enabled by the ALPN tag = "c-webrtc" as described in:
https://datatracker.ietf.org/doc/draft-ietf-= rtcweb-alpn/

I don't see how this s= olves the problem. The issue is that from the browser's perspective,
the DTLS connection is to the MDD, so how does he know what the MDD= is doing with
the data?

-Ekr
=

=C2=A0
=C2=A0 =C2=A0 Thus, media as plain-text will not be accessible to the JS. A= nd as a
=C2=A0 =C2=A0 result of that any PeerConnection created will need to be req= uired
=C2=A0 =C2=A0 to use the end-to-end encryption. So if you would select to f= orward
=C2=A0 =C2=A0 the media, it would still be secured and not accessible to an= attacker.

=C2=A0 =C2=A0 I do note that this wil require keeping the keys in use withi= n one
=C2=A0 =C2=A0 context to keys provided by one specific KMF. Otherwise the a= ttacker
=C2=A0 =C2=A0 could use a key of itself and still export the media of the e= ndpoint.
=C2=A0 =C2=A0 However, this falls under the same general case of applying p= olicies
=C2=A0 =C2=A0 to a WebRTC endpoint. The endpoint when using PERC must




=C2=A0 =C2=A0 =C2=A0 =C2=A0 In addition, because you are sending the keys o= ver an HTTP channel,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 we have to worry about the HTTP security/loggin= g issues we have with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SDES.


=C2=A0 =C2=A0 Yes, but that is general issue in that case for the Content =C2=A0 =C2=A0 Encryption mechanism. What are the HTTPS security issues, bey= ond the
=C2=A0 =C2=A0 issues with PKI trust? The PKI trust issue I would claim are = shared
=C2=A0 =C2=A0 with DTLS when connecting to servers, like the KMF. The loggi= ng is a
=C2=A0 =C2=A0 question of implementation, one that apparently needs conside= ration
=C2=A0 =C2=A0 on what to logg and not logg.


Well, it's an issue that doesn't exit if you only use the DTLS chan= nel.


Agreed, but not being alone with a problem makes it more likely that you ca= n reach the critical mass to address the issue.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--f46d04182808b4c29f051ad83fb8-- From nobody Tue Jul 14 09:49:40 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDFA1A1A22 for ; Tue, 14 Jul 2015 09:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djOtoPQjfL5f for ; Tue, 14 Jul 2015 09:49:37 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 707531A038A for ; Tue, 14 Jul 2015 09:49:37 -0700 (PDT) X-AuditID: c1b4fb25-f79046d000007f53-a0-55a53d9f8737 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 49.B1.32595.F9D35A55; Tue, 14 Jul 2015 18:49:35 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.210.2; Tue, 14 Jul 2015 18:49:35 +0200 Message-ID: <55A53D9E.1040806@ericsson.com> Date: Tue, 14 Jul 2015 18:49:34 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Eric Rescorla References: <55A4C866.3060101@ericsson.com> <55A50A34.9070506@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUyM+Jvje5826WhBu/ealqseH2O3WL1wumM DkweS5b8ZPKY/LiNOYApissmJTUnsyy1SN8ugStj+ro97AXneCq2njjG1sA4kauLkZNDQsBE 4t7CHUwQtpjEhXvr2boYuTiEBI4ySnxYe44ZwlnOKPHo/kkWkCpeAW2Jg0+3soPYLAKqEtPX fgKLswlYSNz80cgGYosKRElMfbwOql5Q4uTMJ2C2iICCxK8/J8BsZgFhiXer1jGD2MICHhJT 5vyAWjaLSaK7/TwrSIJTIFDi8KGdUA0WEjPnn2eEsOUlmrfOBmsWAjqooamDdQKj4Cwk+2Yh aZmFpGUBI/MqRtHi1OKk3HQjY73Uoszk4uL8PL281JJNjMCQPbjlt+oOxstvHA8xCnAwKvHw KuQuCRViTSwrrsw9xCjNwaIkzjtjc16okEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkbJ1Dln GDbsYlum4Bv/nSXfsit1Q0JEe3rtH03/JNkXQa2LOD1PPFHrfBR3pHfv/dAfHuXvpLeUrBN9 E+zoOfe/4M2nyXNZBPYqTdxl579k494bRVmPDI7xv/9R/5L94dYtAit6xD7+qld/ttVUnVMx UmgbX8yXg5brWey11f49P9adN/tA0yYlluKMREMt5qLiRABp1MMPOgIAAA== Archived-At: Cc: perc@ietf.org Subject: Re: [Perc] Comments on draft-westerlund-perc-webrtc-use-case-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 16:49:39 -0000 Eric Rescorla skrev den 2015-07-14 18:22: > > The media confidentiality (isolation) mode that is enabled by the > ALPN tag "c-webrtc" as described in: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-alpn/ > > > I don't see how this solves the problem. The issue is that from the > browser's perspective, > the DTLS connection is to the MDD, so how does he know what the MDD is > doing with > the data? Sorry, for not being explicit enough. The UA that is establishing an PeerConnection with end-to-end security, must locally apply the media isolation to all media it sends. The media it receives from a PeerConnection using E2E security must also be isolated. It could be allowed to be forwarded, but if and only if the outgoing PeerConnection applies E2E security using a group key from the same KMF instance. I think it might be simpler to have the whole context being locked into isolation mode for all media streams when an E2E security PeerConnection is created. This is independent of use keying mechanism, and will apply also if the group key is done by DTLS. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jul 14 09:51:50 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F631A8A11 for ; Tue, 14 Jul 2015 09:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rT1M6_kcMAj4 for ; Tue, 14 Jul 2015 09:51:48 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A90F1A897F for ; Tue, 14 Jul 2015 09:51:48 -0700 (PDT) X-AuditID: c1b4fb25-f79046d000007f53-c1-55a53e228bb5 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D4.E1.32595.22E35A55; Tue, 14 Jul 2015 18:51:46 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.210.2; Tue, 14 Jul 2015 18:51:45 +0200 Message-ID: <55A53E22.8050107@ericsson.com> Date: Tue, 14 Jul 2015 18:51:46 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell , Eric Rescorla , , References: <55A4D07F.3040403@cs.tcd.ie> In-Reply-To: <55A4D07F.3040403@cs.tcd.ie> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsUyM+Jvja6S3dJQg7vTNSxmXfnJZrHi9Tl2 i9ULpzNaTN97jd2BxWNt91U2jyVLfjJ5TH7cxuzx5fJntgCWKC6blNSczLLUIn27BK6M9zub mAqauCsOrtnM1sD4jqOLkZNDQsBE4uiM9+wQtpjEhXvr2boYuTiEBI4ySkxY+ooRwlnOKPFh 40cmkCpeAW2J4x93g9ksAqoSzZtaWUFsNgELiZs/GtlAbFGBKImpj9exQNQLSpyc+YQFZJCI wHRGieNTG8HWCQu4Srz6cRusWUggV2JO3ySwOKeApsSp0x1AcQ4OZgF7iQdby0DCzALyEs1b ZzNDlGtLNDR1sE5gFJiFZMUshI5ZSDoWMDKvYhQtTi1Oyk03MtZLLcpMLi7Oz9PLSy3ZxAgM 34NbfqvuYLz8xvEQowAHoxIPr0LuklAh1sSy4srcQ4zSHCxK4rwzNueFCgmkJ5akZqemFqQW xReV5qQWH2Jk4uCUamAU2/Bnn/3LeY8XLZt6J0Tx9/w5DUksS33V9+vnykb2Cq+O3Lr41uol Xs8+/57vmn64pT257+2k6s5332c73Ls+a9PNJ+bTVzyRP5IX+rh2b8q7YGXRt+uerdubf4Zf Outd/gR/hkUVrqsmmrMyb1Lb2LDimJIYS/PCwIaw2pmXrqvGJFf4BrwSU2Ipzkg01GIuKk4E AK3qPk9AAgAA Archived-At: Subject: Re: [Perc] Review of draft-jones-perc-private-media-reqts-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 16:51:50 -0000 Stephen Farrell skrev den 2015-07-14 11:03: > > Hiya, > > On 12/07/15 22:36, Eric Rescorla wrote: >> >> - The KMF knows the number of participants in the call, but >> nothing prevents the CPS from injecting an extra participant >> since the KMF has no expectation of the caller's identities. > > I'm not sure I've got all the context here but if perc conference > calls allow properly implemented infrastructure nodes to add a > silent monitoring participant without any of the other call > participants being able to detect that then I'd say we're not > meeting the chartered goals. The MDD can always forward copies of the end-to-end protected media to a recording device or store it locally. But, the E2E encryption is there to protect the confidentiality. The whole issue resides around ensuring that only invited participants are getting access to the E2E keying material. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jul 14 09:53:33 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF6D1A1EF6 for ; Tue, 14 Jul 2015 09:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iU806d7QJsx for ; Tue, 14 Jul 2015 09:53:30 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3131A8A48 for ; Tue, 14 Jul 2015 09:53:30 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so19514745wic.1 for ; Tue, 14 Jul 2015 09:53:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=dH9YeUkgGyaWNIKPrlw/kWSBxris9+VnPUPmeF3RJ64=; b=ZeFPDbME+1DF/BmQX3quqhDtuTvqgtsrrTd0qOg3irpmgvPBE5gHrQ6siTNBVkQQWK trGnUXqD7TGBfWwyMJJZdm4t2LrlqIHKtLdEvsoBxzGMSa7JA2+pw9gs1M9Pz+bjP1CY Wd0kZpqZQ2GwxIAMGl6gHb0V2YueJdl9o7po48WtZZNXO12BesIC4D5P0haOF2SUeNKq LlNRs2BL2yGH0yUoxnht/46NaSJJ+hTP5ffyq6XST4YGtKZ9cQibKcbp7z4JBUm3/fur BpWGC1EOJCFilo5+mwrtTiqDltVLcIniL6zPdEYG2mp03wK7LVy2zp853d+nbMigLpJ6 1qMA== X-Gm-Message-State: ALoCoQluDHQ97ftvpVwfbv+ZJgq8rTeFF0ENJ+pR3dA2/bqd26HMbHeQvgSHXqO+omWLMjySqPFM X-Received: by 10.180.87.168 with SMTP id az8mr22500890wib.53.1436892809085; Tue, 14 Jul 2015 09:53:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Tue, 14 Jul 2015 09:52:49 -0700 (PDT) In-Reply-To: <55A53D9E.1040806@ericsson.com> References: <55A4C866.3060101@ericsson.com> <55A50A34.9070506@ericsson.com> <55A53D9E.1040806@ericsson.com> From: Eric Rescorla Date: Tue, 14 Jul 2015 09:52:49 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=90e6ba181b827756e1051ad8ad99 Archived-At: Cc: perc@ietf.org Subject: Re: [Perc] Comments on draft-westerlund-perc-webrtc-use-case-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 16:53:32 -0000 --90e6ba181b827756e1051ad8ad99 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 14, 2015 at 9:49 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Eric Rescorla skrev den 2015-07-14 18:22: > >> >> The media confidentiality (isolation) mode that is enabled by the >> ALPN tag "c-webrtc" as described in: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-alpn/ >> >> >> I don't see how this solves the problem. The issue is that from the >> browser's perspective, >> the DTLS connection is to the MDD, so how does he know what the MDD is >> doing with >> the data? >> > > Sorry, for not being explicit enough. The UA that is establishing an > PeerConnection with end-to-end security, must locally apply the media > isolation to all media it sends. The media it receives from a > PeerConnection using E2E security must also be isolated. It could be > allowed to be forwarded, but if and only if the outgoing PeerConnection > applies E2E security using a group key from the same KMF instance. I thin= k > it might be simpler to have the whole context being locked into isolation > mode for all media streams when an E2E security PeerConnection is created= . > > This is independent of use keying mechanism, and will apply also if the > group key is done by DTLS. I'm still not sure how this addresses the problem. In ordinary E2E calls with Identity, you are told who the counterparty who will be receiving the media is in the permissions prompt and this is all bound to DTLS. In this case, however, as the DTLS connection is to the MDD, it will show the MDD's identity. -Ekr Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --90e6ba181b827756e1051ad8ad99 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 14, 2015 at 9:49 AM, Magnus Westerlund &l= t;magnu= s.westerlund@ericsson.com> wrote:
Eric Rescorla skrev den 2015-07-14 18:22:

=C2=A0 =C2=A0 The media confidentiality (isolation) mode that is enabled by= the
=C2=A0 =C2=A0 ALPN tag "c-webrtc" as described in:
=C2=A0 =C2=A0 https://datatracker.ietf.org/d= oc/draft-ietf-rtcweb-alpn/


I don't see how this solves the problem. The issue is that from the
browser's perspective,
the DTLS connection is to the MDD, so how does he know what the MDD is
doing with
the data?

 Sorry, for not being explicit enough. The UA that is establishing an PeerCo= nnection with end-to-end security, must locally apply the media isolation t= o all media it sends. The media it receives from a PeerConnection using E2E= security must also be isolated. It could be allowed to be forwarded, but i= f and only if the outgoing PeerConnection applies E2E security using a grou= p key from the same KMF instance. I think it might be simpler to have the w= hole context being locked into isolation mode for all media streams when an= E2E security PeerConnection is created.

This is independent of use keying mechanism, and will apply also if the gro= up key is done by DTLS.

I'm still not s= ure how this addresses the problem.

In ordinary E2= E calls with Identity, you are told who the counterparty who will
be receiving the media is in the permissions prompt and this is all bound = to DTLS.
In this case, however, as the DTLS connection is to the = MDD, it will show the MDD's
identity.

-Ekr

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--90e6ba181b827756e1051ad8ad99-- From nobody Tue Jul 14 10:04:33 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F24041A8A6B for ; Tue, 14 Jul 2015 10:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZskrHqMnTlzz for ; Tue, 14 Jul 2015 10:04:30 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22D741A90BC for ; Tue, 14 Jul 2015 10:04:28 -0700 (PDT) X-AuditID: c1b4fb3a-f79356d000006281-62-55a5411b64a1 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 8E.5A.25217.B1145A55; Tue, 14 Jul 2015 19:04:27 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.210.2; Tue, 14 Jul 2015 19:04:26 +0200 Message-ID: <55A5411A.4080306@ericsson.com> Date: Tue, 14 Jul 2015 19:04:26 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Eric Rescorla References: <55A4C866.3060101@ericsson.com> <55A50A34.9070506@ericsson.com> <55A53D9E.1040806@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM+Jvja6049JQg607pSxWvD7HbrF64XRG ByaPJUt+MnlMftzGHMAUxWWTkpqTWZZapG+XwJWxedc55oIPohVHP39lbWA8J9DFyMkhIWAi cXvKc1YIW0ziwr31bF2MXBxCAkcZJbY23meBcJYzSmyY/AEow8HBK6At0bVYDKSBRUBVYvK3 uUwgNpuAhcTNH41sILaoQJTE1MfrWEBsXgFBiZMzn4DZIgIKEr/+nACzmQWEJd6tWscMYgsL eEhMmfODGWLXfyaJCTc/gSU4BQIlHh+ayQTRYCExc/55RghbXqJ562ywGiGgexqaOlgnMArO QrJvFpKWWUhaFjAyr2IULU4tLs5NNzLSSy3KTC4uzs/Ty0st2cQIDNiDW35b7WA8+NzxEKMA B6MSD69C7pJQIdbEsuLK3EOM0hwsSuK8MzbnhQoJpCeWpGanphakFsUXleakFh9iZOLglGpg VJx6ua0p/umBIiU1oX18qx0tdx9l+rBohtkfR6aTe/RiNr4xntq7h9X0wovduhN3SRn6+H1+ v+38N+n5Z0+v+7rx2lvhmDdL5jbvMjtbEJasnX1TqN9iUf0CBrPrvvtX/TFO0XF75dd9z827 eM663uTjWgt1wg4FF+v+D9/KGft9+oV+T8azhkosxRmJhlrMRcWJAJpNJr45AgAA Archived-At: Cc: perc@ietf.org Subject: Re: [Perc] Comments on draft-westerlund-perc-webrtc-use-case-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 17:04:32 -0000 Eric Rescorla skrev den 2015-07-14 18:52: > > > On Tue, Jul 14, 2015 at 9:49 AM, Magnus Westerlund > > > wrote: > > Eric Rescorla skrev den 2015-07-14 18:22: > > > The media confidentiality (isolation) mode that is enabled > by the > ALPN tag "c-webrtc" as described in: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-alpn/ > > > I don't see how this solves the problem. The issue is that from the > browser's perspective, > the DTLS connection is to the MDD, so how does he know what the > MDD is > doing with > the data? > > > Sorry, for not being explicit enough. The UA that is establishing an > PeerConnection with end-to-end security, must locally apply the > media isolation to all media it sends. The media it receives from a > PeerConnection using E2E security must also be isolated. It could be > allowed to be forwarded, but if and only if the outgoing > PeerConnection applies E2E security using a group key from the same > KMF instance. I think it might be simpler to have the whole context > being locked into isolation mode for all media streams when an E2E > security PeerConnection is created. > > This is independent of use keying mechanism, and will apply also if > the group key is done by DTLS. > > > I'm still not sure how this addresses the problem. > > In ordinary E2E calls with Identity, you are told who the counterparty > who will > be receiving the media is in the permissions prompt and this is all > bound to DTLS. > In this case, however, as the DTLS connection is to the MDD, it will > show the MDD's > identity. > Okay, we appear to be talking past each other and likely are not talking about the same security issue / problem. I am talking an WebRTC issue related issue, of how you prevent the media content to be compromised by the JS running in the WebRTC Endpoint. This include both local analysis as well as getting it off the endpoint so that an attacker controlling the JS can get to a plain text version of the content at some other endpoint. So what problem are you talking about? Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jul 14 10:12:37 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C371A8A54 for ; Tue, 14 Jul 2015 10:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxUTjVdIBF09 for ; Tue, 14 Jul 2015 10:12:34 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 147E91A0404 for ; Tue, 14 Jul 2015 10:12:33 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so19926471wic.1 for ; Tue, 14 Jul 2015 10:12:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=YvuGxGTYhrrKP4ofeKi/jmONJAzXAsIMtozWIe7DaAg=; b=O7slhVTEhg6GSYJyPHEuJjwhfVAYDODcFXryhbk5QtWBd6ugQ8ghjQLkoQw3VBOT9w 5V2tlwkV1jPwQZhQjED2l89pTa1OZ9lXck050UZciYB9yKiYKWiyZFRAGkbkj1ZY6TZ5 6nX7GJIwfADyST7axt9knfuEWEd634L3MKBudmzGXZr/aEVeF5JtlVmJjnoqha8jdmKf Ncz6fiht9X0WFebWYp5h5OYF+bl6xU0sIueFgUhZyDTo2Lh+UlNIsEjCNIy+xSyhib1X V2A2Xmzrt8j4pYmwl/thSDLWxtvYR87ftB5lmknLi3Cl0X5wY8c7JeZaiPKqHWeAN7Ck bykg== X-Gm-Message-State: ALoCoQn/PI0PMHbfKV9a0bGntbkZqSu1ieMXNwFXtgv5PavL/bxpY5fyhLEzf3adl55z0lS0I62f X-Received: by 10.180.14.200 with SMTP id r8mr7599546wic.53.1436893951882; Tue, 14 Jul 2015 10:12:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Tue, 14 Jul 2015 10:11:52 -0700 (PDT) In-Reply-To: <55A5411A.4080306@ericsson.com> References: <55A4C866.3060101@ericsson.com> <55A50A34.9070506@ericsson.com> <55A53D9E.1040806@ericsson.com> <55A5411A.4080306@ericsson.com> From: Eric Rescorla Date: Tue, 14 Jul 2015 10:11:52 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=f46d040f9f3e950c3c051ad8f126 Archived-At: Cc: perc@ietf.org Subject: Re: [Perc] Comments on draft-westerlund-perc-webrtc-use-case-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 17:12:36 -0000 --f46d040f9f3e950c3c051ad8f126 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 14, 2015 at 10:04 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Eric Rescorla skrev den 2015-07-14 18:52: > >> >> >> On Tue, Jul 14, 2015 at 9:49 AM, Magnus Westerlund >> > >> >> wrote: >> >> Eric Rescorla skrev den 2015-07-14 18:22: >> >> >> The media confidentiality (isolation) mode that is enabled >> by the >> ALPN tag "c-webrtc" as described in: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-alpn/ >> >> >> I don't see how this solves the problem. The issue is that from >> the >> browser's perspective, >> the DTLS connection is to the MDD, so how does he know what the >> MDD is >> doing with >> the data? >> >> >> Sorry, for not being explicit enough. The UA that is establishing an >> PeerConnection with end-to-end security, must locally apply the >> media isolation to all media it sends. The media it receives from a >> PeerConnection using E2E security must also be isolated. It could be >> allowed to be forwarded, but if and only if the outgoing >> PeerConnection applies E2E security using a group key from the same >> KMF instance. I think it might be simpler to have the whole context >> being locked into isolation mode for all media streams when an E2E >> security PeerConnection is created. >> >> This is independent of use keying mechanism, and will apply also if >> the group key is done by DTLS. >> >> >> I'm still not sure how this addresses the problem. >> >> In ordinary E2E calls with Identity, you are told who the counterparty >> who will >> be receiving the media is in the permissions prompt and this is all >> bound to DTLS. >> In this case, however, as the DTLS connection is to the MDD, it will >> show the MDD's >> identity. >> >> > Okay, we appear to be talking past each other and likely are not talking > about the same security issue / problem. > > I am talking an WebRTC issue related issue, of how you prevent the media > content to be compromised by the JS running in the WebRTC Endpoint. This > include both local analysis as well as getting it off the endpoint so that > an attacker controlling the JS can get to a plain text version of the > content at some other endpoint. > > So what problem are you talking about? The same problem. As I understand it, the desired behavior in your model is that the user consents to media access with an identity tied to the MDD (because he is going to set up a DTLS connection to the MDD). The UA then contacts the KMF and gets the EKT key which it somehow attaches to the PC. Is that correct? -Ekr --f46d040f9f3e950c3c051ad8f126 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 14, 2015 at 10:04 AM, Magnus Westerlund &= lt;magn= us.westerlund@ericsson.com> wrote:
Eric Rescorla skrev den 2015-07-14 18:52:


On Tue, Jul 14, 2015 at 9:49 AM, Magnus Westerlund
 <mag= nus.westerlund@ericsson.com <mailto:magnus.westerlund@ericsson.com>&= gt;

wrote:

=C2=A0 =C2=A0 Eric Rescorla skrev den 2015-07-14 18:22:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The media confidentiality (= isolation) mode that is enabled
=C2=A0 =C2=A0 =C2=A0 =C2=A0 by the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ALPN tag "c-webrtc&quo= t; as described in:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatrac= ker.ietf.org/doc/draft-ietf-rtcweb-alpn/


=C2=A0 =C2=A0 =C2=A0 =C2=A0 I don't see how this solves the problem. Th= e issue is that from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 browser's perspective,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the DTLS connection is to the MDD, so how does = he know what the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MDD is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 doing with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the data?


=C2=A0 =C2=A0 Sorry, for not being explicit enough. The UA that is establis= hing an
=C2=A0 =C2=A0 PeerConnection with end-to-end security, must locally apply t= he
=C2=A0 =C2=A0 media isolation to all media it sends. The media it receives = from a
=C2=A0 =C2=A0 PeerConnection using E2E security must also be isolated. It c= ould be
=C2=A0 =C2=A0 allowed to be forwarded, but if and only if the outgoing
=C2=A0 =C2=A0 PeerConnection applies E2E security using a group key from th= e same
=C2=A0 =C2=A0 KMF instance. I think it might be simpler to have the whole c= ontext
=C2=A0 =C2=A0 being locked into isolation mode for all media streams when a= n E2E
=C2=A0 =C2=A0 security PeerConnection is created.

=C2=A0 =C2=A0 This is independent of use keying mechanism, and will apply a= lso if
=C2=A0 =C2=A0 the group key is done by DTLS.


I'm still not sure how this addresses the problem.

In ordinary E2E calls with Identity, you are told who the counterparty
who will
be receiving the media is in the permissions prompt and this is all
bound to DTLS.
In this case, however, as the DTLS connection is to the MDD, it will
show the MDD's
identity.


Okay, we appear to be talking past each other and likely are not talking ab= out the same security issue / problem.

I am talking an WebRTC issue related issue, of how you prevent the media co= ntent to be compromised by the JS running in the WebRTC Endpoint. This incl= ude both local analysis as well as getting it off the endpoint so that an a= ttacker controlling the JS can get to a plain text version of the content a= t some other endpoint.

So what problem are you talking about?

The = same problem.

As I understand it, the desired beha= vior in your model is that the user consents to media access with
an identity tied to the MDD (because he is going to set up a DTLS connecti= on to
the MDD). The UA then contacts the KMF and gets the EKT key= which it somehow
attaches to the PC. Is that correct?
=
-Ekr

--f46d040f9f3e950c3c051ad8f126-- From nobody Tue Jul 14 10:28:39 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FE61ACEAF for ; Tue, 14 Jul 2015 10:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id td1FyyoGQqFC for ; Tue, 14 Jul 2015 10:28:36 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A7021ACE30 for ; Tue, 14 Jul 2015 10:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2452; q=dns/txt; s=iport; t=1436894916; x=1438104516; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZnEVECHMV5HctqrbVu/ovyhgdFCd33H0GxlwmsexDJA=; b=ZN+ySXIWJU0LvWNnRtWSsaPKU8aAuyzqYlUkYV/9D+4s2tzMG0mptwfx Ayy6rQl9sP508BIFPfAxdbEsr6141wBtFVjTVo0I5O4YuDK8s5r54XoTu 72lpPBxjtKOnrfI0lq3+Y0+tzSR6RaN1WuwHuPihHZMvuFLWSV0RJ0dmR w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A2BQApRqVV/4YNJK1bgxOBPQbDQgKBTDsRAQEBAQEBAYEKhCMBAQEEDFwRDAICAgEIEQQBAQEKHQcbFxQJCAIEAQ0FCIglAc82AQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSLSIRVMQcGgxGBFAWHCYVbh04BjUWTT4NfJoN7b4FHgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,473,1432598400"; d="scan'208";a="9710812" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-7.cisco.com with ESMTP; 14 Jul 2015 17:28:35 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t6EHSZeN019769 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Jul 2015 17:28:35 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.25]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Tue, 14 Jul 2015 12:28:34 -0500 From: "David Benham (dbenham)" To: Magnus Westerlund , Stephen Farrell , "perc@ietf.org" Thread-Topic: [Perc] Review of draft-jones-perc-private-media-reqts-00 Thread-Index: AQHQvOr/Mnph97IUaU2sJjzSN5/9H53bAgaAgACCsgCAAApBwA== Date: Tue, 14 Jul 2015 17:28:33 +0000 Message-ID: <0683D6CB32AC424D8AF52C0F660E5DC56BA2749B@xmb-aln-x10.cisco.com> References: <55A4D07F.3040403@cs.tcd.ie> <55A53E22.8050107@ericsson.com> In-Reply-To: <55A53E22.8050107@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.20.230] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-jones-perc-private-media-reqts@tools.ietf.org" Subject: Re: [Perc] Review of draft-jones-perc-private-media-reqts-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 17:28:37 -0000 Magnus beat me to the reply, so I'll just pile on to say that this is actua= lly an excellent case in which to claim victory eventually. =20 In other words, we should assume an admin turned bad actor can and will, as= they can today, configure an MDD not in the trusted domain (cloud conf pro= vider or IaaS, etc) to send copies of all your conf's packets to another pa= rticipant (eg, a capture device) without the rest of the legitimate partici= pants knowing. PERC will preserve the privacy of the media content despit= e such eavesdropping capture as the KMS would not provide E2E key material = to that device. > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Tuesday, July 14, 2015 9:52 AM > To: Stephen Farrell; Eric Rescorla; perc@ietf.org; draft-jones-perc-priva= te- > media-reqts@tools.ietf.org > Subject: Re: [Perc] Review of draft-jones-perc-private-media-reqts-00 >=20 > Stephen Farrell skrev den 2015-07-14 11:03: > > Hiya, > > > > On 12/07/15 22:36, Eric Rescorla wrote: > >> > >> - The KMF knows the number of participants in the call, but > >> nothing prevents the CPS from injecting an extra participant > >> since the KMF has no expectation of the caller's identities. > > > > I'm not sure I've got all the context here but if perc conference > > calls allow properly implemented infrastructure nodes to add a > > silent monitoring participant without any of the other call > > participants being able to detect that then I'd say we're not > > meeting the chartered goals. >=20 > The MDD can always forward copies of the end-to-end protected media to a > recording device or store it locally. But, the E2E encryption is there > to protect the confidentiality. >=20 > The whole issue resides around ensuring that only invited participants > are getting access to the E2E keying material. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 From nobody Tue Jul 14 11:05:11 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79691AD1F5 for ; Tue, 14 Jul 2015 11:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciSbw6FL5IBf for ; Tue, 14 Jul 2015 11:05:09 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4A7D1AD1DB for ; Tue, 14 Jul 2015 11:05:08 -0700 (PDT) Received: by ykax123 with SMTP id x123so15142765yka.1 for ; Tue, 14 Jul 2015 11:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8qQIBvZNkTpgtDnRlHfX+3lzOeHrhsCG5CjYWlytRGw=; b=xHpPwBHYJOg+GBUB2ocOHba46T92WVjYXtmnXh6HZ3yJIPsYdVQR2sTG9sE4A/1OIe TEnfdKtCfjXSb2QCunXHRCs+69ocLv+1jFmi9/izLOcAXXOB8tcizS2mY8VQlLuHzPV7 Ws0ftOlRJaqdeZtVTLLC8pnedN91MPRf4ihMaCn/DupdrCT1gG7UbTXz8QUIk0YNQPjJ oIsfJolPdQf93/5TmQBOGqdSwk5w1TgyJg1fIfB3EJopqxdRyNIILRKBXBq8KDgbMpis KCp/s2hV96R8Rtql5mShVsj9yrTgzU30/myy43cBa3CfGpcwHWzLGHvCHjca0/MBtlsR 3WTA== MIME-Version: 1.0 X-Received: by 10.13.216.210 with SMTP id a201mr14961859ywe.89.1436897108220; Tue, 14 Jul 2015 11:05:08 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Tue, 14 Jul 2015 11:05:08 -0700 (PDT) In-Reply-To: References: <55A4C866.3060101@ericsson.com> <55A50A34.9070506@ericsson.com> <55A53D9E.1040806@ericsson.com> <55A5411A.4080306@ericsson.com> Date: Tue, 14 Jul 2015 11:05:08 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Magnus Westerlund , perc@ietf.org Subject: Re: [Perc] Comments on draft-westerlund-perc-webrtc-use-case-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 18:05:11 -0000 I can imagine several arrangements, but I think that the one Magnus envisages here is one where you connect to the MDD with DTLS-SRTP, but don't transmit media through that connection until you learn the group key from the KMF and can properly encipher toward the group. With the aim to making the MDD equivalent to any other on-path adversary with respect to media confidentiality. This is not described particularly well in the draft. Furthermore, I think that we would need some new system of peer identification to support it. The biggest concern I have here is that the KMF role can't be assumed by one of the conference participants, at least as specified. I can imagine being able to use data channels in some new way to support that function, but then we have something (again) fundamentally different. On 14 July 2015 at 10:11, Eric Rescorla wrote: > > > On Tue, Jul 14, 2015 at 10:04 AM, Magnus Westerlund > wrote: >> >> Eric Rescorla skrev den 2015-07-14 18:52: >>> >>> >>> >>> On Tue, Jul 14, 2015 at 9:49 AM, Magnus Westerlund >>> > >>> >>> wrote: >>> >>> Eric Rescorla skrev den 2015-07-14 18:22: >>> >>> >>> The media confidentiality (isolation) mode that is enabled >>> by the >>> ALPN tag "c-webrtc" as described in: >>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-alpn/ >>> >>> >>> I don't see how this solves the problem. The issue is that from >>> the >>> browser's perspective, >>> the DTLS connection is to the MDD, so how does he know what the >>> MDD is >>> doing with >>> the data? >>> >>> >>> Sorry, for not being explicit enough. The UA that is establishing an >>> PeerConnection with end-to-end security, must locally apply the >>> media isolation to all media it sends. The media it receives from a >>> PeerConnection using E2E security must also be isolated. It could be >>> allowed to be forwarded, but if and only if the outgoing >>> PeerConnection applies E2E security using a group key from the same >>> KMF instance. I think it might be simpler to have the whole context >>> being locked into isolation mode for all media streams when an E2E >>> security PeerConnection is created. >>> >>> This is independent of use keying mechanism, and will apply also if >>> the group key is done by DTLS. >>> >>> >>> I'm still not sure how this addresses the problem. >>> >>> In ordinary E2E calls with Identity, you are told who the counterparty >>> who will >>> be receiving the media is in the permissions prompt and this is all >>> bound to DTLS. >>> In this case, however, as the DTLS connection is to the MDD, it will >>> show the MDD's >>> identity. >>> >> >> Okay, we appear to be talking past each other and likely are not talking >> about the same security issue / problem. >> >> I am talking an WebRTC issue related issue, of how you prevent the media >> content to be compromised by the JS running in the WebRTC Endpoint. This >> include both local analysis as well as getting it off the endpoint so that >> an attacker controlling the JS can get to a plain text version of the >> content at some other endpoint. >> >> So what problem are you talking about? > > > The same problem. > > As I understand it, the desired behavior in your model is that the user > consents to media access with > an identity tied to the MDD (because he is going to set up a DTLS connection > to > the MDD). The UA then contacts the KMF and gets the EKT key which it somehow > attaches to the PC. Is that correct? > > -Ekr > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > From nobody Tue Jul 14 11:12:26 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21AE1AD36E for ; Tue, 14 Jul 2015 11:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uThPRFtKSmp9 for ; Tue, 14 Jul 2015 11:12:23 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11D061AD369 for ; Tue, 14 Jul 2015 11:12:22 -0700 (PDT) X-AuditID: c1b4fb2d-f79176d00000321c-fe-55a55105c353 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AA.C9.12828.50155A55; Tue, 14 Jul 2015 20:12:21 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.210.2; Tue, 14 Jul 2015 20:12:20 +0200 Message-ID: <55A55104.8060403@ericsson.com> Date: Tue, 14 Jul 2015 20:12:20 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Eric Rescorla References: <55A4BBF7.4060107@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM+JvjS5r4NJQgztL5CxmXfnJZrHi9Tl2 i/MXNjBZrF44ndGBxWPJkp9MHg37jrJ7TH7cxuzx5fJntgCWKC6blNSczLLUIn27BK6MhQt0 CmZLV+x7/outgXGraBcjB4eEgInElC/1XYycQKaYxIV769m6GLk4hASOMkq0LNzKAuEsZ5R4 +nQ1C0gVr4C2RMs1kCpODhYBVYkHu+8xg9hsAhYSN380gsVFBaIkpj5eB1UvKHFy5hMwW0RA QeLXnxNgNrNAqUT75GVg9cICrhKvftxmhVi2gFFi3p/FYEM5BQIlJsy6zAzRYCExc/55Rghb XqJ562ywuBDQQQ1NHawTGAVnIdk3C0nLLCQtCxiZVzGKFqcWF+emGxnrpRZlJhcX5+fp5aWW bGIEhvXBLb91dzCufu14iFGAg1GJh1chd0moEGtiWXFl7iFGaQ4WJXHeGZvzQoUE0hNLUrNT UwtSi+KLSnNSiw8xMnFwSjUw8m17Yc3y8/pxq3XTLG5I/qsV3JbRet1vCtcy7bnq0cl2za7l z+T1HJTXzXp6OY11g8+XwGfOL9RKfv3iCSuarHqiTabedONyAfO9D0XuX80X2WAbIJr6Yd6r bd/fLTuZoPfCLKHJmkOkfEnPDKMMLsXpf4utI5UduD4xuTfqt/F98uFlLX6pxFKckWioxVxU nAgAdi85PUwCAAA= Archived-At: Cc: "Paul E. Jones" , perc@ietf.org, draft-jones-perc-private-media-reqts@tools.ietf.org Subject: Re: [Perc] Review of draft-jones-perc-private-media-reqts-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 18:12:25 -0000 Eric Rescorla skrev den 2015-07-14 15:03: > > > On Tue, Jul 14, 2015 at 12:36 AM, Magnus Westerlund > > > Regarding these two bullets, I think we do need to aim at the > security level that no one that can't assert an identity towards the > KMF that the inviter in the conference has included in the > conference invitation/rooster can retrieve the key. That > verification can't be dune by the CPS, it needs to be part of the > KMF or a stand alone but trusted entity. > > >From a functional perspective the conference inviter will schedule > a conference and create a rooster with identity. At the time of > joining the conference the participant needs to assert its identity > to the KMF. If that is done by talking to a secure rooster server > that generates some credentials bound to the participants endpoint, > and those are used to assert the identity when talking to the KMF, > that is an open question. I have a tendency to favour the second as > that will reduce the API surface on the KMF, and separate the > authorization of the participant to this separate function, which > then can be a bit more flexible to integrate the various identity > systems used. > > > As far as I know, standardizing the control plane communication between > the KM > and the CPS is out of scope for this effort, right? So it certainly > should be possible > that the KMF will have an independent way of knowing which identities > should be > allowed into the conference, but it's not something we are required to > design. > And there are certainly valid designs where you don't provide this. Even if something is out of scope for standardizing it may not be out of scope to put requirement on the need for a particular functionality. My main point is that the system as a whole need to ensure that only intended participants is capable of joining a particular conference. That we do need a solution for! You might have additional ideas for this, but I have so far only thought of two ways of doing it. The first alternative is to provided the invited party with a secret. However that requires that you can safely distribute it to the invited party, and likely require them to store it confidential until the participant selects to join the conference. Something that is fairly difficult and vulnerable. The second alternative is that the invited need to assert an identity toward the trusted part of the system. If that assertion is accepted then one give the participant's endpoint access to the conference group key. And I have only semi trust in CPS and MDD. I only trust it as far as not preventing my conference from working, but I will not give it any way of compromising the confidentiality of the media content. It can clearly affect the view a particular conference Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jul 14 11:15:23 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41871AD369 for ; Tue, 14 Jul 2015 11:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.977 X-Spam-Level: X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBBHtt-u94nm for ; Tue, 14 Jul 2015 11:15:19 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E561AD289 for ; Tue, 14 Jul 2015 11:15:19 -0700 (PDT) Received: by wgxm20 with SMTP id m20so15138782wgx.3 for ; Tue, 14 Jul 2015 11:15:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=WAbwNLRc02dN3/6Z+VGeGiko3unUOCS7lhHfyT6ArF4=; b=bMBDG9asjwQtOqli6DWsxQFXSh0Dr+UXmk/JJ0S/2IYsg9i2YgHd7j/VKXshwIUzxk TZDL0yg/mCwPP1zbSthLW3pgutwf6wVGvcg5BGRDa8typVC8lCSs6gmT3NAYHb4NLcMg EsUlqehWopJf8VkvaOVO9p/9nk1EuIk+usi1Q/bwfXTdB2bRLTSwQgXFhbs6Mvja5AVz poQTcwS2u8YZt+s2I2RU6AVHzp0n0w5aQHQqODh6emvMOVE6f4Qst+0D2DKOZItYXZV4 nyJYRu1/V9k9iLB6i+gH5NILXaU2eptJhMjSyZYIvd5rYd2z8RPDHxAkDEc6XAc429Cz KX2A== X-Gm-Message-State: ALoCoQkMPoAhrGt+bAib+fF9yRpO8hz/UVBGmSweQg786LUetI9kAIeB6q4EJvOrzXPWjXzXdBDO X-Received: by 10.194.133.73 with SMTP id pa9mr79289082wjb.148.1436897717875; Tue, 14 Jul 2015 11:15:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Tue, 14 Jul 2015 11:14:37 -0700 (PDT) In-Reply-To: <55A55104.8060403@ericsson.com> References: <55A4BBF7.4060107@ericsson.com> <55A55104.8060403@ericsson.com> From: Eric Rescorla Date: Tue, 14 Jul 2015 11:14:37 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=089e011771a90d8c60051ad9d223 Archived-At: Cc: "Paul E. Jones" , perc@ietf.org, draft-jones-perc-private-media-reqts@tools.ietf.org Subject: Re: [Perc] Review of draft-jones-perc-private-media-reqts-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 18:15:22 -0000 --089e011771a90d8c60051ad9d223 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 14, 2015 at 11:12 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Eric Rescorla skrev den 2015-07-14 15:03: > >> >> >> On Tue, Jul 14, 2015 at 12:36 AM, Magnus Westerlund >> > >> > > Regarding these two bullets, I think we do need to aim at the >> security level that no one that can't assert an identity towards the >> KMF that the inviter in the conference has included in the >> conference invitation/rooster can retrieve the key. That >> verification can't be dune by the CPS, it needs to be part of the >> KMF or a stand alone but trusted entity. >> >> >From a functional perspective the conference inviter will schedule >> a conference and create a rooster with identity. At the time of >> joining the conference the participant needs to assert its identity >> to the KMF. If that is done by talking to a secure rooster server >> that generates some credentials bound to the participants endpoint, >> and those are used to assert the identity when talking to the KMF, >> that is an open question. I have a tendency to favour the second as >> that will reduce the API surface on the KMF, and separate the >> authorization of the participant to this separate function, which >> then can be a bit more flexible to integrate the various identity >> systems used. >> >> >> As far as I know, standardizing the control plane communication between >> the KM >> and the CPS is out of scope for this effort, right? So it certainly >> should be possible >> that the KMF will have an independent way of knowing which identities >> should be >> allowed into the conference, but it's not something we are required to >> design. >> And there are certainly valid designs where you don't provide this. >> > > Even if something is out of scope for standardizing it may not be out of > scope to put requirement on the need for a particular functionality. > > My main point is that the system as a whole need to ensure that only > intended participants is capable of joining a particular conference. That > we do need a solution for! > I don't think that's precisely true. I would say rather that it must be possible to implement a system that way. You might have additional ideas for this, but I have so far only thought of > two ways of doing it. The first alternative is to provided the invited > party with a secret. However that requires that you can safely distribute > it to the invited party, and likely require them to store it confidential > until the participant selects to join the conference. Something that is > fairly difficult and vulnerable. > The second alternative is that the invited need to assert an identity > toward the trusted part of the system. If that assertion is accepted then > one give the participant's endpoint access to the conference group key. > The second is the natural design, since you can use existing public key identity mechanisms for it. -Ekr > And I have only semi trust in CPS and MDD. I only trust it as far as not > preventing my conference from working, but I will not give it any way of > compromising the confidentiality of the media content. It can clearly > affect the view a particular conference > > > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --089e011771a90d8c60051ad9d223 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 14, 2015 at 11:12 AM, Magnus Westerlund &= lt;magn= us.westerlund@ericsson.com> wrote:
Eric Rescorla skrev den 2015-07-14 15:03:


On Tue, Jul 14, 2015 at 12:36 AM, Magnus Westerlund
 <mag= nus.westerlund@ericsson.com <mailto:magnus.westerlund@ericsson.com>&= gt;

=C2=A0 =C2=A0 Regarding these two bullets, I think we do need to aim at the=
=C2=A0 =C2=A0 security level that no one that can't assert an identity = towards the
=C2=A0 =C2=A0 KMF that the inviter in the conference has included in the =C2=A0 =C2=A0 conference invitation/rooster can retrieve the key. That
=C2=A0 =C2=A0 verification can't be dune by the CPS, it needs to be par= t of the
=C2=A0 =C2=A0 KMF or a stand alone but trusted entity.

=C2=A0 =C2=A0 =C2=A0>From a functional perspective the conference invite= r will schedule
=C2=A0 =C2=A0 a conference and create a rooster with identity. At the time = of
=C2=A0 =C2=A0 joining the conference the participant needs to assert its id= entity
=C2=A0 =C2=A0 to the KMF. If that is done by talking to a secure rooster se= rver
=C2=A0 =C2=A0 that generates some credentials bound to the participants end= point,
=C2=A0 =C2=A0 and those are used to assert the identity when talking to the= KMF,
=C2=A0 =C2=A0 that is an open question. I have a tendency to favour the sec= ond as
=C2=A0 =C2=A0 that will reduce the API surface on the KMF, and separate the=
=C2=A0 =C2=A0 authorization of the participant to this separate function, w= hich
=C2=A0 =C2=A0 then can be a bit more flexible to integrate the various iden= tity
=C2=A0 =C2=A0 systems used.


As far as I know, standardizing the control plane communication between
the KM
and the CPS is out of scope for this effort, right? So it certainly
should be possible
that the KMF will have an independent way of knowing which identities
should be
allowed into the conference, but it's not something we are required to<= br> design.
And there are certainly valid designs where you don't provide this.

Even if something is out of scope for standardizing it may not be out of sc= ope to put requirement on the need for a particular functionality.

My main point is that the system as a whole need to ensure that only intend= ed participants is capable of joining a particular conference. That we do n= eed a solution for!

I don't think t= hat's precisely true. I would say rather that it must be possible to=C2= =A0
implement a system that way.


You might have additional ideas for this, but I have so far only thought of= two ways of doing it. The first alternative is to provided the invited par= ty with a secret. However that requires that you can safely distribute it t= o the invited party, and likely require them to store it confidential until= the participant selects to join the conference. Something that is fairly d= ifficult and vulnerable.
The second alternative is that the invited need to assert an identity towar= d the trusted part of the system. If that assertion is accepted then one gi= ve the participant's endpoint access to the conference group key.

The second is the natural design, since you = can use existing public key identity mechanisms
for it.

-Ekr
=C2=A0
And I have only semi trust in CPS and MDD. I only trust it as far as not pr= eventing my conference from working, but I will not give it any way of comp= romising the confidentiality of the media content. It can clearly affect th= e view a particular conference



Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--089e011771a90d8c60051ad9d223-- From nobody Thu Jul 16 05:25:27 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D39C1A898B for ; Thu, 16 Jul 2015 05:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yF9hIJpo0_bV for ; Thu, 16 Jul 2015 05:25:22 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B9031A8909 for ; Thu, 16 Jul 2015 05:25:21 -0700 (PDT) X-AuditID: c1b4fb3a-f79356d000006281-d8-55a7a2afb726 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 88.9F.25217.FA2A7A55; Thu, 16 Jul 2015 14:25:20 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.210.2; Thu, 16 Jul 2015 14:25:19 +0200 Message-ID: <55A7A2AE.404@ericsson.com> Date: Thu, 16 Jul 2015 14:25:18 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Eric Rescorla References: <55A4C866.3060101@ericsson.com> <55A50A34.9070506@ericsson.com> <55A53D9E.1040806@ericsson.com> <55A5411A.4080306@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM+Jvje6GRctDDY4v4bVY8focu8XqhdMZ HZg8liz5yeQx+XEbcwBTFJdNSmpOZllqkb5dAlfGtK2NrAVfBCqWrb/F3sB4gbeLkZNDQsBE YkrzdmYIW0ziwr31bF2MXBxCAkcZJd69vcgC4SxnlPh17Tc7SBWvgLrEtPn9YB0sAqoSa1+/ AYuzCVhI3PzRyAZiiwpESUx9vI4Fol5Q4uTMJ2C2iICCxK8/J8BsZgFhiXer1oHNERbwkJgy 5wczxLInzBK3jn4CGsrBwSkQKLH1RDxEvYXEzPnnGSFseYnmrbPBeoUEtCUamjpYJzAKzkKy bhaSlllIWhYwMq9iFC1OLS7OTTcy0kstykwuLs7P08tLLdnECAzYg1t+W+1gPPjc8RCjAAej Eg+vgsDyUCHWxLLiytxDjNIcLErivDM254UKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYMxe /GOOSUhX+oyWpFyfx/KzX/UddowSLxNZuFAr+i5z+rRX+w32Mp07e6n7Y5cFp6fn93ta3ZGd LW9n7T/JsWFyr3FQXRL7IacfJSdf1L2ZsmCedvzGssjT2h6PU7vsZa2mXD5Qe3mJQPKNJ3li TSv87CWOfVkt4bV0S1LE9zd/CuIkmWpVniixFGckGmoxFxUnAgBltC5AOQIAAA== Archived-At: Cc: perc@ietf.org Subject: Re: [Perc] Comments on draft-westerlund-perc-webrtc-use-case-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 12:25:26 -0000 Eric Rescorla skrev den 2015-07-14 19:11: > > As I understand it, the desired behavior in your model is that the user > consents to media access with > an identity tied to the MDD (because he is going to set up a DTLS > connection to > the MDD). The UA then contacts the KMF and gets the EKT key which it somehow > attaches to the PC. Is that correct? > No. The model we have is that the participant, uses its identity to log into the conference (identified by an URI). Assuming the identity matches the conference rooster as established by the conference inviter, the participant will get credentials back tied to the participant's endpoint. Using these credentials it will do an HTTPS request to the KMF for the conference's group key (EKT master key). It will receive it back using Content Encryption header. The web application gets an key-id. Then the application establish the PeerConnection with the MDD, indicating the identity of the conference. Giving the key-id as the group key to use for this PeerConnection. During the PeerConnection establishment the hop-by-hop will be established. We propose to use new CSP directives given by the origin to force the application to establish PeerConnections using end-to-end security as well as which KMF that is the one to use. Thus, we are not explicitly tying the media to the MDD. We are tying it to the KMF. And the KMF is the one controlling who gets the group key. Assuming that is safe. If you can't get local media off the endpoint within this browser context except by having it end-to-end protected there are no sever consequences of having it sent around. cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Jul 16 06:53:31 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134531B3BD4 for ; Thu, 16 Jul 2015 06:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAmqFqrp2ZKx for ; Thu, 16 Jul 2015 06:53:29 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20C8D1B3BD0 for ; Thu, 16 Jul 2015 06:53:29 -0700 (PDT) Received: by wgmn9 with SMTP id n9so59166491wgm.0 for ; Thu, 16 Jul 2015 06:53:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fvLCZRb7qF1S+N2yBs3XcfB1DdUz+J3dQLqpgZbieDE=; b=bYgpW3lsH0XS+kWUG4Iphs26whYcB8ZZ11u1ri4oBXBKlnYEpv31OPS4qb39tVYTpJ fk8z1k6I5ik9YtVIThSH/Xf8/9HHX08GpuU0OMcH24cAMljJDP34kQ+CyIlFlTiC65If 8pY5cU4k+1d18aD4kBgu77TitPwEoKczNKWWNf/Fko8Tlar1SboqvXtvjNSH3qbJ40dz UyL/PrYPlLKJNcBx+h9gEP5imjTPYHQ2m5k7/AK4Pm+kGR5qm7oK5dKBlGX3+wDML3Qi KUZ962y+hHkdYmXJFJECe7pbCqtsYSt6fJJIufxTEAhYwdwv2Ajcm1mUGq1pP/xd3YYq V3VQ== X-Gm-Message-State: ALoCoQn16lj1Nn8ADmAfwbPY4QjINc6+YeWFBGLK1rjYieLithFIVNUftPMTGYgzh3OYVnpA3xV2 X-Received: by 10.194.79.225 with SMTP id m1mr19619119wjx.8.1437054807885; Thu, 16 Jul 2015 06:53:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Thu, 16 Jul 2015 06:52:48 -0700 (PDT) In-Reply-To: <55A7A2AE.404@ericsson.com> References: <55A4C866.3060101@ericsson.com> <55A50A34.9070506@ericsson.com> <55A53D9E.1040806@ericsson.com> <55A5411A.4080306@ericsson.com> <55A7A2AE.404@ericsson.com> From: Eric Rescorla Date: Thu, 16 Jul 2015 06:52:48 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=047d7b10c90358e4c1051afe658a Archived-At: Cc: perc@ietf.org Subject: Re: [Perc] Comments on draft-westerlund-perc-webrtc-use-case-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 13:53:31 -0000 --047d7b10c90358e4c1051afe658a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jul 16, 2015 at 5:25 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Eric Rescorla skrev den 2015-07-14 19:11: > > >> As I understand it, the desired behavior in your model is that the user >> consents to media access with >> an identity tied to the MDD (because he is going to set up a DTLS >> connection to >> the MDD). The UA then contacts the KMF and gets the EKT key which it >> somehow >> attaches to the PC. Is that correct? >> >> > No. The model we have is that the participant, uses its identity to log > into the conference (identified by an URI). Assuming the identity matches > the conference rooster as established by the conference inviter, the > participant will get credentials back tied to the participant's endpoint. > Using these credentials it will do an HTTPS request to the KMF for the > conference's group key (EKT master key). It will receive it back using > Content Encryption header. The web application gets an key-id. Then the > application establish the PeerConnection with the MDD, indicating the > identity of the conference. Giving the key-id as the group key to use for > this PeerConnection. During the PeerConnection establishment the hop-by-h= op > will be established. We propose to use new CSP directives given by the > origin to force the application to establish PeerConnections using > end-to-end security as well as which KMF that is the one to use. > Hmm... I guess I'd need to see your proposed CSP directives.This seems kind of out of the wheelhouse for WebAppSec though. -Ekr > Thus, we are not explicitly tying the media to the MDD. We are tying it t= o > the KMF. And the KMF is the one controlling who gets the group key. > Assuming that is safe. If you can't get local media off the endpoint with= in > this browser context except by having it end-to-end protected there are n= o > sever consequences of having it sent around. > > cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --047d7b10c90358e4c1051afe658a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jul 16, 2015 at 5:25 AM, Magnus Westerlund &l= t;magnu= s.westerlund@ericsson.com> wrote:
Eric Rescorla skrev den 2015-07-14 19:11:


As I understand it, the desired behavior in your model is that the user
consents to media access with
an identity tied to the MDD (because he is going to set up a DTLS
connection to
the MDD). The UA then contacts the KMF and gets the EKT key which it someho= w
attaches to the PC. Is that correct?


 No. The model we have is that the participant, uses its identity to log int= o the conference (identified by an URI). Assuming the identity matches the = conference rooster as established by the conference inviter, the participan= t will get credentials back tied to the participant's endpoint. Using t= hese credentials it will do an HTTPS request to the KMF for the conference&= #39;s group key (EKT master key). It will receive it back using Content Enc= ryption header. The web application gets an key-id. Then the application es= tablish the PeerConnection with the MDD, indicating the identity of the con= ference. Giving the key-id as the group key to use for this PeerConnection.= During the PeerConnection establishment the hop-by-hop will be established= . We propose to use new CSP directives given by the origin to force the app= lication to establish PeerConnections using end-to-end security as well as = which KMF that is the one to use.

Hmm..= . I guess I'd need to see your proposed CSP directives.This seems kind = of
out of the wheelhouse for WebAppSec though.

-Ekr

=C2=A0
Thus, we are not explicitly tying the media to the MDD. We are tying it to = the KMF. And the KMF is the one controlling who gets the group key. Assumin= g that is safe. If you can't get local media off the endpoint within th= is browser context except by having it end-to-end protected there are no se= ver consequences of having it sent around.

cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--047d7b10c90358e4c1051afe658a-- From nobody Fri Jul 17 02:42:16 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2481B321D for ; Fri, 17 Jul 2015 02:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuQCVrvBgoda for ; Fri, 17 Jul 2015 02:42:13 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDF471B3215 for ; Fri, 17 Jul 2015 02:42:12 -0700 (PDT) X-AuditID: c1b4fb25-f79046d000007f53-e5-55a8cdf2c2bb Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 2B.13.32595.3FDC8A55; Fri, 17 Jul 2015 11:42:11 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.210.2; Fri, 17 Jul 2015 11:42:10 +0200 To: From: Magnus Westerlund Message-ID: <55A8CDF1.2050704@ericsson.com> Date: Fri, 17 Jul 2015 11:42:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGJMWRmVeSWpSXmKPExsUyM+Jvje7nsytCDdrbhCxWL5zO6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMl/5zMWfGSvuLtzFlMD41a2LkZODgkBE4mHz3cxQ9hiEhfu rQeKc3EICRxllHi5ficThLOcUWJb5wV2kCoRAWGJHxcmgtlsAhYSN380gk0SFtCVuP15NVic V0Bb4ufy+YwgNouAqsSDs9NYQWxRgRiJ+SumM0PUCEqcnPmEpYuRg4NZwF7iwdYykDCzgLxE 89bZYCVCQGMamjpYJzDyzULSMQuhYxaSjgWMzKsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYx AgPq4JbfqjsYL79xPMQowMGoxMO7IHFFqBBrYllxZe4hRmkOFiVx3hmb80KFBNITS1KzU1ML Uovii0pzUosPMTJxcEo1MFYm3d+hU7Lx5eOa1O8M894UmVQwL64Q+n3r20qtL++0zpe2nlzZ bZexYU6k2d1/JYsYC78E3oqLXLC+679bCfc8jtOvLEsf52j77bunY2A0YX9me+zUE5vvMUQl /5uS6Gf7Wm6RXo8Mo8/9N0x/pgldmhNf1Tl/8afwxjcB0c/Z8xgnR/k4flViKc5INNRiLipO BAB5Li5BCQIAAA== Archived-At: Subject: [Perc] MDD and codec independent Forwarding X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 09:42:15 -0000 Hi, I just reviewed https://tools.ietf.org/html/draft-aboba-avtcore-sfu-rtp-00 and I think it contains quite a lot of highly relevant information for the participants in the PERC WG. Primarily I think it shows the breath of different behaviour even an SFU can have when forwarding packets. This is something we do need to consider and discuss when it comes to the design of what fields that can be expected to be rewritten by the MDD, and what it might generate and terminate as well as forward. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Jul 17 21:13:28 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9223E1A6FFB for ; Fri, 17 Jul 2015 21:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.112 X-Spam-Level: X-Spam-Status: No, score=-0.112 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8ovrOv2G4Of for ; Fri, 17 Jul 2015 21:13:24 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68B8F1A8715 for ; Fri, 17 Jul 2015 21:13:24 -0700 (PDT) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.14.9/8.14.9) with ESMTP id t6I4DMAF009872 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Jul 2015 00:13:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1437192803; bh=Z9/6+qXOimtXSOdDoqez1NMrCwKELhjQauuFQTtCFc8=; h=From:To:Subject:Cc:Date:In-Reply-To:Reply-To; b=tPWQvfw6Osh5lxHRYkaRjmXv02abE1btemR30w1iUFqLCjLxUNz4RkVvFcSlPgqb9 EDefEtLKNe8+auUtcaAP5h1aDw+2Hb2y4dIzChAYmjeeoEsGCZbmoy3bKTzZejcmSx X59fr7e2Gaoxn0PZThWgqp+NlfNNmVbfdlOexe+0= From: "Paul E. Jones" To: "Eric Rescorla" Date: Sat, 18 Jul 2015 04:13:41 +0000 Message-Id: In-Reply-To: User-Agent: eM_Client/6.0.22344.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB30BD5AA0-5FE1-4509-9B0D-2CA5207357B9" Archived-At: Cc: perc@ietf.org Subject: Re: [Perc] Review of draft-jones-perc-private-media-reqts-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 04:13:26 -0000 --------=_MB30BD5AA0-5FE1-4509-9B0D-2CA5207357B9 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eric, Other text I think we're in agreement on (and need to work on). I did want to respond to your one question. >>>* Section 7.1.2 is confusing when compared to 7.2.3. >>>I think that the issue is that 7.1.2 needs to be rewritten to >>>make clear that the guarantee is that the sending endpoint is >>>part of the group, not that it is a particular endpoint. >> We might want to know that it is a particular endpoint or even a=20 particular human user, and we get this by checking the client=20 certificate and validating it. However, insofar as this goal goes, I=20 think that was the intent. John Mattsson contributed this one, I think.= =20 If you don't have particular suggestions for wording changes, perhaps=20 he might weigh in? That's fine as far as session establishment, but once the session is=20 established everyone knows the sending key for Alice and so can impersonate Alice unless the MDD tags each message with the identity using the H2H key. Is that the plan? There will be a HBH key that is shared between Alice and the MDD. The=20 intent is that the MDD will process the SRTP packets and check for the=20 authentication tag created with that key that is known only to Alice and= =20 the MDD (and the KMF, but we trust it). The MDD will reject any packet=20 that is authenticated with Alice's key and purportedly coming from=20 Alice. When the MDD forwards media, it will re-authenticate the packet using=20 the shared key between itself and Bob (or Carol or ...). Each hop will=20 receive a copy of Alice's packet, each hop being authenticated with that= =20 hop's key. However, there is no particular identifying information that we've=20 proposed to put into Alice's packet so that Bob would know that was=20 originally sourced from Alice. All Bob would know is that an apparently= =20 valid packet is received from the MDD. The endpoint will also check to=20 ensure that any received EKT tag is not corrupted and it will verify=20 that the encrypted payload authenticates with the key associated with=20 the sender's SSRC. Still, Bob does not know the SSRC belongs to Alice=20 or anyone else, is no other identifying info in the packet. And I think= =20 that's OK. We can prevent packet packets coming in from untrusted=20 entities, but we're not trying to prevent a trusted endpoint from being=20 malicious. Paul --------=_MB30BD5AA0-5FE1-4509-9B0D-2CA5207357B9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Eric,
 
Other text I think we're in agreement on (and need to work= on).
 
I did want to respond to your one question.
 
* Section 7.1.2 is confusing when compared to 7.2.3.
I think that the issue is that 7.1.2 needs to be rewritten to
make clear that the guarantee is that the sending endpoint is
part of the group, not that it is a particular endpoint.
 
We might want to know that it is a particular endpoint or even a parti= cular human user, and we get this by checking the client certificate= and validating it.  However, insofar as this goal goes, I think that= was the intent.  John Mattsson contributed this one, I think. = If you don't have particular suggestions for wording changes, perhaps he= might weigh in?

That's fine as far as session establishment, but once the session is= established
everyone knows the sending key for Alice and so can impersonate Alice<= /DIV>
unless the MDD tags each message with the identity using the H2H key.<= /DIV>
Is that the plan?
 
There will be a HBH key that is shared between Alice and the MDD. = ; The intent is that the MDD will process the SRTP packets and check for= the authentication tag created with that key that is known only to Alice= and the MDD (and the KMF, but we trust it).  The MDD will reject any= packet that is authenticated with Alice's key and purportedly coming from= Alice.
 
When the MDD forwards media, it will re-authenticate the packet using= the shared key between itself and Bob (or Carol or ...).  Each hop= will receive a copy of Alice's packet, each hop being authenticated with= that hop's key.
 
However, there is no particular identifying information that we've = proposed to put into Alice's packet so that Bob would know that was origina= lly sourced from Alice.  All Bob would know is that an apparently vali= d packet is received from the MDD.  The endpoint will also check to= ensure that any received EKT tag is not corrupted and it will verify that= the encrypted payload authenticates with the key associated with the sende= r's SSRC.  Still, Bob does not know the SSRC belongs to Alice or anyon= e else, is no other identifying info in the packet.  And I think that'= s OK.  We can prevent packet packets coming in from untrusted entities= , but we're not trying to prevent a trusted endpoint from being malicious.<= /DIV>
 
Paul
 
--------=_MB30BD5AA0-5FE1-4509-9B0D-2CA5207357B9-- From nobody Fri Jul 17 21:17:52 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B301A8732 for ; Fri, 17 Jul 2015 21:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.012 X-Spam-Level: X-Spam-Status: No, score=-4.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1n5sK039bfg for ; Fri, 17 Jul 2015 21:17:49 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 041E71A1B0E for ; Fri, 17 Jul 2015 21:17:48 -0700 (PDT) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.14.9/8.14.9) with ESMTP id t6I4HjKd010078 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Jul 2015 00:17:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1437193066; bh=8sg3CsiquEIfg6TifvJ4JeQ67GEx63DzcYRznBgf71o=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=V1orKNqz7gAqi8rpgcpwikCJ01J9vmfinY1WmlsWgc4U6xZ1hUzLr8i0Mk6OLeEg9 cOsjQLMdJ9U+oFZUH/u4ITxSAG8YznYgi9q+CvGOa0OhL/kUccCqukLeWz8m9ymXt+ JKgOppPHvIANneYlEmPTe32scTmWb+5dXEFOiHdQ= From: "Paul E. Jones" To: "Magnus Westerlund" , "Eric Rescorla" , perc@ietf.org Date: Sat, 18 Jul 2015 04:18:10 +0000 Message-Id: In-Reply-To: <55A4BBF7.4060107@ericsson.com> User-Agent: eM_Client/6.0.22344.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Perc] Review of draft-jones-perc-private-media-reqts-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 04:17:50 -0000 Magnus, I think we agree on the security requirements. I only meant that some=20 systems may not maintain a roster of who is presently in a conference. =20 It would certainly have a list of who is allowed to be in the=20 conference. Paul ------ Original Message ------ From: "Magnus Westerlund" To: "Paul E. Jones" ; "Eric Rescorla"=20 ; perc@ietf.org;=20 draft-jones-perc-private-media-reqts@tools.ietf.org Sent: 7/14/2015 3:36:23 AM Subject: Re: [Perc] Review of draft-jones-perc-private-media-reqts-00 >Hi, > >I reacted to this part of the discussion. > >Paul E. Jones skrev den 2015-07-14 07:30: > >>>- PERC allows active attack by the Call Processing System to be >>> detectable to a great extent: >>> >>> - The client knows the identity (i.e., the certificate) of >>> the KMF. If WebRTC identity or a valid certificate is >>> used, then the client can determine whether the CPS has >>> injected itself. >>This would be true, but that is also true even if the attack is not on >>the CPS. >>> - The KMF knows the number of participants in the call, but >>> nothing prevents the CPS from injecting an extra participant >>> since the KMF has no expectation of the caller's identities. >>Insofar as the PERC work goes, I think that is a correct >>statement. Some might build a KMF that does know endpoints and does >> have access to a secure conference roster, but I don't think we want >>to force those requirements into PERC. > >Regarding these two bullets, I think we do need to aim at the security=20 >level that no one that can't assert an identity towards the KMF that=20 >the inviter in the conference has included in the conference=20 >invitation/rooster can retrieve the key. That verification can't be=20 >dune by the CPS, it needs to be part of the KMF or a stand alone but=20 >trusted entity. > >From a functional perspective the conference inviter will schedule a=20 >conference and create a rooster with identity. At the time of joining=20 >the conference the participant needs to assert its identity to the KMF.= =20 >If that is done by talking to a secure rooster server that generates=20 >some credentials bound to the participants endpoint, and those are used= =20 >to assert the identity when talking to the KMF, that is an open=20 >question. I have a tendency to favour the second as that will reduce=20 >the API surface on the KMF, and separate the authorization of the=20 >participant to this separate function, which then can be a bit more=20 >flexible to integrate the various identity systems used. > >I also note if we are going to solve the SHOULD level goal of=20 >preventing a participant prior to joining and after leaving the=20 >conference to have an possibility to decrypt, including retrospective,=20 >the end-to-end security layer, then we will be forced to go into=20 >tracking who is currently active participants within a trusted=20 >function, i.e. not the CPS. The CPS can of course be an helper, but the= =20 >security can't rely on the CPS. > >Cheers > >Magnus Westerlund > >---------------------------------------------------------------------- >Services, Media and Network features, Ericsson Research EAB/TXM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > From nobody Fri Jul 17 21:22:13 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09AB01A88A4 for ; Fri, 17 Jul 2015 21:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrOlXIGsaKvX for ; Fri, 17 Jul 2015 21:22:11 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4A031A889D for ; Fri, 17 Jul 2015 21:22:10 -0700 (PDT) Received: by widic2 with SMTP id ic2so51696576wid.0 for ; Fri, 17 Jul 2015 21:22:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0XztpCVYkxPa8Y7/yS6w6rP0aVhJm4NxHSvJdLDUZkg=; b=L9t7uHD81Ixh8fY3B95JofApCK9+3GeVUk7uYJt7921QReit70cv+Vb7tmWUxj0tk9 a8VB6PFNBRtyKdX0vdZrK47ExSZfatNox3c+8atd53qmxmK3hzWJUXUcygQsAouMR9+h QP5cJa/yD/3OhokbLJ1F8sW0ceOqh5/SaY4jI38DKU047PE5eVdfdfiKc2/zGGuZHSv7 IxQMROg2B/EHQ60rB9bwVUTZoMnElTo418IRLtpS2qAByRgioei2Bkef1XI/vnZuGs3u cFTeen8SKQVj5c4qwpYRVAtjTXqTRLxTPjugrAIUV3fjbQmtokELT8LKnL3ALFspaaNT TDbQ== X-Gm-Message-State: ALoCoQmbWNH6kljfTc17ZXil7fG+JHeGLBEmo8LkMKRPLw3FA67i6NFnMI+1G2gK6MPEloIP66v1 X-Received: by 10.194.133.73 with SMTP id pa9mr35083654wjb.148.1437193329423; Fri, 17 Jul 2015 21:22:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Fri, 17 Jul 2015 21:21:30 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 17 Jul 2015 21:21:30 -0700 Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=089e011771a9dfcf16051b1ea5fa Archived-At: Cc: perc@ietf.org Subject: Re: [Perc] Review of draft-jones-perc-private-media-reqts-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 04:22:13 -0000 --089e011771a9dfcf16051b1ea5fa Content-Type: text/plain; charset=UTF-8 On Fri, Jul 17, 2015 at 9:13 PM, Paul E. Jones wrote: > Eric, > > Other text I think we're in agreement on (and need to work on). > > I did want to respond to your one question. > > > * Section 7.1.2 is confusing when compared to 7.2.3. >> I think that the issue is that 7.1.2 needs to be rewritten to >> make clear that the guarantee is that the sending endpoint is >> part of the group, not that it is a particular endpoint. >> >> >> > We might want to know that it is a particular endpoint or even a > particular human user, and we get this by checking the client certificate > and validating it. However, insofar as this goal goes, I think that was > the intent. John Mattsson contributed this one, I think. If you don't > have particular suggestions for wording changes, perhaps he might weigh in? > > That's fine as far as session establishment, but once the session is > established > everyone knows the sending key for Alice and so can impersonate Alice > unless the MDD tags each message with the identity using the H2H key. > Is that the plan? > > There will be a HBH key that is shared between Alice and the MDD. The > intent is that the MDD will process the SRTP packets and check for the > authentication tag created with that key that is known only to Alice and > the MDD (and the KMF, but we trust it). The MDD will reject any packet > that is authenticated with Alice's key and purportedly coming from Alice. > > When the MDD forwards media, it will re-authenticate the packet using the > shared key between itself and Bob (or Carol or ...). Each hop will receive > a copy of Alice's packet, each hop being authenticated with that hop's key. > > However, there is no particular identifying information that we've > proposed to put into Alice's packet so that Bob would know that was > originally sourced from Alice. All Bob would know is that an apparently > valid packet is received from the MDD. The endpoint will also check to > ensure that any received EKT tag is not corrupted and it will verify that > the encrypted payload authenticates with the key associated with the > sender's SSRC. Still, Bob does not know the SSRC belongs to Alice or > anyone else, is no other identifying info in the packet. And I think > that's OK. We can prevent packet packets coming in from untrusted > entities, but we're not trying to prevent a trusted endpoint from being > malicious. > So to be clear, the endpoint recipient of a packet has no way of determining the sender of the packet? I don't think that's necessarily bad, but that's ot how I read 7.1.2. -Ekr --089e011771a9dfcf16051b1ea5fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 17, 2015 at 9:13 PM, Paul E. Jones <paulej@packetizer.= com> wrote:
Eric,
=C2=A0
Other text I think we're in=C2=A0agreement on (and need to w= ork on).
=C2=A0
I did want to respond to your=C2=A0one question.
=C2=A0
* Section 7.1.2 is confusing when compared to 7.2.3.
I think that the issue is that 7.1.2 needs to be rewritten to
make clear that the guarantee is that the sending endpoint is
part of the group, not that it is a particular endpoint.
=C2=A0
We might want to know that it is a particular endpoint or even a parti= cular human user,=C2=A0and we get this by checking the client certificate a= nd validating it.=C2=A0 However, insofar as this goal goes, I think that wa= s the intent.=C2=A0 John Mattsson contributed this one, I think.=C2=A0 If y= ou don't have particular suggestions for wording changes, perhaps he mi= ght weigh in?

That's fine as far as session establishment, but once the session = is established
everyone knows the sending key for Alice and so can impersonate Alice<= /div>
unless the MDD tags each message with the identity using the H2H key.<= /div>
Is that the plan?
=C2=A0
There will be a HBH key that is shared between Alice and the MDD.=C2= =A0 The intent is that the MDD will process the SRTP packets and check for = the authentication tag created with that key that is known only to Alice an= d the MDD (and the KMF, but we trust it).=C2=A0 The MDD will reject any pac= ket that is authenticated with Alice's key and purportedly coming from = Alice.
=C2=A0
When the MDD forwards media, it will re-authenticate the packet using = the shared key between itself and Bob (or Carol or ...).=C2=A0 Each hop wil= l receive a copy of Alice's packet, each hop being authenticated with t= hat hop's key.
=C2=A0
However, there is no particular identifying information that we've= proposed to put into Alice's packet so that Bob would know that was or= iginally sourced from Alice.=C2=A0 All Bob would know is that an apparently= valid packet is received from the MDD.=C2=A0 The endpoint will also check = to ensure that any received EKT tag is not corrupted and it will verify tha= t the encrypted payload authenticates with the key associated with the send= er's SSRC.=C2=A0 Still, Bob does not know the SSRC belongs to Alice or = anyone else, is no other identifying info in the packet.=C2=A0 And I think = that's OK.=C2=A0 We can prevent packet packets coming in from untrusted= entities, but we're not trying to prevent a trusted endpoint from bein= g malicious.

So to be clear, =C2=A0th= e endpoint recipient of a packet has no way of determining
th= e sender of the packet? I don't think that's necessarily bad, but t= hat's ot how I read 7.1.2.

-Ekr

=


--089e011771a9dfcf16051b1ea5fa-- From nobody Fri Jul 17 21:26:08 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC811A88B6 for ; Fri, 17 Jul 2015 21:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyOttMSO9Ifu for ; Fri, 17 Jul 2015 21:26:03 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06891A8968 for ; Fri, 17 Jul 2015 21:26:02 -0700 (PDT) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.14.9/8.14.9) with ESMTP id t6I4Q09w010506 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Jul 2015 00:26:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1437193561; bh=ZL0HKgDC2Mvtpi9av9xcG58QLfHgugTX52+9nAGPcLs=; h=From:To:Subject:Cc:Date:In-Reply-To:Reply-To; b=aSrz3DEn4JGkuTlVbqGzncSSkcUsTFWDkiA29evWErtVeXHr2pmi6r+JA8nYe/LPZ BqW6HcCDenSRaCORjhvBxoRJSK8o3ydB6oQsdfjEJ2dOqc5YAj10YGuB2ydA8k1wQY SZHEvzjZvc5VkTayxIzVcHtZSw1H/hfErOBaLmi4= From: "Paul E. Jones" To: "Eric Rescorla" Date: Sat, 18 Jul 2015 04:26:26 +0000 Message-Id: In-Reply-To: User-Agent: eM_Client/6.0.22344.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBA5A0AF94-A313-47DB-9E15-4149981A348B" Archived-At: Cc: perc@ietf.org Subject: Re: [Perc] Review of draft-jones-perc-private-media-reqts-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 04:26:05 -0000 --------=_MBA5A0AF94-A313-47DB-9E15-4149981A348B Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eric, >>>>>* Section 7.1.2 is confusing when compared to 7.2.3. >>>>>I think that the issue is that 7.1.2 needs to be rewritten to >>>>>make clear that the guarantee is that the sending endpoint is >>>>>part of the group, not that it is a particular endpoint. >>>> >>We might want to know that it is a particular endpoint or even a=20 >>particular human user, and we get this by checking the client=20 >>certificate and validating it. However, insofar as this goal goes, I=20 >>think that was the intent. John Mattsson contributed this one, I=20 >>think. If you don't have particular suggestions for wording changes,=20 >>perhaps he might weigh in? >> >>That's fine as far as session establishment, but once the session is=20 >>established >>everyone knows the sending key for Alice and so can impersonate Alice >>unless the MDD tags each message with the identity using the H2H key. >>Is that the plan? There will be a HBH key that is shared between Alice and the MDD. The=20 intent is that the MDD will process the SRTP packets and check for the=20 authentication tag created with that key that is known only to Alice and= =20 the MDD (and the KMF, but we trust it). The MDD will reject any packet=20 that is authenticated with Alice's key and purportedly coming from=20 Alice. When the MDD forwards media, it will re-authenticate the packet using=20 the shared key between itself and Bob (or Carol or ...). Each hop will=20 receive a copy of Alice's packet, each hop being authenticated with that= =20 hop's key. However, there is no particular identifying information that we've=20 proposed to put into Alice's packet so that Bob would know that was=20 originally sourced from Alice. All Bob would know is that an apparently= =20 valid packet is received from the MDD. The endpoint will also check to=20 ensure that any received EKT tag is not corrupted and it will verify=20 that the encrypted payload authenticates with the key associated with=20 the sender's SSRC. Still, Bob does not know the SSRC belongs to Alice=20 or anyone else, is no other identifying info in the packet. And I think= =20 that's OK. We can prevent packet packets coming in from untrusted=20 entities, but we're not trying to prevent a trusted endpoint from being=20 malicious. So to be clear, the endpoint recipient of a packet has no way of=20 determining the sender of the packet? I don't think that's necessarily bad, but=20 that's ot how I read 7.1.2. Yes, I think that's the intent with that original text. Paul --------=_MBA5A0AF94-A313-47DB-9E15-4149981A348B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Eric,
 
* Section 7.1.2 is confusing when compared to 7.2.3.
I think that the issue is that 7.1.2 needs to be rewritten to
make clear that the guarantee is that the sending endpoint is
part of the group, not that it is a particular endpoint.
 
We might want to know that it is a particular endpoint or even a parti= cular human user, and we get this by checking the client certificate= and validating it.  However, insofar as this goal goes, I think that= was the intent.  John Mattsson contributed this one, I think. = If you don't have particular suggestions for wording changes, perhaps he= might weigh in?

That's fine as far as session establishment, but once the session is= established
everyone knows the sending key for Alice and so can impersonate Alice<= /DIV>
unless the MDD tags each message with the identity using the H2H key.<= /DIV>
Is that the plan?
 
There will be a HBH key that is shared between Alice and the MDD. = ; The intent is that the MDD will process the SRTP packets and check for= the authentication tag created with that key that is known only to Alice= and the MDD (and the KMF, but we trust it).  The MDD will reject any= packet that is authenticated with Alice's key and purportedly coming from= Alice.
 
When the MDD forwards media, it will re-authenticate the packet using= the shared key between itself and Bob (or Carol or ...).  Each hop= will receive a copy of Alice's packet, each hop being authenticated with= that hop's key.
 
However, there is no particular identifying information that we've = proposed to put into Alice's packet so that Bob would know that was origina= lly sourced from Alice.  All Bob would know is that an apparently vali= d packet is received from the MDD.  The endpoint will also check to= ensure that any received EKT tag is not corrupted and it will verify that= the encrypted payload authenticates with the key associated with the sende= r's SSRC.  Still, Bob does not know the SSRC belongs to Alice or anyon= e else, is no other identifying info in the packet.  And I think that'= s OK.  We can prevent packet packets coming in from untrusted entities= , but we're not trying to prevent a trusted endpoint from being malicious.<= /DIV>

So to be clear,  the endpoint recipient of a packet has no way= of determining
the sender of the packet? I don't think that's necessarily bad, but= that's ot how I read 7.1.2.
 
Yes, I think that's the intent with that original text.
 
Paul
 
--------=_MBA5A0AF94-A313-47DB-9E15-4149981A348B-- From nobody Tue Jul 21 00:28:21 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719F91AD1DB for ; Tue, 21 Jul 2015 00:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaRa6p0_3WBr for ; Tue, 21 Jul 2015 00:28:17 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 550BD1AD1BA for ; Tue, 21 Jul 2015 00:28:17 -0700 (PDT) X-AuditID: c1b4fb3a-f79356d000006281-7f-55adf48eee8a Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 04.24.25217.E84FDA55; Tue, 21 Jul 2015 09:28:15 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.3.210.2; Tue, 21 Jul 2015 09:28:14 +0200 To: "Paul E. Jones" , Eric Rescorla , References: From: Magnus Westerlund Message-ID: <55ADF48D.8050802@ericsson.com> Date: Tue, 21 Jul 2015 09:28:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUyM+JvjW7/l7WhBvdOcVuseH2O3eL8hQ1M FqsXTmd0YPZYsuQnk0fDvqPsHpMftzEHMEdx2aSk5mSWpRbp2yVwZUyddZqpYJ5KxYvH71gb GKfIdjFyckgImEgcuLiWCcIWk7hwbz1bFyMXh5DAUUaJn1uvsYMkhASWM0rsuyYCYgsLuEq8 +nGbtYuRg0NEIEZiw3c/iBJriYPr3rOB2GwCFhI3fzSC2bwC2hKtF1eBzWcRUJXo+d7KDGKL ArXOXzGdGaJGUOLkzCcsIDangI3E58ubwHqZgebMnH+eEcKWl2jeOpsZYpe2RENTB+sERoFZ SNpnIWmZhaRlASPzKkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAQD245bfVDsaDzx0PMQpw MCrx8C5YvjZUiDWxrLgy9xCjNAeLkjjvjM15oUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY a5TYbIKehdXmLDkstzn52y7V5q2fS/Ycd2DZzpe/9MduwdaghHcpdznj9v1LvFJ7e09avuBU gcVJlTm35bZmx75/XptwdhXXEfeF5fm1O/0+3Tw9OTzT6eI14QsnjnhVecZHzyv6mVfDWrEj hFFg1YYos5cdNivst8xd57d5ddTJ4j5jU7NsJZbijERDLeai4kQAcwxjMjUCAAA= Archived-At: Subject: Re: [Perc] Review of draft-jones-perc-private-media-reqts-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 07:28:20 -0000 Den 2015-07-18 kl. 06:18, skrev Paul E. Jones: > Magnus, > > I think we agree on the security requirements. I only meant that some > systems may not maintain a roster of who is presently in a conference. > It would certainly have a list of who is allowed to be in the conference. > Yes, for the basic security level that is all fine. But for the higher security level where you want to prevent participants to get to media prior or after having joined or left I don't see an alternative to maintaining a rooster. /Magnus > Paul > > ------ Original Message ------ > From: "Magnus Westerlund" > To: "Paul E. Jones" ; "Eric Rescorla" > ; perc@ietf.org; > draft-jones-perc-private-media-reqts@tools.ietf.org > Sent: 7/14/2015 3:36:23 AM > Subject: Re: [Perc] Review of draft-jones-perc-private-media-reqts-00 > >> Hi, >> >> I reacted to this part of the discussion. >> >> Paul E. Jones skrev den 2015-07-14 07:30: >> >>>> - PERC allows active attack by the Call Processing System to be >>>> detectable to a great extent: >>>> >>>> - The client knows the identity (i.e., the certificate) of >>>> the KMF. If WebRTC identity or a valid certificate is >>>> used, then the client can determine whether the CPS has >>>> injected itself. >>> This would be true, but that is also true even if the attack is not on >>> the CPS. >>>> - The KMF knows the number of participants in the call, but >>>> nothing prevents the CPS from injecting an extra participant >>>> since the KMF has no expectation of the caller's identities. >>> Insofar as the PERC work goes, I think that is a correct >>> statement. Some might build a KMF that does know endpoints and does >>> have access to a secure conference roster, but I don't think we want >>> to force those requirements into PERC. >> >> Regarding these two bullets, I think we do need to aim at the security >> level that no one that can't assert an identity towards the KMF that >> the inviter in the conference has included in the conference >> invitation/rooster can retrieve the key. That verification can't be >> dune by the CPS, it needs to be part of the KMF or a stand alone but >> trusted entity. >> >> From a functional perspective the conference inviter will schedule a >> conference and create a rooster with identity. At the time of joining >> the conference the participant needs to assert its identity to the >> KMF. If that is done by talking to a secure rooster server that >> generates some credentials bound to the participants endpoint, and >> those are used to assert the identity when talking to the KMF, that is >> an open question. I have a tendency to favour the second as that will >> reduce the API surface on the KMF, and separate the authorization of >> the participant to this separate function, which then can be a bit >> more flexible to integrate the various identity systems used. >> >> I also note if we are going to solve the SHOULD level goal of >> preventing a participant prior to joining and after leaving the >> conference to have an possibility to decrypt, including retrospective, >> the end-to-end security layer, then we will be forced to go into >> tracking who is currently active participants within a trusted >> function, i.e. not the CPS. The CPS can of course be an helper, but >> the security can't rely on the CPS. >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Services, Media and Network features, Ericsson Research EAB/TXM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jul 21 00:36:02 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F391A0267 for ; Tue, 21 Jul 2015 00:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Mes2eFH5Ll6 for ; Tue, 21 Jul 2015 00:36:00 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B95791A0235 for ; Tue, 21 Jul 2015 00:35:59 -0700 (PDT) X-AuditID: c1b4fb3a-f79356d000006281-3a-55adf65d249b Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 32.B5.25217.D56FDA55; Tue, 21 Jul 2015 09:35:58 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.210.2; Tue, 21 Jul 2015 09:35:57 +0200 To: "Paul E. Jones" , Eric Rescorla References: From: Magnus Westerlund Message-ID: <55ADF65B.9040604@ericsson.com> Date: Tue, 21 Jul 2015 09:35:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUyM+JvjW7ct7WhBquNLFa8Psducf7CBiaL 1QunMzoweyxZ8pPJo2HfUXaPyY/bmAOYo7hsUlJzMstSi/TtErgyfi0/yl5wSKbi98P0BsaH ol2MnBwSAiYS/7t3s0LYYhIX7q1nA7GFBI4ySqyf5NDFyAVkL2eU+PB2FxNIQljAVeLVj9tg DSICnhKX769nhmiwlri3+DULiM0sICzxbtU6sDibgIXEzR+NYEN5BbQlbpycxAhiswioSjw8 c5sdxBYViJGYv2I6M0SNoMTJmU/A5nAK2Eh0LFgNFOcAmmkv8WBrGcR4eYnmrbOh1mpLNDR1 sE5gFJyFpHsWQscsJB0LGJlXMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgSG7sEtv612MB58 7niIUYCDUYmHd8HytaFCrIllxZW5hxilOViUxHlnbM4LFRJITyxJzU5NLUgtii8qzUktPsTI xMEp1cDIEWxWZl+ywmZzIXe7La+ea8DWun/h7tXTJG0rzrdXCUY8P3nWJ5P/uICp1/fZBTty Svvtwub/8TxXsV1X56fuzZXiC4+/qysz5Typ80nlTnFluNzHGXtMnttP2HLZ52HGPYG+3j7p d231YgU8543/qr7efnDJfM0fSxvORb2V+ztvq5+0v5QSS3FGoqEWc1FxIgBOqk2JPgIAAA== Archived-At: Cc: perc@ietf.org Subject: Re: [Perc] Review of draft-jones-perc-private-media-reqts-00 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 07:36:01 -0000 Den 2015-07-18 kl. 06:26, skrev Paul E. Jones: > Eric, >> >>>> * Section 7.1.2 is confusing when compared to 7.2.3. >>>> I think that the issue is that 7.1.2 needs to be rewritten to >>>> make clear that the guarantee is that the sending endpoint is >>>> part of the group, not that it is a particular endpoint. >> We might want to know that it is a particular endpoint or even a >> particular human user, and we get this by checking the client >> certificate and validating it. However, insofar as this goal >> goes, I think that was the intent. John Mattsson contributed this >> one, I think. If you don't have particular suggestions for >> wording changes, perhaps he might weigh in? >> >> That's fine as far as session establishment, but once the session >> is established >> everyone knows the sending key for Alice and so can impersonate Alice >> unless the MDD tags each message with the identity using the H2H key. >> Is that the plan? >> There will be a HBH key that is shared between Alice and the MDD. >> The intent is that the MDD will process the SRTP packets and check >> for the authentication tag created with that key that is known >> only to Alice and the MDD (and the KMF, but we trust it). The MDD >> will reject any packet that is authenticated with Alice's key and >> purportedly coming from Alice. >> When the MDD forwards media, it will re-authenticate the packet >> using the shared key between itself and Bob (or Carol or ...). >> Each hop will receive a copy of Alice's packet, each hop being >> authenticated with that hop's key. >> However, there is no particular identifying information that we've >> proposed to put into Alice's packet so that Bob would know that >> was originally sourced from Alice. All Bob would know is that an >> apparently valid packet is received from the MDD. The endpoint >> will also check to ensure that any received EKT tag is not >> corrupted and it will verify that the encrypted payload >> authenticates with the key associated with the sender's SSRC. >> Still, Bob does not know the SSRC belongs to Alice or anyone else, >> is no other identifying info in the packet. And I think that's >> OK. We can prevent packet packets coming in from untrusted >> entities, but we're not trying to prevent a trusted endpoint from >> being malicious. >> >> >> So to be clear, the endpoint recipient of a packet has no way of >> determining >> the sender of the packet? I don't think that's necessarily bad, but >> that's ot how I read 7.1.2. > Yes, I think that's the intent with that original text. My view is that we need a way to at least reference who the original sender is. I am fine with this information only being protected to the level of that it is one among the participants that provided this. At the same time I expect that this can be used such that it is not revealing the peers identity to another peer, i.e. there need to be a configuration/usage option. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Jul 22 01:12:08 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3371B3088 for ; Wed, 22 Jul 2015 01:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IwrdTIuYkG6 for ; Wed, 22 Jul 2015 01:12:05 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E1DA1B3083 for ; Wed, 22 Jul 2015 01:12:05 -0700 (PDT) Received: by lahh5 with SMTP id h5so133184743lah.2 for ; Wed, 22 Jul 2015 01:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=yHRJ5IAX/ZhzxfGc8Pl7MYP9/GVNqhe+U1feWYdSWTs=; b=lTS9HaZ1jMjY4Hw05FppUpnYnXRJSWWNZnaqHRdGX49tuufovMDCxXk6HSm1UbuaiE NWN6gjA2DeBZvOTQXduZmfxotHWhoG55QNTO2qVjfylf8uXN9LQqn+GdI3kYfx2w/8Ut P6yWqN9MZzvd7e+WsivTWZAEsRTLWPakIAa9K4Y0xIZS+Jr1fqkRKNA7noigf9JBPXjZ p+K2osAtaCqEiDZzFzTk51YJfqxJbjrGzsP3qwBbLbGOuEyTfGVxUJdMy1pcA2p/nN+d 1rDU0mJ5lUhhcZ2cKdMdVXmAcS2E07zcpeYLfMogLpyTTDSUWBexnOAt1jlY9cLFEl7m +WMg== MIME-Version: 1.0 X-Received: by 10.152.36.41 with SMTP id n9mr1139476laj.79.1437552723993; Wed, 22 Jul 2015 01:12:03 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Wed, 22 Jul 2015 01:12:03 -0700 (PDT) Date: Wed, 22 Jul 2015 10:12:03 +0200 X-Google-Sender-Auth: AnnOokSNS7q6JnQ_WvYtC8_XK98 Message-ID: From: Phillip Hallam-Baker To: perc@ietf.org Content-Type: multipart/alternative; boundary=089e0158b60875aa73051b72538b Archived-At: Subject: [Perc] Alternative way to do key management... X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 08:12:07 -0000 --089e0158b60875aa73051b72538b Content-Type: text/plain; charset=UTF-8 Apologies in advance for the drive-by. I haven't read the drafts. But since we are in Prague and I will be presenting something very similar in a few hours at CFRG. I thought this would be relevant and useful. At any rate, people may want to consider this approach while there is an opportunity to talk to crypto type people. As you are probably aware, crypto is moving to ECC. While this is being done for performance, it also has consequences for features. RSA does not work in elliptic curves. So all the systems are DH based. One particular feature of DH systems is that we can combine two DH keys to create a new key: If we have a Right private key R and a Left private key L, we can derive a Joint key J as follows: J = R+L e^J = e^R . e^L Further, if we perform the computations in a finite group it can be shown that knowledge of e^R and e^L does not provide any information about J unless knowledge of e^R discloses R (in which case DH is broken in that group anyway). OK so what does this mean for PERC? Well on the OpenPGP list we were discussing a mailing list server in which this scheme is used to avoid the need to expose the private key of a mailing list to an online mailing list remailer. The public key of the mailing list is e^J. The secret key of the mailing list (J) is kept offline. The remailer only knows R and the set e^LMi When a new member joins, they contact the (offline) key manager which constructs the value e^LMi in the normal way and communicates this to the mailing list manager. So what does this mean for PERC? Well in an enterprise setting, we can eliminate the need for the key manager to be online at all. As an ExampleCo employee, Alice gets her enterprise PERC key as part of her corporate credentialing process. For ad hoc communications in which the participant is not registered in advance, the key manager has to be online of course. But we can still use the same approach to require collusion between the distribution point and the key manager to effect a default. The division of responsibility here is: Distribution point - responsible for authentication and access control (who joins a conference) Key Manager- responsible for authentication (implicit) and confidentiality The approach may be further extended to meet an additional layer of transparency requirements and further bound the operation of the services. In the traditional protocol design approach we have only asked 'how do we use crypto to enforce condition X'. In the new approach typified by Certification Transparency we accept that we can't enforce every condition cryptographically, in fact we can't even specify every condition in advance. So we use accountability and make trusted components either auditable (privileged participants can verify operation) or (preferably) transparent (anyone can audit operation). The basic approach here is to create ephemeral keys to 'salt' the server key and then intern them in a blockchain structure. --089e0158b60875aa73051b72538b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Apologies in advance for the drive-by. I haven't read = the drafts. But since we are in Prague and I will be presenting something v= ery similar in a few hours at CFRG. I thought this would be relevant and us= eful. At any rate, people may want to consider this approach while there is= an opportunity to talk to crypto type people.

As you ar= e probably aware, crypto is moving to ECC. While this is being done for per= formance, it also has consequences for features. RSA does not work in ellip= tic curves. So all the systems are DH based.

One p= articular feature of DH systems is that we can combine two DH keys to creat= e a new key:


If we have a Right private key R and a Left private k= ey L, we can derive a Joint key J as follows:

J= =3D R+L
e^J =3D e^R . e^L=

Further, if we perform the computations in a f= inite group it can be shown that knowledge of e^R and e^L does not provide = any information about J unless knowledge of e^R discloses R (in which case = DH is broken in that group anyway).


<= /div>
OK so what does this mean = for PERC?

Well on the OpenPGP list we were disc= ussing a mailing list server in which this scheme is used to avoid the need= to expose the private key of a mailing list to an online mailing list rema= iler.

The public key of the mailing list is e^J= . The secret key of the mailing list (J) is kept offline.

The remailer only knows R and the set e^LMi=C2=A0

When a new mem= ber joins, they contact the (offline) key manager which constructs the valu= e e^LMi in the normal way and communicates this to the mailing list manager= .


So what does this mean= for PERC?

Well in an enterprise setting, we can e= liminate the need for the key manager to be online at all. As an ExampleCo = employee, Alice gets her enterprise PERC key as part of her corporate crede= ntialing process.

For ad hoc communications in whi= ch the participant is not registered in advance, the key manager has to be = online of course. But we can still use the same approach to require collusi= on between the distribution point and the key manager to effect a default.<= /div>

The division of responsibility here is:
=
Distribution point - responsible for authentication and acce= ss control (who joins a conference)
Key Manager- responsible for = authentication (implicit) and confidentiality


=
The approach may be further extended to meet an additional layer= of transparency requirements and further bound the operation of the servic= es.

In the traditional protocol design approach we= have only asked 'how do we use crypto to enforce condition X'. In = the new approach typified by Certification Transparency we accept that we c= an't enforce every condition cryptographically, in fact we can't ev= en specify every condition in advance. So we use accountability and make tr= usted components either auditable (privileged participants can verify opera= tion) or (preferably) transparent (anyone can audit operation).
<= br>
The basic approach here is to create ephemeral keys to 's= alt' the server key and then intern them in a blockchain structure.
--089e0158b60875aa73051b72538b-- From nobody Thu Jul 23 04:10:32 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92661B2AAB for ; Wed, 22 Jul 2015 09:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5KqAbNtroQp for ; Wed, 22 Jul 2015 09:38:26 -0700 (PDT) Received: from smtpcmd02111.aruba.it (smtpcmd02111.aruba.it [62.149.158.111]) by ietfa.amsl.com (Postfix) with ESMTP id 278A21B2ACF for ; Wed, 22 Jul 2015 09:38:23 -0700 (PDT) Received: from dell-tcastaldi ([31.130.224.109]) by smtpcmd02.ad.aruba.it with bizsmtp id vUeN1q00l2NEPrz01UePi5; Wed, 22 Jul 2015 18:38:23 +0200 Date: Wed, 22 Jul 2015 18:38:24 +0200 (CEST) From: Meetecho Team To: perc@ietf.org Message-ID: <774137183.11.1437583104204.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_10_324589909.1437583104201" Archived-At: X-Mailman-Approved-At: Thu, 23 Jul 2015 04:10:31 -0700 Subject: [Perc] Meetecho recordings of PERC WG session X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 16:38:27 -0000 ------=_Part_10_324589909.1437583104201 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the PERC WG session at IETF 93 is available at the following URL: http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#PERC In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team ------=_Part_10_324589909.1437583104201-- From nobody Thu Jul 23 04:10:34 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46E21A9073 for ; Wed, 22 Jul 2015 09:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Pb3DtCnUi3w for ; Wed, 22 Jul 2015 09:39:52 -0700 (PDT) Received: from smtpcmd02111.aruba.it (smtpcmd02111.aruba.it [62.149.158.111]) by ietfa.amsl.com (Postfix) with ESMTP id 944321A8AB2 for ; Wed, 22 Jul 2015 09:39:28 -0700 (PDT) Received: from dell-tcastaldi ([31.130.224.109]) by smtpcmd02.ad.aruba.it with bizsmtp id vUfS1q0082NEPrz01UfTba; Wed, 22 Jul 2015 18:39:27 +0200 Date: Wed, 22 Jul 2015 18:39:27 +0200 (CEST) From: Meetecho Team To: perc@ietf.org Message-ID: <440895731.1.1437583167776.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_0_1351561298.1437583167738" Archived-At: X-Mailman-Approved-At: Thu, 23 Jul 2015 04:10:31 -0700 Subject: [Perc] Meetecho recordings of PERC WG session X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 16:39:57 -0000 ------=_Part_0_1351561298.1437583167738 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the PERC WG session at IETF 93 is available at the following URL: http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#PERC In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team ------=_Part_0_1351561298.1437583167738--