From nobody Wed Feb 1 11:52:04 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2971B1294ED for ; Wed, 1 Feb 2017 11:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.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 X5a0_FH94GXJ for ; Wed, 1 Feb 2017 11:52:01 -0800 (PST) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (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 2F81D129563 for ; Wed, 1 Feb 2017 11:52:01 -0800 (PST) Received: by mail-ot0-x230.google.com with SMTP id 32so140068154oth.3 for ; Wed, 01 Feb 2017 11:52:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=JnMbRCXeGnT6/mem3E7+Hw1+RCTnym4alQ1Sjw959+I=; b=nE6A2E9dEZkt83ZufOG+zo+HZpeqsFGAF96qKoYI484IT2NSVi2/GtA2faxpTPCM8b UUDZ1AWh+IXjHoT67K709TqPY3yiHXhluvB6Fbb5a5LQXPWMUlrWODWZAosH+0kXnOAT CH0eYPNdMfr2ywKogFs0eL2I1Ne2hj5URa6nC2RoIYqav1/46Z3CPpcycsRo5iFtPh2/ N6LUu/DQr57DXIipkFu/WPk7gsLbrGg+FusC1Yez1FpNCvvlvF4bF8IZ4R89XzxZom+v ruziNRx4x/LJPwVpcTldP7OVOuH46e3zZssvwRzGCGMqPkPAiKRPVcl10W5rJ9HJI4hK AeOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=JnMbRCXeGnT6/mem3E7+Hw1+RCTnym4alQ1Sjw959+I=; b=b4GMou2Lhnt7Eb9CxLOrxG/naax8BFynTBV6SXCmCIqexfve5qqG/ldNlNEAuCY4p0 n1dT83Fk9E2u3MMHVuG7nqgDBnMhrdmlnCd5z58EXI7ddHIm2QqZkNJyMD/Jyo87v2Hi ipRzzS9sHBo/+TEEh7aBlKJHUtoFqJR5pSp2MnFtbsFRRiRVuv0UEiDqIyBbCRJJfRPy 2o4FpbtTfSpNyFMqgkIyEG198h15sMdf3lVO3AlkNyqXPtl74CiH8tz4lkap7pslsCRM Y0Ma+fgAY4lv/rPFEwdsbvCOFqB4xaMh8enkR5EHRkxCJ+wmgmr58EL27qjRLeUD1n6d ewOQ== X-Gm-Message-State: AIkVDXLDox0Mr6d+U1DhafIyWqhz5DkCBOn/ZBlzaQtEGl0tbvFvP4h7kfod8p4y5PQkKg== X-Received: by 10.157.44.153 with SMTP id p25mr2074654otb.27.1485978720198; Wed, 01 Feb 2017 11:52:00 -0800 (PST) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id t11sm11006401ott.9.2017.02.01.11.51.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Feb 2017 11:51:59 -0800 (PST) To: perc@ietf.org From: Emil Ivov Message-ID: <74609536-491b-e5ed-b899-087b0f32aae0@jitsi.org> Date: Wed, 1 Feb 2017 13:51:58 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Perc] SSRC rewriting X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 19:52:03 -0000 Hey all, Back in Berlin I took an action item to write a draft that describes how one can resolve the security concerns around SSRC rewriting. I dropped the ball on that, apologies, but can now pick it up again. The issue is that I am not able to find anything that actually describes the problem (other than a mere mention of how SSRC splicing could maybe be a risk) and, personally, I am not able to think of a way one could mount a successful attack that way. Is this described anywhere? Thanks, Emil -- https://jitsi.org From nobody Mon Feb 6 15:17:43 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C7D128B37 for ; Mon, 6 Feb 2017 15:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.122 X-Spam-Level: X-Spam-Status: No, score=-3.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 AVPkJ-0syLZv for ; Mon, 6 Feb 2017 15:17:40 -0800 (PST) Received: from smtp93.iad3a.emailsrvr.com (smtp93.iad3a.emailsrvr.com [173.203.187.93]) (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 A4395129667 for ; Mon, 6 Feb 2017 15:17:40 -0800 (PST) Received: from smtp12.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp12.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C0FB925034; Mon, 6 Feb 2017 18:17:29 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp12.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 7ED7825032; Mon, 6 Feb 2017 18:17:29 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.92.108.145] (192-195-83-200.static.monkeybrains.net [192.195.83.200]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Mon, 06 Feb 2017 18:17:29 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <74609536-491b-e5ed-b899-087b0f32aae0@jitsi.org> Date: Mon, 6 Feb 2017 15:17:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2A571A45-B582-4249-A280-35AFFD777DA6@cisco.com> References: <74609536-491b-e5ed-b899-087b0f32aae0@jitsi.org> To: Emil Ivov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: perc@ietf.org Subject: Re: [Perc] SSRC rewriting X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 23:17:42 -0000 I have a vague memory some of the Ericsson folks put together a pretty = reasonable set of slides on it. Perhaps those might be a starting point.=20= > On Feb 1, 2017, at 11:51 AM, Emil Ivov wrote: >=20 > Hey all, >=20 > Back in Berlin I took an action item to write a draft that describes = how one can resolve the security concerns around SSRC rewriting. >=20 > I dropped the ball on that, apologies, but can now pick it up again. >=20 > The issue is that I am not able to find anything that actually = describes the problem (other than a mere mention of how SSRC splicing = could maybe be a risk) and, personally, I am not able to think of a way = one could mount a successful attack that way. >=20 > Is this described anywhere? >=20 > Thanks, > Emil >=20 > --=20 > https://jitsi.org >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc From nobody Mon Feb 6 15:24:33 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DB61296BA for ; Mon, 6 Feb 2017 15:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.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 13hUW6uoiAc2 for ; Mon, 6 Feb 2017 15:24:30 -0800 (PST) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 E59891296B3 for ; Mon, 6 Feb 2017 15:24:29 -0800 (PST) Received: by mail-wr0-x22c.google.com with SMTP id o16so29067884wra.1 for ; Mon, 06 Feb 2017 15:24:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=udQuPRPzS50O9XYub0TDEDBA/kQflpTSY/gg5xW1WVE=; b=YyRWu7X1EKgP3XoaRRupdcxQ2FSiAM6BJqJdIGB0qgTV+BDgI5V2p1wt8VKDKkCPKC zpQFbCc47FUUx48STNW6LUmW8IcQbRrbuenQvWtxKu7jjuBbZeXD6VcqxNSwyF2sbBae zmOHYi4qyg1B68W2ZyW4WbO6TRaqqETxPA8ohChWGw4V1njUEGfAPIh4xMZx02dIY7iT kXzrPbLXDN/lYX/jevNUTuN9ofptJ9VHMUsDapuyIMjiP0wG9QL6FNhKJ13YEei3l58i ObeL8yCGUEZp2+l2+p9ryplgCKcX+Bg+IQ76fIiFocBFZjluvS+mU/6Y5HOcgHeylNzx bqWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=udQuPRPzS50O9XYub0TDEDBA/kQflpTSY/gg5xW1WVE=; b=ARD6g6SkoFIMVDTkdL0A/rPvGK7dkK1i7p2xToF+tltMmiAOtlxkswYbfHyqdhMQUl dkvyej+IZB12CSq/+RYQmOMHNhrzM7Orf7jIVbq2BjTnd/yWfxSVXWirn5hnddsV5N8T epXmhjFolmX9fuFLEst5NaueFOd+M2kWl5Xiq+oklVy2xlsE5GPIsOFduowDsaRlvd2u mx5Dj5mHZF+oUQ32XmyB9HHxdniBg0Joc3Tej9dSFxpjWeZ/2kVmzQlFxmpQIcf0LHo5 H1m3l9aoiK7Pb5d/mujwPokHM3ji6p80pJ/HR2Ff3J5b1H51X3x3kZPXEeN74yw6LhrC AEFg== X-Gm-Message-State: AIkVDXKsM/6/nDbmraUObRXj4XzjYPcHV8qACJ4CGOt9ZTRPURnHtD13xYZpyJKBQWrfyg== X-Received: by 10.223.163.199 with SMTP id m7mr11117013wrb.63.1486423468242; Mon, 06 Feb 2017 15:24:28 -0800 (PST) Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com. [74.125.82.54]) by smtp.gmail.com with ESMTPSA id 61sm4103904wrs.29.2017.02.06.15.24.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Feb 2017 15:24:28 -0800 (PST) Received: by mail-wm0-f54.google.com with SMTP id 196so38261394wmm.1 for ; Mon, 06 Feb 2017 15:24:28 -0800 (PST) X-Received: by 10.28.173.140 with SMTP id w134mr9850474wme.56.1486423467891; Mon, 06 Feb 2017 15:24:27 -0800 (PST) MIME-Version: 1.0 References: <74609536-491b-e5ed-b899-087b0f32aae0@jitsi.org> <2A571A45-B582-4249-A280-35AFFD777DA6@cisco.com> In-Reply-To: <2A571A45-B582-4249-A280-35AFFD777DA6@cisco.com> From: Emil Ivov Date: Mon, 06 Feb 2017 23:24:16 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=001a11444f82ca3c2d0547e4eeb3 Archived-At: Cc: perc@ietf.org Subject: Re: [Perc] SSRC rewriting X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 23:24:32 -0000 --001a11444f82ca3c2d0547e4eeb3 Content-Type: text/plain; charset=UTF-8 Sounds good. Anyone has a reference to them? Emil On Mon, 6 Feb 2017 at 17:17, Cullen Jennings wrote: > > I have a vague memory some of the Ericsson folks put together a pretty > reasonable set of slides on it. Perhaps those might be a starting point. > > > On Feb 1, 2017, at 11:51 AM, Emil Ivov wrote: > > > > Hey all, > > > > Back in Berlin I took an action item to write a draft that describes how > one can resolve the security concerns around SSRC rewriting. > > > > I dropped the ball on that, apologies, but can now pick it up again. > > > > The issue is that I am not able to find anything that actually describes > the problem (other than a mere mention of how SSRC splicing could maybe be > a risk) and, personally, I am not able to think of a way one could mount a > successful attack that way. > > > > Is this described anywhere? > > > > Thanks, > > Emil > > > > -- > > https://jitsi.org > > > > _______________________________________________ > > Perc mailing list > > Perc@ietf.org > > https://www.ietf.org/mailman/listinfo/perc > > -- sent from my mobile --001a11444f82ca3c2d0547e4eeb3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sounds good. Anyone has a reference to them?

= Emil

On Mon, 6 Feb 2017 at 17= :17, Cullen Jennings <fluffy@cisco.c= om> wrote:

I have a vague memory some of the Ericsson folks put together a pretty reas= onable set of slides on it. Perhaps those might be a starting point.

> On Feb 1, 2017, at 11:51 AM, Emil Ivov <emcho@jitsi.org> wrote= :
>
> Hey all,
>
> Back in Berlin I took an action item to write a draft that describes h= ow one can resolve the security concerns around SSRC rewriting.
>
> I dropped the ball on that, apologies, but can now pick it up again. >
> The issue is that I am not able to find anything that actually describ= es the problem (other than a mere mention of how SSRC splicing could maybe = be a risk) and, personally, I am not able to think of a way one could mount= a successful attack that way.
>
> Is this described anywhere?
>
> Thanks,
> Emil
>
> --
> https://jitsi.org
>
> _______________________________________________
> Perc mailing list
> Perc@ietf.org
> https://www.ietf.org/mailman/list= info/perc

--
sent from my mobile
--001a11444f82ca3c2d0547e4eeb3-- From nobody Tue Feb 14 16:05:59 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA321298C6 for ; Tue, 14 Feb 2017 16:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.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 paYl-qQNKhYE for ; Tue, 14 Feb 2017 16:05:56 -0800 (PST) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (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 E6523129983 for ; Tue, 14 Feb 2017 16:05:55 -0800 (PST) Received: by mail-ot0-x22a.google.com with SMTP id 32so106741343oth.3 for ; Tue, 14 Feb 2017 16:05:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=T2skUgfcA3xFzFMi+KTIY32THG18BwssM2OSWaesOl0=; b=SfpPS7di3EOn++r9qYuWWC+QHgONHzzS46rrfccUgSHl+xfUXUvLD62JLqF2x9RZDG lr0WhY+hJc2r0y2zm60tFnILKipyTF6tFYoi+zzjk37f5D3YUqsBJ4thl5bxuNraaeJE rMfmU4wnMHBFTNjhFoHTZcGHKOqPEEenrKIo2+SuqCLfa3zxcWJlI+3avEiORMJM8M3v tAMasg/bnfJPu9ksy09osX1G6ZjuK2WJM4K1c+M7/UyJhC7i9BpDXmIQEfCGbb6DIw0f XjefAQZflGnb8jp0iv+FuOjqclbm1RG6dLk/8sBuHz3NJDbpeUTjAhPBgXXkCfGIj+fT rmBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=T2skUgfcA3xFzFMi+KTIY32THG18BwssM2OSWaesOl0=; b=nJMTjkPejir4cUfyNgo5iv1P5BKU73rBRKGDJQPLNVng9qyvnKV1lftqHEFkIs+hlg NBwKTdVO5SRZi/kff5qFqhaK4Q2J6VvPkEMAvMnFMbxQ/RTl79Ef7V2UPMQk/4Jkf4TQ t+PaqimsIhjRy+qnSLk5BFfqi387I8UpDkzYJnFSLkeHbAuax557DRw+lXm6FG5nBGaE GQTmA8NHsYwP7RCkU9hUDiKS9enrWkF+1QX5rInypz7IsVpbZ/nGzsiOlf8nHqg4tpJE 2U7fA5+kpZf+bYW3L/9R9iAP81KFLc5bPz8XqilHnnsO0jFgCaQiCL7rg6nF9JQ3NDy8 dT6g== X-Gm-Message-State: AMke39lHANkYk6FCdknElKHjrRRuyorTfp+5bka7pV4Zwbcm18LS/ET2pPz3aseMFLDGIQ== X-Received: by 10.157.43.225 with SMTP id u88mr20088217ota.5.1487117155241; Tue, 14 Feb 2017 16:05:55 -0800 (PST) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id v14sm840924otv.0.2017.02.14.16.05.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 16:05:53 -0800 (PST) To: Cullen Jennings References: <74609536-491b-e5ed-b899-087b0f32aae0@jitsi.org> <2A571A45-B582-4249-A280-35AFFD777DA6@cisco.com> From: Emil Ivov Message-ID: Date: Tue, 14 Feb 2017 18:05:53 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------AB129308EC754E68FF3B991B" Archived-At: Cc: perc@ietf.org Subject: Re: [Perc] SSRC rewriting X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 00:05:58 -0000 This is a multi-part message in MIME format. --------------AB129308EC754E68FF3B991B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit So Magnus and I just had an entire discussion about this without realizing we were offline. I am attaching the exchange here. The takeaways for me are the following: 1. Up till now I am not aware of any attack that is specifically introduced by SSRC overwriting in the SFU. 2. We have a bigger issue to solve around SSRC enforcement. Magnus please feel free to correct me or add anything I missed. Cheers, Emil --------------AB129308EC754E68FF3B991B Content-Type: text/html; name="Re_ [Perc] SSRC rewriting.html" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Re_ [Perc] SSRC rewriting.html" PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5SRTogW1BlcmNdIFNTUkMgcmV3cml0aW5nPC90aXRs ZT4NCjxsaW5rIHJlbD0iaW1wb3J0YW50IHN0eWxlc2hlZXQiIGhyZWY9ImNocm9tZTovL21l c3NhZ2Vib2R5L3NraW4vbWVzc2FnZUJvZHkuY3NzIj4NCjwvaGVhZD4NCjxib2R5Pg0KPHRh YmxlIGJvcmRlcj0wIGNlbGxzcGFjaW5nPTAgY2VsbHBhZGRpbmc9MCB3aWR0aD0iMTAwJSIg Y2xhc3M9ImhlYWRlci1wYXJ0MSI+PHRyPjx0ZD48Yj5TdWJqZWN0OiA8L2I+UkU6IFtQZXJj XSBTU1JDIHJld3JpdGluZzwvdGQ+PC90cj48dHI+PHRkPjxiPkZyb206IDwvYj5NYWdudXMg V2VzdGVybHVuZCAmbHQ7bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tJmd0OzwvdGQ+ PC90cj48dHI+PHRkPjxiPkRhdGU6IDwvYj4yLzEzLzE3LCA4OjM1IEFNPC90ZD48L3RyPjwv dGFibGU+PHRhYmxlIGJvcmRlcj0wIGNlbGxzcGFjaW5nPTAgY2VsbHBhZGRpbmc9MCB3aWR0 aD0iMTAwJSIgY2xhc3M9ImhlYWRlci1wYXJ0MiI+PHRyPjx0ZD48Yj5UbzogPC9iPkVtaWwg SXZvdiAmbHQ7ZW1jaG9Aaml0c2kub3JnJmd0OywgQm8gQnVybWFuICZsdDtiby5idXJtYW5A ZXJpY3Nzb24uY29tJmd0OywgJnF1b3Q7Q3VsbGVuCiBKZW5uaW5ncyAoZmx1ZmZ5KSZxdW90 OyAmbHQ7Zmx1ZmZ5QGNpc2NvLmNvbSZndDs8L3RkPjwvdHI+PC90YWJsZT48YnI+DQo8aHRt bCB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6bz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJodHRwOi8vc2NoZW1h cy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4KPGhlYWQ+CjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRl bnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyAiPgo8bWV0YSBuYW1lPSJHZW5lcmF0b3Ii IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4KPHN0eWxl PjwhLS0KLyogRm9udCBEZWZpbml0aW9ucyAqLwpAZm9udC1mYWNlCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsKCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30KQGZvbnQtZmFjZQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsKCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbAoJe21hcmdpbjowY207CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cglmb250 LXNpemU6MTIuMHB0OwoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9 CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsKCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7Cglj b2xvcjpibHVlOwoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9CmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZAoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsKCWNvbG9y OnB1cnBsZTsKCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQpwLk1zb0FjZXRhdGUsIGxp Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJ bXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsKCW1hcmdpbjowY207CgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7Cglmb250LXNpemU6OC4wcHQ7Cglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7fQpzcGFuLmdtYWlsbXNnCgl7bXNvLXN0eWxlLW5hbWU6Z21h aWxfbXNnO30Kc3Bhbi5FbWFpbFN0eWxlMTgKCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Cgljb2xvcjojMUY0 OTdEO30Kc3Bhbi5CYWxsb29uVGV4dENoYXIKCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBU ZXh0IENoYXIiOwoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJbXNvLXN0eWxlLWxpbms6IkJh bGxvb24gVGV4dCI7Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Cgltc28t ZmFyZWFzdC1sYW5ndWFnZTpTVjt9Ci5Nc29DaHBEZWZhdWx0Cgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOwoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQpAcGFnZSBXb3JkU2VjdGlvbjEKCXtzaXplOjYx Mi4wcHQgNzkyLjBwdDsKCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0 O30KZGl2LldvcmRTZWN0aW9uMQoJe3BhZ2U6V29yZFNlY3Rpb24xO30KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4KPC9o ZWFkPgo8Ym9keSBsYW5nPSJTViIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+CjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+U28gb24gdGhlIGZpcnN0IGlzc3VlIG9mIGFzc29jaWF0 aW5nIFNTUkNzLCBJIGhhdmVu4oCZdCBmb2xsb3dlZCB0aGUgZGlzY3Vzc2lvbiwgYnV0IGlm IG9uZSBhbGxvd3MgbXVsdGlwbGUgY29uZmVyZW5jZSBwYXJ0aWNpcGFudHMgdG8gdXNlIHRo ZSBzYW1lCiBTU1JDIHZhbHVlLCB0aGVuIG9uZSBjYW4gc3RpbGwgZG8gcmVwbGFjZW1lbnQu IFNvIG9uZSBlaXRoZXIgbmVlZCB1bmlxdWUgc291cmNlIFNTUkNzIG9yIGEgYmluZGluZyB0 byBhbm90aGVyIElEIHRoYXQgaXMgbWFpbnRhaW5lZCBlbmQtdG8tZW5kLiBQcmV2aW91cyBQ RVJDIGRpc2N1c3Npb25zIGhhdmUgYmVlbiB1bmNsZWFyIGluIHdoYXQgZGlyZWN0aW9uIHRo aXMgZW5kcyB1cCBpbi4KPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5TbywgaWYgb25lIHJlY292ZXJzIHRoZSBvcmlnaW5hbCBTU1JDIGFuZCB0 aGF0IGlzIGVuZm9yY2VkIHRvIGJlIHVuaXF1ZSBieSBvdGhlciBtZWNoYW5pc21zIHRoYW4g dGhlIFNGVXMsIHRoZW4gSSBkb27igJl0IHRoaW5rIHlvdSBoYXZlIGFuIGlzc3VlCiBmcm9t IHRoZSBTRlUgYXMgYXR0YWNrZXIuIE9uZSBpbXBvcnRhbnQgYXNwZWN0IGhlcmUgaXMgdGhh dCB0aGUgU0ZVIG11c3Qgbm90IGJlIGFibGUgdG8gbWFuaXB1bGF0ZSBzb21lIHBhcnRpY2lw YW50IHRvIHVzZSB0aGUgc2FtZSBTU1JDIGFzIGFub3RoZXIgcGFydGljaXBhbnQuIFRodXMs IHRoZSBTU1JDIGhhbmRsaW5nIG5lZWRzIHRvIG1lZXQgY2VydGFpbiBjcml0ZXJpYS4KPG86 cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgc2lt dWxjYXN0IGV4YW1wbGUgaXMgYSBnb29kIG9uZSwgYmVjYXVzZSB0aGUgcmVjZWl2ZXIgbmVl ZCB0byByZWFsbHkga25vdyB3aGljaCBTU1JDcyB0aGF0IGFyZSBmcm9tIHRoZSBzYW1lIG1l ZGlhIHNvdXJjZSwgb3RoZXJ3aXNlIGl0IGJlY29tZXMKIHZ1bG5lcmFibGUgdG8gYXR0YWNr LCBhcyBoZXJlIGNsZWFybHkgdGhlIHNvdXJjZSBTU1JDIG1heSBzd2l0Y2ggYmFjayBhbmQg Zm9ydGggYmV0d2VlbiB0aGUgZGlmZmVyZW50IHJlcHJlc2VudGF0aW9ucy4gVGh1cywgaW4g c3VjaCBhIHVzYWdlIHRoZSBvcmlnaW5hbCBzZW5kZXJzIG1hcHBpbmcgb2YgYSBtZWRpYSBz b3VyY2UgdG8gU1NSQ3MgbmVlZHMgdG8gYmUgY29tbXVuaWNhdGVkIHNlY3VyZWx5Lgo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFp bEVuZENvbXBvc2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzPG86cD48L286cD48L3NwYW4+PC9hPjwvcD4KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWFnbnVzIFdlc3Rlcmx1bmQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gRW1pbCBJdm92IFttYWlsdG86ZW1j aG9Aaml0c2kub3JnXQo8YnI+CjxiPlNlbnQ6PC9iPiBkZW4gMTMgZmVicnVhcmkgMjAxNyAx NDo0NDxicj4KPGI+VG86PC9iPiBCbyBCdXJtYW47IEN1bGxlbiBKZW5uaW5ncyAoZmx1ZmZ5 KTsgTWFnbnVzIFdlc3Rlcmx1bmQ8YnI+CjxiPlN1YmplY3Q6PC9iPiBSZTogW1BlcmNdIFNT UkMgcmV3cml0aW5nPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8ZGl2 Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPgo8ZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBN b24sIDEzIEZlYiAyMDE3IGF0IDA2OjU4LCBNYWdudXMgV2VzdGVybHVuZCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbSI+bWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+CjwvZGl2 Pgo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowY20iPgo8ZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGNsYXNzPSJnbWFpbG1zZyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8L3NwYW4+PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGNsYXNzPSJnbWFp bG1zZyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGNsYXNzPSJnbWFpbG1zZyI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyB0aGUg aXNzdWUgSSBzZWUgaXMgdGhhdCBpZiBvbmUgYWxsb3dzIFNTUkMgcmV3cml0aW5nIGFuZCBo YXZlCiBubyBiaW5kaW5nIGJldHdlZW4gdGhlIEUyRSBjcnlwdG8gb2YgdGhlIG1lZGlhIHBh eWxvYWQgYW5kIHRoZSBzb3VyY2UgdGhlbjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwO3RoZXJlIGV4aXN0IG5vIHBv c3NpYmlsaXR5IHRvIGRvIHNvdXJjZSBhdXRoZW50aWNhdGlvbiAob2YgYSBzcGVjaWZpYyBz b3VyY2UpIGluIHRoZSByZWNlaXZpbmcKIGNsaWVudC48L3NwYW4+PG86cD48L286cD48L3A+ CjwvZGl2Pgo8L2Rpdj4KPC9ibG9ja3F1b3RlPgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SG9sZCBvbiBhIHNlY29uZC4gSWYgeW91IGhhdmUgbm8gd2F5IG9mIGFzc29jaWF0 aW5nIFNTUkNzIHdpdGggc2VuZGVycyB0aGVuIHlvdSBhcmUgYWxyZWFkeSBpbiBiaWcgdHJv dWJsZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhpcyBpcyBub3QgaW4gYW55IHdheSBhIHByb2JsZW0gb2YgU1NSQyByZXdy aXRpbmcuJm5ic3A7PG86cD48L286cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPC9kaXY+CjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+ CjxkaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIHRoaXMgY2FzZSBvbmUgY2FuIG9u bHkgZGV0ZXJtaW5lIGlmIHRoZSBtZWRpYSBjb21lcyBmcm9tIHdpdGhpbiB0aGUgRTJFIHNl Y3VyaXR5IGNvbnRleHQsIGJ1dAogbm90IGRldGVybWluZSBpZiB0aGUgU0ZVLCB3aGljaCB0 aGUgU0ZVIGlzIG5vdCBwYXJ0IG9mIHRoZSBzZWN1cml0eSBjb250ZXh0LCBoYXMgcmV3cml0 dGVuIHRoZSBTU1JDIGFuZCBsaWVzIGFib3V0IHRoZSBvcmlnaW5hbCBzb3VyY2Ugb2YgdGhl IG1lZGlhIHBheWxvYWQuIFRodXMgYXR0cmlidXRpbmcgaXQgdG8gc29tZW9uZSBlbHNlIHRo YXQgZGVsaXZlcnMgbWVkaWEgYW5kIGlzIHBhcnQgb2YgdGhlIEUyRSBzZWN1cml0eSBjb250 ZXh0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPC9kaXY+CjwvZGl2Pgo8L2Jsb2NrcXVvdGU+ CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8L2Rp dj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHBhcnQgdGhhdCBpcyBtaXNzaW5n IGhlcmUgaXMgaG93IGF1dGhlbnRpY2F0aW9uIHdvcmtzIGFjY29yZGluZyB0byB5b3UuPG86 cD48L286cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1c3Qg YXMgd2l0aCBhbnkgb3RoZXIgbW9kaWZpZWQgZmllbGQsIHRoZSBTRlUgd2lsbCBrZWVwIHRo ZSBvcmlnaW5hbCBTU1JDIGFzIHBhcnQgb2YgdGhlIG9yaWdpbmFsIGhlYWRlciBibG9jayB3 aGljaCB3b3VsZCBhbGxvdyByZWNlaXZlcnMgdG88bzpwPjwvbzpwPjwvcD4KPC9kaXY+Cjxk aXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8L2Rpdj4K PGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gVmVyaWZ5IHRoZSBvcmlnaW5hbCBwYWNr ZXQgaXMgbm90IHRhbXBlcmVkIHdpdGggYW5kPG86cD48L286cD48L3A+CjwvZGl2Pgo8ZGl2 Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBFYXNpbHkgZGV0ZWN0IGlmIHRoZSBTRlUgaXMg dHJ5aW5nIHRvIHBhc3MgYSBwYWNrZXQgZnJvbSBBIGFzIGEgcGFja2V0IGZyb20gQjxvOnA+ PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBtZW50 aW9uZWQgYWJvdmUsIGlmIHRoZSByZWNlaXZlciBjYW5ub3QgYXNzb2NpYXRlIFNTUkMgMSB3 aXRoIEEgYW5kIDIgd2l0aCBCIHRoZW4gJm5ic3A7eW91IGhhdmUgdGhlIHNhbWUgYXV0aCBj b25jZXJuIGV2ZW4gd2l0aG91dCByZXdyaXRpbmcuPG86cD48L286cD48L3A+CjwvZGl2Pgo8 ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4K PGRpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBjbGFzcz0iZ21h aWxtc2ciPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+RGVwZW5kaW5nIG9uIG90aGVyIGFzcGVjdHMgb2YgdGhlIHNlY3VyaXR5 IG1lY2hhbmlzbSwgdGhlcmUgbWlnaHQKIGFsc28gZXhpc3QgcG9zc2liaWxpdGllcyB0byBk byBjb21iaW5hdGlvbiBvZiBzcGxpY2luZyBhbmQgZGVsYXkgb3IgcmVwbGF5IGF0dGFjaywg d2hpY2ggaXMgaG93IHRoaXMgYXR0YWNrIGJlY29tZXMgdXNhYmxlIGZyb20gbXkgcGVyc3Bl Y3RpdmUuPC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPgo8L2Rpdj4KPC9kaXY+CjwvYmxvY2txdW90ZT4KPGRpdj4KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgdGhhdCAmbmJz cDtkZWxheSYjNDM7cmVwbGF5IGlzIGEgcG9zc2liaWxpdHkgdGhhdCBoYXMgdG8gYmUgYWRk cmVzc2VkIGJ1dCwganVzdCBhcyB0aGUgY3VycmVudCBkb3VibGUgZHJhZnQgc2F5czogaXQg aXMgaW4gbm8gd2F5IGV4Y2x1c2l2ZSB0byBTU1JDIHJld3JpdGluZy48bzpwPjwvbzpwPjwv cD4KPC9kaXY+CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+CjxkaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPklmIG9uZSBjYW4gcmVjb3ZlciBhbmQgdmVyaWZ5IHRoZSBvcmlnaW5hbCBTU1JDIGFu ZCBvbmUga25vd3Mgd2hpY2ggb3JpZ2luYWwgU1NSQ3MgYXJlIHVzZWQgYnkgdGhlCiBkaWZm ZXJlbnQgbWVkaWEgc291cmNlcywgdGhlbiB0aGlzIGF0dGFjayBpcyBwcmV2ZW50ZWQuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPgo8L2Rpdj4KPC9kaXY+CjwvYmxvY2txdW90ZT4KPGRpdj4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjwvZGl2Pgo8ZGl2 Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ3JlZWQgaGVyZSB0b28gLi4uIGV4Y2VwdCB0aGF0 IHdpdGhvdXQgU1NSQyB2ZXJpZmljYXRpb24gSSBhbSBub3QgYXQgYWxsIGNsZWFyIGhvdyBh IHJlY2VpdmVyIGNhbiBkbyBhbnkgdmFsaWRhdGlvbiBhdCBhbGwgYWJvdXQgaW5jb21pbmcg cGFja2V0cy4gVGhhdCB3b3VsZCBlbmFibGUgYWxsIHNvcnRzIG9mIGF0dGFja3MsIGluY2x1 ZGluZyBzcGxpY2luZyBmcm9tIHRoZSBTRlUgKHdpdGhvdXQgcmVxdWlyaW5nCiByZXdyaXRp bmcpLjxvOnA+PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UYWtlIGZvciBleGFtcGxlIHNlbmRlcnMgQSBhbmQgQiwgc2VuZGluZyBzaW11bGNhc3Qg c3RyZWFzIGExLCBhMiBhbmQgYjEsICZuYnNwO2IyLiBJZiB0aGUgcmVjZWl2ZXIgaXMgbm90 IGF3YXJlIG9mIHRoZSBiaW5kaW5ncyBiZXR3ZWVuIHNlbmRlcnMgYW5kIFNTUkMgdGhlbiBp dCBtdXN0IGJlIGxlYXJuaW5nIHRoZW0gZHluYW1pY2FsbHkgaW4gc29tZSBvdGhlciB3YXkg KHNheSBpdCB1c2VzIGEgc2VwYXJhdGUgNXR1cGxlCiBwZXIgc2VuZGVyKS48bzpwPjwvbzpw PjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhhdCBpcyB0 aGUgY2FzZSB0aGVuIHRoZSBTRlUgY2FuIGp1c3QgYXMgZWFzaWx5IHBhc3MgYTEgYW5kIGIy IGFzIEEncyBzdHJlYW1zIGFuZCBiMSBhbmQgYTIgYXMgQidzLjxvOnA+PC9vOnA+PC9wPgo8 L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgdGhhdCdzIGp1c3Qgb25l IGV4YW1wbGUgLi4uIGRlcGVuZGluZyBvbiBob3cgZXhhY3RseSB5b3UgYmluZCBzc3JjLXMg YW5kIHJlY2VpdmVycyB3aXRob3V0IGV4cGxpY2l0IHNpZ25hbGxpbmcsIHRoZXJlIGFyZSBt YW55IG90aGVycy48bzpwPjwvbzpwPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1z b05vcm1hbCI+RW1pbDxvOnA+PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjwvZGl2Pgo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20i Pgo8ZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGNsYXNzPSJn bWFpbG1zZyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPgo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGNsYXNzPSJnbWFpbG1zZyI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaGVl cnM8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGNsYXNzPSJnbWFpbG1zZyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxv OnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGNsYXNzPSJn bWFpbG1zZyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5NYWdudXMgV2VzdGVybHVuZDwvc3Bhbj48L3NwYW4+PG86cD48L286 cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgbmFtZT0ibV8xMzMxNjMzNDAw MTc1MjAxMTFfX01haWxFbmRDb21wb3NlIj48c3BhbiBjbGFzcz0iZ21haWxtc2ciPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2E+PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gY2xhc3M9ImdtYWlsbXNnIj48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48L3NwYW4+PHNw YW4gY2xhc3M9ImdtYWlsbXNnIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPgogRW1pbCBJdm92IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmVtY2hvQGpp dHNpLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmVtY2hvQGppdHNpLm9yZzwvYT5dCjwvc3Bhbj48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+ CjxzcGFuIGNsYXNzPSJnbWFpbG1zZyI+PGI+U2VudDo8L2I+IGRlbiAxMyBmZWJydWFyaSAy MDE3IDEyOjEyPC9zcGFuPjxicj4KPHNwYW4gY2xhc3M9ImdtYWlsbXNnIj48Yj5Ubzo8L2I+ IEJvIEJ1cm1hbjsgQ3VsbGVuIEplbm5pbmdzIChmbHVmZnkpOyBNYWdudXMgV2VzdGVybHVu ZDwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+CjwvZGl2Pgo8L2Rpdj4KPGRpdj4KPGRp dj4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4KPHNwYW4gY2xhc3M9ImdtYWlsbXNnIj48Yj5TdWJq ZWN0OjwvYj4gUmU6IFtQZXJjXSBTU1JDIHJld3JpdGluZzwvc3Bhbj48L3NwYW4+PG86cD48 L286cD48L3A+CjwvZGl2Pgo8L2Rpdj4KPGRpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5UaGFua3MgTWFnbnVzLDxvOnA+PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4KPC9kaXY+Cjxk aXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBzZWUgdGhlIHNwbGljaW5nIGF0dGFj ayBzbGlkZSBpbiB0aGVyZSBidXQgd2FzIHdvbmRlcmluZyBpZiB5b3UgY291bGQgc2hhcmUg YSBsaXR0bGUgYml0IG1vcmUgaW5zaWdodCBpbnRvIGhvdyBpdCB3b3VsZCB3b3JrLjxvOnA+ PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gY2xhc3M9ImdtYWlsbXNnIj48c3BhbiBsYW5nPSJFTi1VUyI+U3BlY2lmaWNh bGx5OiB3aXRob3V0IFNTUkMgcmV3cml0aW5nLCByZWNlaXZlcnMgbG9va3VwIGFuIGluY29t aW5nIHBhY2tldCdzIFNTUkMgaW4gYSBsaXN0IHRoYXQgaGFzIGJlZW4gcmVjZWl2ZWQgZnJv bSBzaWduYWxsaW5nIGFuZCB0aGV5CiBtYXRjaCBpdCB0byBvbmUgb2YgdGhlIGVudHJpZXMg aW4gdGhlcmUuPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiA8L3NwYW4+PC9zcGFuPjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gY2xhc3M9ImdtYWlsbXNnIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+V2l0aCByZXdyaXRpbmcsIHRoZXkgd291bGQgcmVjaXZlIHBhY2tl dHMgd2l0aCB0d28gU1NSQ3MgKHRoZSBvcmlnaW5hbCBhbmQgdGhlIG5ldyBvbmUpLiBUaGV5 IHdpbGwgc3RpbGwgYXV0aGVudGljYXRlIHRoZSBwYWNrZXQgd2l0aCB0aGUgb3JpZ2luYWwg b25lLCB0aGVuICZuYnNwO3doYXQ/PG86cD48L286cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPgo8L2Rpdj4KPGRp dj4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHdvdWxkIGFzc3VtZSB5b3UgYXJlIHdv cnJpZWQgdGhhdCBpZiBhdCB0aGlzIHBvaW50IHRoZSBuZXcgU1NSQyBtYXRjaGVzIHNvbWVv bmUgZWxzZSdzIFNTUkMsIHRoZSBwYWNrZXQgbWF5IGJlIHNlbnQgdG8gdGhlIHdyb25nIGRl Y29kaW5nIGNoYWluLiZuYnNwOzxvOnA+PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4KPC9kaXY+CjxkaXY+ CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhdCBvZiBjb3Vyc2Ugd291bGQgYmUgdHJp dmlhbCB0byBwcmV2ZW50OiBpdCBpcyBlbm91Z2ggZm9yIHRoZSBQRVJDIHJlY2VpdmVyIHRv IGRyb3AgdGhlIHBhY2tldCBpZiB0aGUgbmV3IFNTUkMgbWF0Y2hlcyBhIHNlbmRlciBkaWZm ZXJlbnQgdGhhbiB0aGUgb25lIHNlbmRpbmcgdGhlIG9yaWdpbmFsIFNTUkMuPG86cD48L286 cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5X aGF0IGFtIEkgbWlzc2luZz88bzpwPjwvbzpwPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkVtaWs8bzpwPjwvbzpwPjwvcD4KPC9kaXY+Cjxk aXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+Cjwv ZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPgo8ZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIE1vbiwgMTMg RmViIDIwMTcgYXQgMDM6MzcsIE1hZ251cyBXZXN0ZXJsdW5kICZsdDs8YSBocmVmPSJtYWls dG86bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFn bnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+CjwvZGl2Pgo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0Ij4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSw8YnI+Cjxicj4KSXMg aXQgdGhpcyBwcmVzZW50YXRpb24geW91IHJlZmVyIHRvPzxicj4KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTQvc2xpZGVzL3NsaWRlcy05NC1wZXJjLTIu cGRmIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3Mv OTQvc2xpZGVzL3NsaWRlcy05NC1wZXJjLTIucGRmPC9hPjxicj4KPGJyPgovTWFnbnVzPGJy Pgo8YnI+Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPgpGcm9tOiBFbWlsIEl2b3Yg W21haWx0bzo8YSBocmVmPSJtYWlsdG86ZW1jaG9Aaml0c2kub3JnIiB0YXJnZXQ9Il9ibGFu ayI+ZW1jaG9Aaml0c2kub3JnPC9hPl08YnI+ClNlbnQ6IGRlbiAxMSBmZWJydWFyaSAyMDE3 IDE3OjQ4PGJyPgpUbzogQ3VsbGVuIEplbm5pbmdzIChmbHVmZnkpOyBCbyBCdXJtYW47IE1h Z251cyBXZXN0ZXJsdW5kPGJyPgpTdWJqZWN0OiBSZTogW1BlcmNdIFNTUkMgcmV3cml0aW5n PGJyPgo8YnI+Cjxicj4KPGJyPgpPbiAyLzYvMTcgNjo0MiBQTSwgQ3VsbGVuIEplbm5pbmdz IChmbHVmZnkpIHdyb3RlOjxicj4KJmd0OyBIaSBCbyAmYW1wOyBNYWdudXMsPGJyPgo8YnI+ CkJ1bXA/PGJyPgo8YnI+CkVtaWw8YnI+Cjxicj4KJmd0Ozxicj4KJmd0OyBEbyBvbmUgb2Yg eW91IHJlbWVtYmVyIHRoZSBzbGlkZXMgSSBhbSB0YWxraW5nIGFib3V0IC0gdGhleSBzaG93 ZWQgdGhlPGJyPgomZ3Q7IFNTUkMgc3BsaWNpbmcgcHJvYmxlbSBpbiBTUlRQPGJyPgomZ3Q7 PGJyPgomZ3Q7IEN1bGxlbjxicj4KJmd0Ozxicj4KJmd0Ozxicj4KJmd0OyZndDsgT24gRmVi IDYsIDIwMTcsIGF0IDM6MjQgUE0sIEVtaWwgSXZvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVt Y2hvQGppdHNpLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmVtY2hvQGppdHNpLm9yZzwvYT48YnI+ CiZndDsmZ3Q7ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmVtY2hvQGppdHNpLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPmVtY2hvQGppdHNpLm9yZzwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+ CiZndDsmZ3Q7PGJyPgomZ3Q7Jmd0OyBTb3VuZHMgZ29vZC4gQW55b25lIGhhcyBhIHJlZmVy ZW5jZSB0byB0aGVtPzxicj4KJmd0OyZndDs8YnI+CiZndDsmZ3Q7IEVtaWw8YnI+CiZndDsm Z3Q7PGJyPgomZ3Q7Jmd0OyBPbiBNb24sIDYgRmViIDIwMTcgYXQgMTc6MTcsIEN1bGxlbiBK ZW5uaW5ncyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZsdWZmeUBjaXNjby5jb20iIHRhcmdldD0i X2JsYW5rIj5mbHVmZnlAY2lzY28uY29tPC9hPjxicj4KJmd0OyZndDsgJmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86Zmx1ZmZ5QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZsdWZm eUBjaXNjby5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPgomZ3Q7Jmd0Ozxicj4KJmd0OyZn dDs8YnI+CiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtJIGhhdmUgYSB2YWd1ZSBtZW1v cnkgc29tZSBvZiB0aGUgRXJpY3Nzb24gZm9sa3MgcHV0IHRvZ2V0aGVyIGE8YnI+CiZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtwcmV0dHkgcmVhc29uYWJsZSBzZXQgb2Ygc2xpZGVz IG9uIGl0LiBQZXJoYXBzIHRob3NlIG1pZ2h0IGJlIGE8YnI+CiZndDsmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDtzdGFydGluZyBwb2ludC48YnI+CiZndDsmZ3Q7PGJyPgomZ3Q7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBPbiBGZWIgMSwgMjAxNywgYXQgMTE6NTEgQU0sIEVt aWwgSXZvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVtY2hvQGppdHNpLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPmVtY2hvQGppdHNpLm9yZzwvYT48YnI+CiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzplbWNob0BqaXRzaS5vcmciIHRhcmdl dD0iX2JsYW5rIj5lbWNob0BqaXRzaS5vcmc8L2E+Jmd0OyZndDsgd3JvdGU6PGJyPgomZ3Q7 Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4KJmd0OyZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyZndDsgSGV5IGFsbCw8YnI+CiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsm Z3Q7PGJyPgomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBCYWNrIGluIEJlcmxp biBJIHRvb2sgYW4gYWN0aW9uIGl0ZW0gdG8gd3JpdGUgYSBkcmFmdCB0aGF0PGJyPgomZ3Q7 Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ZGVzY3JpYmVzIGhvdyBvbmUgY2FuIHJlc29sdmUg dGhlIHNlY3VyaXR5IGNvbmNlcm5zIGFyb3VuZCBTU1JDPGJyPgomZ3Q7Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7cmV3cml0aW5nLjxicj4KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyZndDs8YnI+CiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IEkgZHJvcHBlZCB0 aGUgYmFsbCBvbiB0aGF0LCBhcG9sb2dpZXMsIGJ1dCBjYW4gbm93IHBpY2sgaXQgdXAgYWdh aW4uPGJyPgomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4KJmd0OyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgVGhlIGlzc3VlIGlzIHRoYXQgSSBhbSBub3QgYWJs ZSB0byBmaW5kIGFueXRoaW5nIHRoYXQgYWN0dWFsbHk8YnI+CiZndDsmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDtkZXNjcmliZXMgdGhlIHByb2JsZW0gKG90aGVyIHRoYW4gYSBtZXJlIG1l bnRpb24gb2YgaG93IFNTUkM8YnI+CiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtzcGxp Y2luZyBjb3VsZCBtYXliZSBiZSBhIHJpc2spIGFuZCwgcGVyc29uYWxseSwgSSBhbSBub3Qg YWJsZSB0bzxicj4KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3RoaW5rIG9mIGEgd2F5 IG9uZSBjb3VsZCBtb3VudCBhIHN1Y2Nlc3NmdWwgYXR0YWNrIHRoYXQgd2F5Ljxicj4KJmd0 OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+CiZndDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsmZ3Q7IElzIHRoaXMgZGVzY3JpYmVkIGFueXdoZXJlPzxicj4KJmd0OyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+CiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7IFRoYW5rcyw8YnI+CiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IEVt aWw8YnI+CiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPgomZ3Q7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyAtLTxicj4KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9qaXRzaS5vcmciIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL2ppdHNpLm9yZzwvYT4gJmx0OzxhIGhyZWY9Imh0dHBzOi8vaml0c2kub3JnLyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vaml0c2kub3JnLzwvYT4mZ3Q7PGJyPgomZ3Q7Jmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+CiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IFBlcmMgbWFpbGluZyBs aXN0PGJyPgomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyA8YSBocmVmPSJtYWls dG86UGVyY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlBlcmNAaWV0Zi5vcmc8L2E+ICZs dDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOlBlcmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5QZXJjQGlldGYub3JnPC9hPiZndDs8YnI+CiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cGVyYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcGVyYzwvYT48YnI+CiZndDsmZ3Q7PGJyPgomZ3Q7Jmd0OyAtLTxicj4KJmd0OyZn dDsgc2VudCBmcm9tIG15IG1vYmlsZTxicj4KJmd0Ozxicj4KPGJyPgotLTxicj4KPGEgaHJl Zj0iaHR0cHM6Ly9qaXRzaS5vcmciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2ppdHNpLm9y ZzwvYT48bzpwPjwvbzpwPjwvcD4KPC9ibG9ja3F1b3RlPgo8L2Rpdj4KPC9kaXY+CjxkaXY+ CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0KPG86cD48L286cD48L3A+CjwvZGl2Pgo8 ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnNlbnQgZnJvbSBteSBtb2JpbGU8bzpw PjwvbzpwPjwvcD4KPC9kaXY+CjwvZGl2Pgo8L2Rpdj4KPC9ibG9ja3F1b3RlPgo8L2Rpdj4K PC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPgo8 L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c2VudCBmcm9tIG15IG1vYmlsZTxv OnA+PC9vOnA+PC9wPgo8L2Rpdj4KPC9kaXY+CjwvYm9keT4KPC9odG1sPgo8L2JvZHk+DQo8 L2h0bWw+DQo= --------------AB129308EC754E68FF3B991B-- From nobody Tue Feb 14 16:35:26 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7F4129452 for ; Tue, 14 Feb 2017 16:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 F3-8fugYh3Cq for ; Tue, 14 Feb 2017 16:35:23 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 44AC112941C for ; Tue, 14 Feb 2017 16:35:23 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id k127so90508571vke.0 for ; Tue, 14 Feb 2017 16:35:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g0R8GVIcEA2wc8MO/6ryw7FTU6vF9I6fXD1IPI+XTvI=; b=rO3aAnbC3zBMYTA4FRMAwgIrYaBeH75JzwOILXI26R7wtzOJUDlLewi5zmqxz43fkR X4jIjEkc5iZN1xCVmAg/lfkVofEJNYvSyFYWssa0cSX+WDHUuTiQWqPWJS19Q/8F0MKB 6/UomUiDRMJiR1aZHX8UnFk5vhWJK9xMtTwBL5xTQmg3mrFO0XEVl7hPcH1TKl1Odjb6 78I1mVnTzt9YRf0ZVgrHN6Km/RyFTgYK+1IK1cHaBzr6Ea5pKRRbTrmCVVUJocdOYEXq e+fEZEwZ0cX4R8RKLngvbnPxMKDoaqIQt1HANpsma0MpPKrWDN5Og0i5hMRGrvC2g0Jv lfxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g0R8GVIcEA2wc8MO/6ryw7FTU6vF9I6fXD1IPI+XTvI=; b=CsLt3F2NHV+BQPgf2ACp8x9fGPOsaUzBPiaNTzo05DEdzsPsvm5yZ9ABHzIm96G6Ue ASGw33SLuT2GKVjbUYZ2uBe9AaRiYVYUwhG/bWk/li7/jT00XCN86njS5WuT29qdazzc HYdw2EmKa9ZlR8kuwIBeK5CrojNn3awDRLC6ZQS1eMgh/WRNypN2rO6a6hcRxRwFgW64 b68KNkeD/qNbdJjbbC4txIBIx3C+MYYJ/vol/I033hhLaLnUXKaArDq3J/YiDb/womNy 2/rfUtJNGn9M3kREMlSLtKMPGwgxIHhRLw0U1MSqfvjTvLaYVcjuZCZyTPgLAdcaMb22 qAsg== X-Gm-Message-State: AMke39nOYmLU3WS4T5QtxJx9hTE6JnTdNIBbKMWOYmeP7mHSWiu5EaM0ggLZmmyTAP80Tq9oycteWYoTnasM2g== X-Received: by 10.31.227.193 with SMTP id a184mr16022332vkh.106.1487118922200; Tue, 14 Feb 2017 16:35:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.88.90 with HTTP; Tue, 14 Feb 2017 16:35:01 -0800 (PST) In-Reply-To: References: <74609536-491b-e5ed-b899-087b0f32aae0@jitsi.org> <2A571A45-B582-4249-A280-35AFFD777DA6@cisco.com> From: Bernard Aboba Date: Tue, 14 Feb 2017 16:35:01 -0800 Message-ID: To: Emil Ivov , Magnus Westerlund Content-Type: multipart/alternative; boundary=001a114df80a18c076054886db57 Archived-At: Cc: Cullen Jennings , perc@ietf.org Subject: Re: [Perc] SSRC rewriting X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 00:35:25 -0000 --001a114df80a18c076054886db57 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Magnus said: "If one allows multiple conference participants to use the same SSRC value, then one can still do replacement. So one either need unique source SSRCs or a binding to another ID that is maintained end-to-end. Previous PERC discussions have been unclear in what direction this ends up in." [BA] In the RTP translator topology, this concern does not arise, since the SSRCs of the participants are required to be unique, and therefore it is necessary for participants to detect conflicts with other participants in the conference. However, in the situation where the SFU terminates RTP/RTCP, and conflicts can only occur between an individual participant and the SFU, there is no guarantee that one participant won't have a conflicting SSRC with another one. This is not a problem for RTP, but it *is* a problem for PERC if one assumes that key lookup is tied to the original SSRC, since the receiver now does not know which key to use to decrypt a payload from a given original SSRC. Magnus also said: "So, if one recovers the original SSRC and that is enforced to be unique by other mechanisms than the SFUs, then I don=E2=80=99t think you have an issu= e from the SFU as attacker. One important aspect here is that the SFU must not be able to manipulate some participant to use the same SSRC as another participant. Thus, the SSRC handling needs to meet certain criteria. [BA] If you are going to require SSRC uniqueness among all participants, then aren't you in effect requiring the RTP translator topology. I am trying to understand the situation in which simultaneously: a. The SSRC of each participant is unique. b. The SFU modifies SSRCs. c. The SFU does not terminate RTP/RTCP. On Tue, Feb 14, 2017 at 4:05 PM, Emil Ivov wrote: > So Magnus and I just had an entire discussion about this without realizin= g > we were offline. I am attaching the exchange here. > > The takeaways for me are the following: > > 1. Up till now I am not aware of any attack that is specifically > introduced by SSRC overwriting in the SFU. > > 2. We have a bigger issue to solve around SSRC enforcement. > > Magnus please feel free to correct me or add anything I missed. > > Cheers, > Emil > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > > --001a114df80a18c076054886db57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Magnus said:=C2=A0

"If one= allows multiple conference participants to use the same SSRC value, then o= ne can still do replacement. So one either need unique source SSRCs or a bi= nding to another ID that is maintained end-to-end. Previous PERC discussion= s have been unclear in what direction this ends up in."

[BA] In the RTP translator topolog= y, this concern does not arise, since the SSRCs of the participants are req= uired to be unique, and therefore it is necessary for participants to detec= t conflicts with other participants in the conference.=C2=A0 However, in th= e situation where the SFU terminates RTP/RTCP, and conflicts can only occur= between an individual participant and the SFU, there is no guarantee that = one participant won't have a conflicting SSRC with another one.=C2=A0 T= his is not a problem for RTP, but it *is* a problem for PERC if one assumes= that key lookup is tied to the original SSRC, since the receiver now does = not know which key to use to decrypt a payload from a given original SSRC.<= /span>

=C2=A0Magnus also said:=C2=A0

"So, if one recovers the original SSRC and that is enforced to be= unique by other mechanisms than the SFUs, then I don=E2=80=99t think you h= ave an issue from the SFU as attacker. One important aspect here is that th= e SFU must not be able to manipulate some participant to use the same SSRC = as another participant. Thus, the SSRC handling needs to meet certain crite= ria.

[BA] If you are going to require SSRC uniquenes= s among all participants, then aren't you in effect requiring the RTP t= ranslator topology.=C2=A0 I am trying to understand the situation in which = simultaneously:

a. The SSRC of each participant is unique.

b. The SFU modifies SSR= Cs.

c. = The SFU does not terminate RTP/RTCP.

On Tue, Feb 14, 2017 at 4:05 PM, Emil Ivov <emc= ho@jitsi.org> wrote:
So Mag= nus and I just had an entire discussion about this without realizing we wer= e offline. I am attaching the exchange here.

The takeaways for me are the following:

1. Up till now I am not aware of any attack that is specifically introduced= by SSRC overwriting in the SFU.

2. We have a bigger issue to solve around SSRC enforcement.

Magnus please feel free to correct me or add anything I missed.

Cheers,
Emil

_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc


--001a114df80a18c076054886db57-- From nobody Tue Feb 14 18:14:57 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8808912944A for ; Tue, 14 Feb 2017 18:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=atlassian-com.20150623.gappssmtp.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 LVZN4DFZMRCj for ; Tue, 14 Feb 2017 18:14:54 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 D29A51294B8 for ; Tue, 14 Feb 2017 18:14:53 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id r141so30610548wmg.1 for ; Tue, 14 Feb 2017 18:14:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=atlassian-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=OceaGAlHL7ghKGAgeF8VuoRB+2K8oTML2MS+hvE6H7A=; b=aFxeUbcqFgNklXZXYTkY79CyoCqCBb+XTKztY+22/HoK6EuCpKt+Hrim+spEhkoptc emP/GabvMfbG2qxB0g+ScHBlpd2UwRw6aMNZtUKaxA5vSU2WjyNASih1OISjZX+B9BVO fZHUpVkA2DLWFMOvrW9SW5bOZBYq0Qmt+YM7zO6vajjJniqFyTiAi07zXFYplquptul5 mDIpNyEbvylokTOpl2wUMF4zH6ky8GIxGBQ3Koyi5eQ+mDGh4/n6LMKS8sMStxM6ortJ 3t5xh6QDJ/J48rVRSX9l4Kxj1Ne9LA7ezG01UB55PdlpuC/8u1LHHcneg+LAXKySKTTn YWdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OceaGAlHL7ghKGAgeF8VuoRB+2K8oTML2MS+hvE6H7A=; b=M+fdl+ZSA75G1LmV7vLEPodK/HgbIJVCnT2Xn+mgoIHJsVI2RioKnsFCvTSxazvo7o SXJjYT8jYHTLJ8G46bTW27Gfp8kfH14OC3Ofpa86cPMK7vA29jGWV+I2mpVpKBF18FYn 4MFu+oAQNsKOXikDU3f+7pGIJC7qL56mPq+fBqBRlHwS9Rm89kP7uR1ejRW2fo9H7cPY iddNasc1xkV4m3VQOi9cN3ihE5jKwniAt9Wa1lHBnX4xDPjtSL//WJMqno9e0WVl4FyO 1yzBT9fQa7xTA3vVjS6fl2k3l0Hv4QwgH7fJ12k0cYOQDWrly4/eednGux7tgOM4ZS4a IYSA== X-Gm-Message-State: AMke39n0ItV/qTX+hg+B9dXj6BMDt3gdYhWTZAJlfa3RAJGX+YKGCLbF5S6IqMKBwM3USSOc X-Received: by 10.28.226.67 with SMTP id z64mr5432924wmg.137.1487124892156; Tue, 14 Feb 2017 18:14:52 -0800 (PST) Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com. [74.125.82.50]) by smtp.gmail.com with ESMTPSA id e74sm3434514wmd.2.2017.02.14.18.14.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 18:14:51 -0800 (PST) Received: by mail-wm0-f50.google.com with SMTP id r141so30610363wmg.1 for ; Tue, 14 Feb 2017 18:14:51 -0800 (PST) X-Received: by 10.28.173.140 with SMTP id w134mr5557538wme.56.1487124891288; Tue, 14 Feb 2017 18:14:51 -0800 (PST) MIME-Version: 1.0 From: Emil Ivov Date: Wed, 15 Feb 2017 02:14:40 +0000 X-Gmail-Original-Message-ID: Message-ID: To: "perc@ietf.org" Content-Type: multipart/alternative; boundary=001a11444f82e1e2750548883e0c Archived-At: Subject: [Perc] Impersonation X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 02:14:55 -0000 --001a11444f82e1e2750548883e0c Content-Type: text/plain; charset=UTF-8 While looking at the specs it wasn't immediately obvious to me exactly what would prevent participant A in a PERC call to impersonate participant B by simply sending with their SSRC. Everyone's e2e key is known to everyone else and all the keys are symmetric. Have I missed something or is this a known limitation that we have stated in the docs? If so could someone please point me to the relevant place? Thanks, Emil -- https://jitsi.org -- sent from my mobile --001a11444f82e1e2750548883e0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
While looking at the specs it wasn't immediately obvious to me exa= ctly what would prevent participant A in a PERC call to impersonate partici= pant B by simply sending with their SSRC. Everyone's e2e key is known t= o everyone else and all the keys are symmetric.

Ha= ve I missed something or is this a known limitation that we have stated in = the docs? If so could someone please point me to the relevant place?
<= div>
Thanks,
Emil

--=C2=A0=
--
sent from my= mobile
--001a11444f82e1e2750548883e0c-- From nobody Tue Feb 14 19:37:44 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D681612949E for ; Tue, 14 Feb 2017 19:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 rQUAcIZ2B4dM for ; Tue, 14 Feb 2017 19:37:39 -0800 (PST) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (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 4471E12970F for ; Tue, 14 Feb 2017 19:37:39 -0800 (PST) Received: by mail-pf0-x231.google.com with SMTP id 202so24710804pfx.2 for ; Tue, 14 Feb 2017 19:37:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q02AbbPr8QKVUJLNhUnpuuCEaABJCU2xsdaccNwVsGs=; b=tT7YcfBxQ3wdN4JT8Ytw8he64ATEIITmYmYyL18cc5reYWCemBuxa/sz9UxbWeqb1V Y8DNLXHftL0SQEL63YI+g0jaGI36OGkE0ET2fIFvkh4xFZNHGzmhdsx08hb7PcggwP57 npFAcc10+VmFdTT5hk47NujAv78VVeskT4WgW0eI8b5CaTMuIH2l9PVUdw+lMvxTLK5A xhC+qJQsNIXfYqx4Dm1mGnk6q9O2mbfCZccG0NIJSplrSgknqtfV1LvrPCcMkudfZ0xL yX3nGRbAgHRP1m0JwsJhvSQLj7wGVTBkOLr2ZGv1JN8vF/InfEjAkvvDvLPSn85gXBXV hG7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q02AbbPr8QKVUJLNhUnpuuCEaABJCU2xsdaccNwVsGs=; b=UhulMwZfhCjvjaSXfPerTFQxdKfJKwGaOmU3GaZM5OXT0TLaVUGOHdXCrb5B4Z0J0E xDRmqnwe8tJsjGr+tCjpd58+o1sTaWjsPZ4c03p+FE+5GyK9T7I4TizYRvOlFEb7NpIf sMpo289BPV9qsG23Y/vURPZAcz6Ios04kPq2C8fJ7WP1n3YpgNFK6qX/XazOUoiFJCUs MglBWFUNgoDT2TMgYVPinA9+81LIzDAGYDgh3L/Y78Hg4xTdsz7c9iflFGCnMGIXxXVO Znjp/Sj4CkUF4cYpGN0IYOsESOMuSkh2eb7ZGRPWic909U9QsqA+sfdA/no+WObH3xfr WqZA== X-Gm-Message-State: AMke39n5deeLMFi8gpnIs28i+rKyUff12/cPMUNZKExeDOdOsak6RooBj7H1/K4cJmGQEQ== X-Received: by 10.99.123.3 with SMTP id w3mr36078214pgc.155.1487129858840; Tue, 14 Feb 2017 19:37:38 -0800 (PST) Received: from [10.122.118.53] (mobile-166-176-184-31.mycingular.net. [166.176.184.31]) by smtp.gmail.com with ESMTPSA id e129sm3794619pfe.8.2017.02.14.19.37.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 19:37:37 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-23D4FD08-87C4-4053-851D-49BBDE67F0CB Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Tue, 14 Feb 2017 19:37:36 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: To: Emil Ivov Archived-At: Cc: "perc@ietf.org" Subject: Re: [Perc] Impersonation X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 03:37:41 -0000 --Apple-Mail-23D4FD08-87C4-4053-851D-49BBDE67F0CB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Presumably the MDD would check the SSRC against the endpoint address so as t= o avoid forgery.=20 > On Feb 14, 2017, at 6:14 PM, Emil Ivov wrote: >=20 > While looking at the specs it wasn't immediately obvious to me exactly wha= t would prevent participant A in a PERC call to impersonate participant B by= simply sending with their SSRC. Everyone's e2e key is known to everyone els= e and all the keys are symmetric. >=20 > Have I missed something or is this a known limitation that we have stated i= n the docs? If so could someone please point me to the relevant place? >=20 > Thanks, > Emil >=20 > --=20 > https://jitsi.org > --=20 > sent from my mobile > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc --Apple-Mail-23D4FD08-87C4-4053-851D-49BBDE67F0CB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Presumably the MDD would ch= eck the SSRC against the endpoint address so as to avoid forgery. 

On Feb 14, 2017, at 6:14 PM, Emil Ivov <eivov@atlassian.com> wrote:

While looking at the specs it wasn't immediately obvi= ous to me exactly what would prevent participant A in a PERC call to imperso= nate participant B by simply sending with their SSRC. Everyone's e2e key is k= nown to everyone else and all the keys are symmetric.

Have I missed something or is this a known limitation that we have stated= in the docs? If so could someone please point me to the relevant place?

Thanks,
Emil

--&nbs= p;
--
sent from my= mobile
____________________= ___________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman= /listinfo/perc
= --Apple-Mail-23D4FD08-87C4-4053-851D-49BBDE67F0CB-- From nobody Tue Feb 14 20:11:25 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848D91299B4 for ; Tue, 14 Feb 2017 20:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=atlassian-com.20150623.gappssmtp.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 0Pt55MkieFvW for ; Tue, 14 Feb 2017 20:11:22 -0800 (PST) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 EA77B1294EE for ; Tue, 14 Feb 2017 20:11:21 -0800 (PST) Received: by mail-wr0-x22c.google.com with SMTP id o16so183017256wra.1 for ; Tue, 14 Feb 2017 20:11:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=atlassian-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VSphLbtl7HLbJgM8t+4xBK0KsgYUp0SHw5SKs4ZCec0=; b=SJ0LmXuS0i1E2h1YKhNONAjkL2lnbBajB5vDCL+QNQtM7WmhvaDVmb7fa8Mlx8/JAr wNdPIhbDOzkx7+DQiZWBNKB5/8bt+LZEiCv4ErM1xZLVDHthO+TjBZ0bTbmNd65D8MEe J2rRfRsDVE7J+HPDO7QJ0q9jrtznPUnciW5h6mbY7CecmBlL9j5Pe3aaz/DdgDzAgptk bLMiXVlndL4Tq14QhErENR+FhfP3zmLgVfobetmy/2Idxpftp6xR+uoQ+pu1d8NNoSFe L9opgc/yA6UD4JVea7DzrNs4IatGjHYIJZBIyLAJ7xdGK4arwFlwk70LT8TebpteIqsf 9I6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VSphLbtl7HLbJgM8t+4xBK0KsgYUp0SHw5SKs4ZCec0=; b=c5LczxC81N2MajXKoxV2Jrum6JRi19nAMufXrjvDpzhiSzHNnI52R4XSLayxNSB+yw OPR6dTVexSXtddWXyvfDx9R+F1udBPM0YQ6VobcxKAKDpxPFl5bm5f97wlGb57IwNbM3 76wCIuO0+wOixC/j8EWOEKQj58CFnyn918LF7GG5a7+KwW6245tXYtaoOkQC2qvfgwTe ccXA6jvZl+nK+0Rl1auu9fegSj40lfzNLK8tzzTYYFePgHKXv7yIWlDybTJq/7VTjAE3 qf8Ik+IJWaM96AMaG+lTPoX0iy/ivk0xu57AUiH+A2zFMUimkY7bW7lWBDSBREXj+9Hf 6XLQ== X-Gm-Message-State: AMke39mAarfCL9QKIA/AEaoRlYpvpDS4D9ngb8Kb/pufkA+MNlYyO2RHVWlW9wOSYiHPdLyT X-Received: by 10.223.160.84 with SMTP id l20mr26936603wrl.106.1487131880226; Tue, 14 Feb 2017 20:11:20 -0800 (PST) Received: from mail-wr0-f182.google.com (mail-wr0-f182.google.com. [209.85.128.182]) by smtp.gmail.com with ESMTPSA id 36sm3195855wrz.8.2017.02.14.20.11.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 20:11:19 -0800 (PST) Received: by mail-wr0-f182.google.com with SMTP id i10so182978807wrb.0 for ; Tue, 14 Feb 2017 20:11:19 -0800 (PST) X-Received: by 10.223.170.137 with SMTP id h9mr26849005wrc.202.1487131879140; Tue, 14 Feb 2017 20:11:19 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Emil Ivov Date: Wed, 15 Feb 2017 04:11:08 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=94eb2c1b45d2640d1e054889df01 Archived-At: Cc: "perc@ietf.org" Subject: Re: [Perc] Impersonation X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 04:11:23 -0000 --94eb2c1b45d2640d1e054889df01 Content-Type: text/plain; charset=UTF-8 That would be one way, yeah, but then isn't the whole idea of PERC to not trust the mdd? If thats all we have then we are basicaly saying: we don't trust the mdd to not attack us, but we surely trust it to prevent others from attacking us ... On Tue, 14 Feb 2017 at 21:37, Bernard Aboba wrote: > Presumably the MDD would check the SSRC against the endpoint address so as > to avoid forgery. > > On Feb 14, 2017, at 6:14 PM, Emil Ivov wrote: > > While looking at the specs it wasn't immediately obvious to me exactly > what would prevent participant A in a PERC call to impersonate participant > B by simply sending with their SSRC. Everyone's e2e key is known to > everyone else and all the keys are symmetric. > > Have I missed something or is this a known limitation that we have stated > in the docs? If so could someone please point me to the relevant place? > > Thanks, > Emil > > -- > https://jitsi.org > -- > sent from my mobile > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > > -- sent from my mobile --94eb2c1b45d2640d1e054889df01 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That would be one way, yeah, but then isn't the whole idea of= PERC to not trust the mdd?

If thats all we = have then we are basicaly saying: we don't trust the mdd to not attack = us, but we surely trust it to prevent others from attacking us ...

On Tue, 14 Feb 2017 at 21:37, Bernard= Aboba <bernard.aboba@gmail.c= om> wrote:
Presumably = the MDD would check the SSRC against the endpoint address so as to avoid fo= rgery.=C2=A0
<= br class=3D"gmail_msg">On Feb 14, 2017, at 6:14 PM, Emil Ivov <eivov= @atlassian.com> wrote:

While looking at the specs it wasn't immed= iately obvious to me exactly what would prevent participant A in a PERC cal= l to impersonate participant B by simply sending with their SSRC. Everyone&= #39;s e2e key is known to everyone else and all the keys are symmetric.

Have I missed something or is this a known limitation that we have s= tated in the docs? If so could someone please point me to the relevant plac= e?

Thanks,
Emil

--=C2= =A0
https://jitsi.org
--
sent from my mobile
___= ____________________________________________
= Perc mailing list
<= span class=3D"gmail_msg">Perc@ietf.org
https://www.ietf.org/mailman/listinfo= /perc
--
sent from my mobile
--94eb2c1b45d2640d1e054889df01-- From nobody Tue Feb 14 21:20:12 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4C0129591 for ; Tue, 14 Feb 2017 21:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 QU4zY6BTBl-2 for ; Tue, 14 Feb 2017 21:20:08 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 DCC8D12946B for ; Tue, 14 Feb 2017 21:20:08 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id c73so25159322pfb.0 for ; Tue, 14 Feb 2017 21:20:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=NBPgG1Ff+a9ggUKEfPYGNXJRNiGRZk0BCXK7x+0Mvew=; b=Ms/bnuHwi0qXiEF89f+diEBeSM7Lzv81tC2G2iNidwmKwZzXharcWpZ6xVWHFRPIAY dtOJAa7dXK5EkOK1iEOUHlvvMV64ihpHfmgfjhcx9YpCWijS/OW01wpbOM5nwkz7vTNd jbHkgxY/1ViBo1P4sQSb81uLo1S/RSkaEWIFs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=NBPgG1Ff+a9ggUKEfPYGNXJRNiGRZk0BCXK7x+0Mvew=; b=g02IzCHp32PyfIbauQmQxAZCHv6Qk17c1TsZzgo9rIJ8EjO0d7KYJaFHl0q9hV2mI3 JPjL1ZosMpwEtCD0w3CyuXEQuwdiqaAi1Rq6PHjy/oK0hDoku6OAKp8gjQyr9MYzqIiF wOhIiaYWyqtpqHeLhRyKqKtrhpoNrCnIm2jv2ZbSLswnUPzuvOJ5wErke1B18z3QmluT csZioXfU42v6q64CfkcIs3YYBaI68tUGtAzEwdLaHvi42ZtLlUEzlyDnIyFHxehP8mFK Yn8Cji6ZqCNC6/xxD4kFqaX6HiB+VdiGAbLp5tWhq2pYV26kCzEdo07pNJlwmCuuTakG nYkA== X-Gm-Message-State: AMke39lrejogfl/cEntYNpTQjdheiMIPPTNgPHAQYNX6Bh/3lIZPtB68mkMLi5F8fyb+wzZP X-Received: by 10.84.175.74 with SMTP id s68mr41023081plb.155.1487136008277; Tue, 14 Feb 2017 21:20:08 -0800 (PST) Received: from ?IPv6:2601:647:4601:ec84:718d:637b:3a29:45b3? ([2601:647:4601:ec84:718d:637b:3a29:45b3]) by smtp.gmail.com with ESMTPSA id 64sm4209109pfq.112.2017.02.14.21.20.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 21:20:06 -0800 (PST) From: Nils Ohlmeier Message-Id: <40280E69-8437-4036-A0F5-4BB48FDD83E0@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_4ED3E29B-BD97-4476-ABDE-2155235A0FC7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 14 Feb 2017 21:20:04 -0800 In-Reply-To: To: Emil Ivov References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "perc@ietf.org" Subject: Re: [Perc] Impersonation X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 05:20:10 -0000 --Apple-Mail=_4ED3E29B-BD97-4476-ABDE-2155235A0FC7 Content-Type: multipart/alternative; boundary="Apple-Mail=_28E2D3F4-3EAA-416E-8A4B-0AFBA08B122B" --Apple-Mail=_28E2D3F4-3EAA-416E-8A4B-0AFBA08B122B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m under the impression that the whole identity topic has not = been solved yet for a PERC call. The KDD knows who is who in a PERC call, based on cert fingerprints and = the DTLS connections it has established with each participant. The MDD can also identify each participant based on the hop-by-hop keys. = But as you pointed out the MDD should better not be trusted to forward = that information correctly. If we really want to prevent impersonation I guess we would have to have = the clients sign their e2e SRTP packets with a private key. Best Nils Ohlmeier > On Feb 14, 2017, at 18:14, Emil Ivov wrote: >=20 > While looking at the specs it wasn't immediately obvious to me exactly = what would prevent participant A in a PERC call to impersonate = participant B by simply sending with their SSRC. Everyone's e2e key is = known to everyone else and all the keys are symmetric. >=20 > Have I missed something or is this a known limitation that we have = stated in the docs? If so could someone please point me to the relevant = place? >=20 > Thanks, > Emil >=20 > -- > https://jitsi.org > -- > sent from my mobile > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc --Apple-Mail=_28E2D3F4-3EAA-416E-8A4B-0AFBA08B122B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80=99m under the impression that the whole identity = topic has not been solved yet for a PERC call.

The KDD knows who is who in a PERC = call, based on cert fingerprints and the DTLS connections it has = established with each participant.

The MDD can also identify each = participant based on the hop-by-hop keys. But as you pointed out the MDD = should better not be trusted to forward that information = correctly.

If = we really want to prevent impersonation I guess we would have to have = the clients sign their e2e SRTP packets with a private key.

Best
  Nils Ohlmeier

On Feb 14, 2017, at 18:14, Emil = Ivov <eivov@atlassian.com> wrote:

While = looking at the specs it wasn't immediately obvious to me exactly what = would prevent participant A in a PERC call to impersonate participant B = by simply sending with their SSRC. Everyone's e2e key is known to = everyone else and all the keys are symmetric.

Have I missed something or is this a = known limitation that we have stated in the docs? If so could someone = please point me to the relevant place?

Thanks,
Emil

-- 
https://jitsi.org
--
sent = from my mobile
_______________________________________________
Perc = mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc

= --Apple-Mail=_28E2D3F4-3EAA-416E-8A4B-0AFBA08B122B-- --Apple-Mail=_4ED3E29B-BD97-4476-ABDE-2155235A0FC7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYo+UFAAoJEJ3NnGfOORkktOgQALBpb2VUJnqo+yQpTlhSiIH2 NeKC1a3yTS8/gmq9whgIkuS/3tyBxPIxdZU3VACWoY5/b8x4Mluz2CReF5Wi8NWE 3s5mzprih2M6gnKbfxzZJ2oIsys+5LXevVb2LmvRX4K9AleIvgtQbVvxydkhVneB wamBVcc8BAFVBOEpUmH6fV3bvohM1M91hvO9dbqB2cFbFZ7vLyuUic/fFq88vPE6 5MbxQgM4+oM/EJu0RiUXZFxtWBSIcIcJom1WbCmnmWrZ+6uvT20wJXt4hPAtT5vS EoKzUKOixo+6tz3jB7BNP7gIsqjpBloOTsNXKVi9BZh9Bpm5bRUDGoVE3Sk0JXnv 9IMMTD7t2iIHLWMW6jfGbN1HyW39vj7UdLaXTlDjgU9YvTqp14gBFzlNmsIiwslR Y04RO+xkveOMS8h6nchCgQJXfvi1CTJgK1+gd9OQNG0vYm1WUeZRyUSPMOQ2QG2w mkdX+JQDaolyZ3n7Mc01veb/6IiRJvVevUppkAoa1zPrnHCDofs4v12cwVbczpM0 kQq5YdFSpSEanTN4YFwEUa/03Ek2uyou/VebNHqHKRlFwvnII5yS0p926fqjt7oV uTXuOmGHGWelsNqUCjSIW9cQLheOEzUKtc47TTFSAg4wheyiMcBHRV7VDaZiFMBX td8ajJMTcPPC6TSsPx7Z =Fpfu -----END PGP SIGNATURE----- --Apple-Mail=_4ED3E29B-BD97-4476-ABDE-2155235A0FC7-- From nobody Tue Feb 14 22:01:27 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF0C129759 for ; Tue, 14 Feb 2017 22:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 aY8-Qz_pw0ME for ; Tue, 14 Feb 2017 22:01:24 -0800 (PST) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 69780129A04 for ; Tue, 14 Feb 2017 22:01:24 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id l19so77238195ywc.2 for ; Tue, 14 Feb 2017 22:01:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xi570Ra5jkS35Tr9a+quxYSU4ZziJITR4aIAH8cz5oU=; b=Je/Y7VswAYs/2QnRPJqEjVZ10QZpT8lU68A7xNxOB3ORhpSKqcoxqlGdODbtiCzgeG /7KkIELzZ154o7rafK6+Ugssme0WzZxkgHyfBPM4uK/lMUaIVtsh57kKEIqAPGsk31Xm UaA1Jlp2Cfy7zoyUC4Eaws7HCk2pHkJbJ3cClYi7Xua1ssHP/vMRgHAglEStXrbsymFU q3A5X41mNgx24Ce1jV7xYB0LTJZ0VmTi1tJfDbut1e4K+LJvjP4/1mBUKmmds4BEmX/T 2ojM4yNAez9CnAOHtusXqaZUGLAx/paRPBMHV5lG2BpC9Uvcy81unV8dWF2vQ4l/luxW IBkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xi570Ra5jkS35Tr9a+quxYSU4ZziJITR4aIAH8cz5oU=; b=eRQ2qU1FKfMN5OL94vrGq9u5ozXEFoAi2ccE5Ih9iVyktxA4bB/+FW1PebiWRU32IH v/LeLUs4k/7wZY7H/IoYUs6/OJB8j/mKYO7170XbnVRsdFbxwWhSmHK//I0C80VL0Ejo AU6I8jq6VrCfF420xGK4IXOe+7JB3LRnre/znO9gBe/nGI6FkySlN7+/6GLuQ8xjtuKA Hv4UADyM5OcBUo+9X84F/lilr1aQ6ek4bY5TuER1KcDTTKvGB1uxgMP1cV3IoJOXLivc ppU5xYgNlq3WN8N/AWwR0akhH4y/5+io583/kVSHFnO8PQspbVgD2vVyXtADXGHiSUw9 H//w== X-Gm-Message-State: AMke39m476lJOfBKVfzABmYeivctSAhxDvcmnHEtTe2gvTrc9wjjTDmxUgEoSnzGMt7LDJA7KC/QKLkoNIBuxw== X-Received: by 10.129.132.77 with SMTP id u74mr24380328ywf.125.1487138483685; Tue, 14 Feb 2017 22:01:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Tue, 14 Feb 2017 22:00:43 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 14 Feb 2017 22:00:43 -0800 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=001a114f09960d7ea305488b69f9 Archived-At: Cc: "perc@ietf.org" , Bernard Aboba Subject: Re: [Perc] Impersonation X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 06:01:26 -0000 --001a114f09960d7ea305488b69f9 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 14, 2017 at 8:11 PM, Emil Ivov wrote: > That would be one way, yeah, but then isn't the whole idea of PERC to not > trust the mdd? > No. It's to have confidentiality against the MDD. If thats all we have then we are basicaly saying: we don't trust the mdd to > not attack us, but we surely trust it to prevent others from attacking us > ... > No, because the limit of the attack is allowing one member of the conference (which the MDD cannot control) to impersonate another. -Ekr > > On Tue, 14 Feb 2017 at 21:37, Bernard Aboba > wrote: > >> Presumably the MDD would check the SSRC against the endpoint address so >> as to avoid forgery. >> >> On Feb 14, 2017, at 6:14 PM, Emil Ivov wrote: >> >> While looking at the specs it wasn't immediately obvious to me exactly >> what would prevent participant A in a PERC call to impersonate participant >> B by simply sending with their SSRC. Everyone's e2e key is known to >> everyone else and all the keys are symmetric. >> >> Have I missed something or is this a known limitation that we have stated >> in the docs? If so could someone please point me to the relevant place? >> >> Thanks, >> Emil >> >> -- >> https://jitsi.org >> -- >> sent from my mobile >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >> >> -- > sent from my mobile > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > > --001a114f09960d7ea305488b69f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 14, 2017 at 8:11 PM, Emil Ivov <eivov@atlassian.com&= gt; wrote:
That would be= one way, yeah, but then isn't the whole idea of PERC to not trust the = mdd?

No. It's to have confi= dentiality against the MDD.


If thats all we have then we are basicaly saying: w= e don't trust the mdd to not attack us, but we surely trust it to preve= nt others from attacking us ...

No, b= ecause the limit of the attack is allowing one member of the conference (wh= ich the MDD cannot control) to impersonate another.

-Ekr
=C2=A0

On Tue, 1= 4 Feb 2017 at 21:37, Bernard Aboba <bernard.aboba@gmail.com> wrote:
Presumably the MDD would check the SSRC against t= he endpoint address so as to avoid forgery.=C2=A0

On Feb 14, 2017, at 6:14= PM, Emil Ivov <eivov@atlassian.com> wrot= e:

While looking at the specs it wasn'= ;t immediately obvious to me exactly what would prevent participant A in a = PERC call to impersonate participant B by simply sending with their SSRC. E= veryone's e2e key is known to everyone else and all the keys are symmet= ric.

Have I missed something or is this a known limitation that we have st= ated in the docs? If so could someone please point me to the relevant place= ?

Thanks,
Emil

--=C2= =A0
http= s://jitsi.org
--
sent from my mobil= e
_______________________________________________
Perc mailing list
P= erc@ietf.org
https://www.ietf.org/mailman/listinfo/perc
=
--
sent from my mobile

_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc


--001a114f09960d7ea305488b69f9-- From nobody Tue Feb 14 23:54:40 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C205129480 for ; Tue, 14 Feb 2017 23:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8SbM2pKa-IL3 for ; Tue, 14 Feb 2017 23:54:36 -0800 (PST) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (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 5F060128B37 for ; Tue, 14 Feb 2017 23:54:36 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id 202so26642447pfx.2 for ; Tue, 14 Feb 2017 23:54:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WUdSw0Mq/6yZqb3akV1gsZyUgQkX12i9jHYu9doazXA=; b=Ldo4tmy+mYf07UFstHNhoCAyRbPRVEiQkEKfgKLzjSIBTFUbbz8W8RGgrgkMFoHvcu ZOJtfz+qz/tWNECeX5jTctQK5vUmq9DiB7TehWr4hPzGWZR5bg2XptLZxi0DqIBB3wQ0 NCImJhVFNcH9DSS30TjWz8lvglfDfKOnKtBbhWl3JgoeWsUXAhTQ/riEnaqKcStFVTOG gEPHJVD06IsPvEMQFNrzkorFriHDlJCNpq217aoXBJNBNwUvvkrUYn9r3qPjnzbNboP9 0hX+TsjurSTZeIt+uKbq30R8YEMVscMO83dOAwA4MX/9SK1JYAW9/WYunswvDmUmsXj1 ykwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WUdSw0Mq/6yZqb3akV1gsZyUgQkX12i9jHYu9doazXA=; b=qnfV8sX2zrwHwhZKH6yEr1HuVD0ng35lzDsvb0bTY/rQm9pQwdrj3X+oYNb30iYD4L wc/hYbX7jvY/Ylw/nLzLH8o1ZjQxvh6IHspeVGx+Cu4iWv62thB+05Hegj/o9zBgtKK/ Gfq/0W3CyVqdi8mwlRL4FS6A5ziYokk8kvdepjBsPqK6zyW3eAjh+RiDf9TNACnwe3Ec svS35icqj321M0q0/nR5j+1wq0m26+fHaWgoV7MbQm+MPXpZcKqVaX5+QkPa/aK4Qa77 buhgHEpNsDB9VqR4V63bUzAOEjoh8cJsFxFr0quRed4E1c0QAPrGE35nMYUfE2Wqeh5j FtXA== X-Gm-Message-State: AMke39m1FeHE0vuPMSurTRKoJP89XBMTeY373wzMjY1+8UGuf49ZjB/YhUxtSSEfaDjZPw== X-Received: by 10.99.136.198 with SMTP id l189mr36782290pgd.45.1487145275897; Tue, 14 Feb 2017 23:54:35 -0800 (PST) Received: from [192.168.1.101] (c-24-19-245-25.hsd1.wa.comcast.net. [24.19.245.25]) by smtp.gmail.com with ESMTPSA id z70sm5463408pff.26.2017.02.14.23.54.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 23:54:35 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-3BF2DA5E-D112-49AF-8237-322712F61EB1 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (14D27) In-Reply-To: Date: Tue, 14 Feb 2017 23:54:34 -0800 Content-Transfer-Encoding: 7bit Message-Id: <4AAAD833-C7D6-4EEA-9BA8-3AE3E9259A45@gmail.com> References: To: Emil Ivov Archived-At: Cc: "perc@ietf.org" Subject: Re: [Perc] Impersonation X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 07:54:38 -0000 --Apple-Mail-3BF2DA5E-D112-49AF-8237-322712F61EB1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Comments below. > On Feb 14, 2017, at 20:11, Emil Ivov wrote: >=20 > That would be one way, yeah, but then isn't the whole idea of PERC to not t= rust the mdd? [BA] The MDD is not to obtain the payload in cleartext. But I do not believe= that the design attempts to mitigate threats from a rogue MDD or even from p= assive surveillance which can obtain just about everything worth knowing oth= er than the payload contents (the meeting participant locations, the discuss= ion leaders, the format of the meeting, the interaction dynamics, etc.) >=20 > If thats all we have then we are basicaly saying: we don't trust the mdd t= o not attack us, but we surely trust it to prevent others from attacking us .= .. >=20 >> On Tue, 14 Feb 2017 at 21:37, Bernard Aboba wro= te: >> Presumably the MDD would check the SSRC against the endpoint address so a= s to avoid forgery.=20 >>=20 >>> On Feb 14, 2017, at 6:14 PM, Emil Ivov wrote: >>>=20 >>> While looking at the specs it wasn't immediately obvious to me exactly w= hat would prevent participant A in a PERC call to impersonate participant B b= y simply sending with their SSRC. Everyone's e2e key is known to everyone el= se and all the keys are symmetric. >>>=20 >>> Have I missed something or is this a known limitation that we have state= d in the docs? If so could someone please point me to the relevant place? >>>=20 >>> Thanks, >>> Emil >>>=20 >>> --=20 >>> https://jitsi.org >>> --=20 >>> sent from my mobile >>=20 >>> _______________________________________________ >>> Perc mailing list >>> Perc@ietf.org >>> https://www.ietf.org/mailman/listinfo/perc >=20 > --=20 > sent from my mobile --Apple-Mail-3BF2DA5E-D112-49AF-8237-322712F61EB1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Comments below.
<= br>On Feb 14, 2017, at 20:11, Emil Ivov <eivov@atlassian.com> wrote:

That would be one way, yeah, but then isn't the whole id= ea of PERC to not trust the mdd?

[BA] The MDD is not to obtain the payload in cleartext. But I do not belie= ve that the design attempts to mitigate threats from a rogue MDD or even fro= m passive surveillance which can obtain just about everything worth knowing o= ther than the payload contents (the meeting participant locations, the discu= ssion leaders, the format of the meeting, the interaction dynamics, etc.)

If thats all we hav= e then we are basicaly saying: we don't trust the mdd to not attack us, but w= e surely trust it to prevent others from attacking us ...

On Tue, 14 Feb 2017 at 21:37, Bernard Aboba <= bernard.aboba@gmail.com> w= rote:
Presumably the MDD would c= heck the SSRC against the endpoint address so as to avoid forgery. 

On Feb 14, 2017, at 6:14 PM, Emil Ivov <eivov@atlassian.com>= ; wrote:

While looking at the specs it wasn't immediately obvious to me exactly= what would prevent participant A in a PERC call to impersonate participant B= by simply sending with their SSRC. Everyone's e2e key is known to everyone e= lse and all the keys are symmetric.

Have I missed something or is thi= s a known limitation that we have stated in the docs? If so could someone pl= ease point me to the relevant place?

Thanks,
Emil

-- 
https://jitsi.org
--
sent from my mobile
______= _________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc<= /span>
--
se= nt from my mobile
= --Apple-Mail-3BF2DA5E-D112-49AF-8237-322712F61EB1-- From nobody Wed Feb 15 02:25:17 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBFB1294D8 for ; Wed, 15 Feb 2017 02:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 MrmF6pFY49tX for ; Wed, 15 Feb 2017 02:25:12 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25222129418 for ; Wed, 15 Feb 2017 02:25:12 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGN30791; Wed, 15 Feb 2017 10:25:09 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 15 Feb 2017 10:25:07 +0000 Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by nkgeml414-hub.china.huawei.com (10.98.56.75) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 15 Feb 2017 18:25:04 +0800 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0301.000; Wed, 15 Feb 2017 18:25:01 +0800 From: Roni Even To: Emil Ivov , Bernard Aboba Thread-Topic: [Perc] Impersonation Thread-Index: AQHShzFRX9aWoNBoWEOup0IGORw75aFo5TMAgAAJXwCAAOw+wA== Date: Wed, 15 Feb 2017 10:25:01 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD774149@DGGEMM506-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD774149DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.58A42C85.0342, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 90c1eb25922ec0a4bda1c75cca090e68 Archived-At: Cc: "perc@ietf.org" Subject: Re: [Perc] Impersonation X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 10:25:16 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD774149DGGEMM506MBXchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RW1pbCwNCk15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgTUREIGlzIOKAnG1peGVy4oCdIGFz IHNwZWNpZmllZCBpbiB0aGUgY29uZmVyZW5jaW5nIGZyYW1ld29yayBmb3IgU0lQIFJGQzQzNTMg c2VjdGlvbiA0LjMuIEl0IGlzIG5vdCBjb25mZXJlbmNlIOKAnGF3YXJl4oCdLiBUaGUgdHJ1c3Qg aXMgYWJvdXQgY29uZmlkZW50aWFsaXR5IG9mIHRoZSBtZWRpYS4gVGhlIGlzc3VlIG9mIGtub3dp bmcgd2hpY2ggU1NSQyBiZWxvbmdzIHRvIGVhY2ggcGFydGljaXBhbnQgaXMgbm90IHNvbWV0aGlu ZyB0aGUgTUREIGNhbiBrbm93LiBCVFc6IHRoaXMgaW5mb3JtYXRpb24gaXMgYXZhaWxhYmxlIGlu IHRoZSBjb25mZXJlbmNlIGV2ZW50IHBhY2thZ2UuDQpJIHRoaW5rIHRoaXMgaXMgYW5vdGhlciBy ZWFzb24gdG8gaGF2ZSBhIFBFUkMgc2lnbmFsaW5nIGRvY3VtZW50IHRoYXQgd2lsbCBkaXNjdXNz IGhvdyBjb25mZXJlbmNlIHBhcnRpY2lwYW50cyBrbm93IHRoYXQgdGhleSBuZWVkIHRvIHVzZSBQ RVJDIGluIHRoZSBmaXJzdCBwbGFjZQ0KUm9uaQ0KDQpGcm9tOiBQZXJjIFttYWlsdG86cGVyYy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRW1pbCBJdm92DQpTZW50OiDXmdeV150g15Mg MTUg16TXkdeo15XXkNeoIDIwMTcgMDY6MTENClRvOiBCZXJuYXJkIEFib2JhDQpDYzogcGVyY0Bp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtQZXJjXSBJbXBlcnNvbmF0aW9uDQoNClRoYXQgd291bGQg YmUgb25lIHdheSwgeWVhaCwgYnV0IHRoZW4gaXNuJ3QgdGhlIHdob2xlIGlkZWEgb2YgUEVSQyB0 byBub3QgdHJ1c3QgdGhlIG1kZD8NCg0KSWYgdGhhdHMgYWxsIHdlIGhhdmUgdGhlbiB3ZSBhcmUg YmFzaWNhbHkgc2F5aW5nOiB3ZSBkb24ndCB0cnVzdCB0aGUgbWRkIHRvIG5vdCBhdHRhY2sgdXMs IGJ1dCB3ZSBzdXJlbHkgdHJ1c3QgaXQgdG8gcHJldmVudCBvdGhlcnMgZnJvbSBhdHRhY2tpbmcg dXMgLi4uDQoNCk9uIFR1ZSwgMTQgRmViIDIwMTcgYXQgMjE6MzcsIEJlcm5hcmQgQWJvYmEgPGJl cm5hcmQuYWJvYmFAZ21haWwuY29tPG1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbT4+IHdy b3RlOg0KUHJlc3VtYWJseSB0aGUgTUREIHdvdWxkIGNoZWNrIHRoZSBTU1JDIGFnYWluc3QgdGhl IGVuZHBvaW50IGFkZHJlc3Mgc28gYXMgdG8gYXZvaWQgZm9yZ2VyeS4NCg0KT24gRmViIDE0LCAy MDE3LCBhdCA2OjE0IFBNLCBFbWlsIEl2b3YgPGVpdm92QGF0bGFzc2lhbi5jb208bWFpbHRvOmVp dm92QGF0bGFzc2lhbi5jb20+PiB3cm90ZToNCldoaWxlIGxvb2tpbmcgYXQgdGhlIHNwZWNzIGl0 IHdhc24ndCBpbW1lZGlhdGVseSBvYnZpb3VzIHRvIG1lIGV4YWN0bHkgd2hhdCB3b3VsZCBwcmV2 ZW50IHBhcnRpY2lwYW50IEEgaW4gYSBQRVJDIGNhbGwgdG8gaW1wZXJzb25hdGUgcGFydGljaXBh bnQgQiBieSBzaW1wbHkgc2VuZGluZyB3aXRoIHRoZWlyIFNTUkMuIEV2ZXJ5b25lJ3MgZTJlIGtl eSBpcyBrbm93biB0byBldmVyeW9uZSBlbHNlIGFuZCBhbGwgdGhlIGtleXMgYXJlIHN5bW1ldHJp Yy4NCg0KSGF2ZSBJIG1pc3NlZCBzb21ldGhpbmcgb3IgaXMgdGhpcyBhIGtub3duIGxpbWl0YXRp b24gdGhhdCB3ZSBoYXZlIHN0YXRlZCBpbiB0aGUgZG9jcz8gSWYgc28gY291bGQgc29tZW9uZSBw bGVhc2UgcG9pbnQgbWUgdG8gdGhlIHJlbGV2YW50IHBsYWNlPw0KDQpUaGFua3MsDQpFbWlsDQoN Ci0tDQpodHRwczovL2ppdHNpLm9yZw0KLS0NCnNlbnQgZnJvbSBteSBtb2JpbGUNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQZXJjIG1haWxpbmcgbGlz dA0KUGVyY0BpZXRmLm9yZzxtYWlsdG86UGVyY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcGVyYw0KLS0NCnNlbnQgZnJvbSBteSBtb2JpbGUNCg== --_000_6E58094ECC8D8344914996DAD28F1CCD774149DGGEMM506MBXchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5nbWFpbG1zZw0KCXttc28tc3R5 bGUtbmFtZTpnbWFpbF9tc2c7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcy LjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkVtaWwsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPk15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgTUREIGlzIOKAnG1p eGVy4oCdIGFzIHNwZWNpZmllZCBpbiB0aGUgY29uZmVyZW5jaW5nIGZyYW1ld29yayBmb3IgU0lQ IFJGQzQzNTMgc2VjdGlvbiA0LjMuIEl0IGlzIG5vdCBjb25mZXJlbmNlIOKAnGF3YXJl4oCdLiBU aGUgdHJ1c3QNCiBpcyBhYm91dCBjb25maWRlbnRpYWxpdHkgb2YgdGhlIG1lZGlhLiBUaGUgaXNz dWUgb2Yga25vd2luZyB3aGljaCBTU1JDIGJlbG9uZ3MgdG8gZWFjaCBwYXJ0aWNpcGFudCBpcyBu b3Qgc29tZXRoaW5nIHRoZSBNREQgY2FuIGtub3cuIEJUVzogdGhpcyBpbmZvcm1hdGlvbiBpcyBh dmFpbGFibGUgaW4gdGhlIGNvbmZlcmVuY2UgZXZlbnQgcGFja2FnZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SSB0aGluayB0aGlzIGlzIGFub3RoZXIgcmVhc29uIHRvIGhhdmUgYSBQ RVJDIHNpZ25hbGluZyBkb2N1bWVudCB0aGF0IHdpbGwgZGlzY3VzcyBob3cgY29uZmVyZW5jZSBw YXJ0aWNpcGFudHMga25vdyB0aGF0IHRoZXkgbmVlZCB0byB1c2UgUEVSQyBpbiB0aGUgZmlyc3QN CiBwbGFjZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Sb25pPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFBlcmMgW21haWx0bzpwZXJjLWJvdW5jZXNA aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVtaWwgSXZvdjxicj4NCjxiPlNlbnQ6PC9i PiA8c3BhbiBsYW5nPSJIRSIgZGlyPSJSVEwiPteZ15XXnSZuYnNwO9eTIDE1INek15HXqNeV15DX qCAyMDE3IDA2OjExPC9zcGFuPjxicj4NCjxiPlRvOjwvYj4gQmVybmFyZCBBYm9iYTxicj4NCjxi PkNjOjwvYj4gcGVyY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1BlcmNdIElt cGVyc29uYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoYXQgd291bGQgYmUgb25lIHdheSwgeWVhaCwgYnV0IHRoZW4gaXNu J3QgdGhlIHdob2xlIGlkZWEgb2YgUEVSQyB0byBub3QgdHJ1c3QgdGhlIG1kZD88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0 aGF0cyBhbGwgd2UgaGF2ZSB0aGVuIHdlIGFyZSBiYXNpY2FseSBzYXlpbmc6IHdlIGRvbid0IHRy dXN0IHRoZSBtZGQgdG8gbm90IGF0dGFjayB1cywgYnV0IHdlIHN1cmVseSB0cnVzdCBpdCB0byBw cmV2ZW50IG90aGVycyBmcm9tIGF0dGFja2luZyB1cyAuLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIDE0IEZlYiAyMDE3IGF0IDIx OjM3LCBCZXJuYXJkIEFib2JhICZsdDs8YSBocmVmPSJtYWlsdG86YmVybmFyZC5hYm9iYUBnbWFp bC5jb20iPmJlcm5hcmQuYWJvYmFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlByZXN1bWFibHkgdGhlIE1ERCB3b3VsZCBjaGVjayB0aGUgU1NSQyBhZ2FpbnN0IHRoZSBl bmRwb2ludCBhZGRyZXNzIHNvIGFzIHRvIGF2b2lkIGZvcmdlcnkuJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIEZlYiAxNCwgMjAxNywgYXQgNjox NCBQTSwgRW1pbCBJdm92ICZsdDs8YSBocmVmPSJtYWlsdG86ZWl2b3ZAYXRsYXNzaWFuLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmVpdm92QGF0bGFzc2lhbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldo aWxlIGxvb2tpbmcgYXQgdGhlIHNwZWNzIGl0IHdhc24ndCBpbW1lZGlhdGVseSBvYnZpb3VzIHRv IG1lIGV4YWN0bHkgd2hhdCB3b3VsZCBwcmV2ZW50IHBhcnRpY2lwYW50IEEgaW4gYSBQRVJDIGNh bGwgdG8gaW1wZXJzb25hdGUgcGFydGljaXBhbnQgQiBieSBzaW1wbHkgc2VuZGluZyB3aXRoIHRo ZWlyIFNTUkMuIEV2ZXJ5b25lJ3MgZTJlIGtleSBpcyBrbm93biB0byBldmVyeW9uZSBlbHNlIGFu ZCBhbGwNCiB0aGUga2V5cyBhcmUgc3ltbWV0cmljLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IYXZlIEkgbWlzc2VkIHNvbWV0aGluZyBvciBp cyB0aGlzIGEga25vd24gbGltaXRhdGlvbiB0aGF0IHdlIGhhdmUgc3RhdGVkIGluIHRoZSBkb2Nz PyBJZiBzbyBjb3VsZCBzb21lb25lIHBsZWFzZSBwb2ludCBtZSB0byB0aGUgcmVsZXZhbnQgcGxh Y2U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkVtaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+LS0mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vaml0c2kub3JnIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly9qaXRzaS5vcmc8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPnNlbnQgZnJvbSBteSBtb2JpbGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iZ21haWxtc2ciPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbG1z ZyI+UGVyYyBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsbXNnIj48 YSBocmVmPSJtYWlsdG86UGVyY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlBlcmNAaWV0Zi5v cmc8L2E+PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbG1zZyI+PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wZXJjIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wZXJjPC9hPjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c2VudCBmcm9tIG15IG1v YmlsZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_6E58094ECC8D8344914996DAD28F1CCD774149DGGEMM506MBXchina_-- From nobody Wed Feb 15 10:04:46 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97503129B0E for ; Wed, 15 Feb 2017 10:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 SJmOaQgw-ipB for ; Wed, 15 Feb 2017 10:04:42 -0800 (PST) Received: from mail-ot0-f176.google.com (mail-ot0-f176.google.com [74.125.82.176]) (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 C1AB912950D for ; Wed, 15 Feb 2017 09:56:09 -0800 (PST) Received: by mail-ot0-f176.google.com with SMTP id 19so10884239oti.2 for ; Wed, 15 Feb 2017 09:56:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=B7N+pcWOaMAJFt89PKogbkmVyP+Fqjc2s2nljNUgPVo=; b=s65GhhPcjRZ1uIaB8AgCR0v+SOUFdWCfXIFY17ryqd0gcuhhtvlEUobYyQ6P6/XMu4 X79XGsphi5WaoW5ZPoH6G2O83Bu83VO9gW+kvvsAEs+8HjCipUEplioo8Agwg//uGKUF Qo37UkQxfavGFxIFYjNf32VIwFxK5teGVrc1bLx5uPt07H8SbeE1ASOdzoJFdu5SeN+n tFlFGB2MvsX/eIR4Vg3xXb5G2sKP5JmzI2LSiJ+F8wlenTDwVLu+pKFD41nHCQQIdL8g KZyZsn4tewIa88bT3NJqAmSyeVB+wlsMaaP9HCysT6pu0jvD/EFOGArGY5/cOxQAM1C+ frqA== X-Gm-Message-State: AMke39m5t0waH8noEpbufSu9SmEQSoHck/WFU+sFisBpMuy6qtfRQX60niyxcEb+BMzIJw== X-Received: by 10.157.48.51 with SMTP id d48mr19295036otc.207.1487181368614; Wed, 15 Feb 2017 09:56:08 -0800 (PST) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id w84sm1784929oiw.21.2017.02.15.09.56.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Feb 2017 09:56:07 -0800 (PST) To: Eric Rescorla References: From: Emil Ivov Organization: Atlassian Message-ID: Date: Wed, 15 Feb 2017 11:56:06 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "perc@ietf.org" , Bernard Aboba Subject: Re: [Perc] Impersonation X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 18:04:43 -0000 On 2/15/17 12:00 AM, Eric Rescorla wrote: > > > On Tue, Feb 14, 2017 at 8:11 PM, Emil Ivov > wrote: > > That would be one way, yeah, but then isn't the whole idea of PERC > to not trust the mdd? > > > No. It's to have confidentiality against the MDD. > > > If thats all we have then we are basicaly saying: we don't trust the > mdd to not attack us, but we surely trust it to prevent others from > attacking us ... > > > No, because the limit of the attack is allowing one member of the > conference (which the MDD cannot control) to impersonate another. You lost me. How do you know what the relationship is between the MDD and that participant and that they are not actually controlled by the same party? Anyways, it is hard to argue how big of a deal this is without having a full implementation in mind (specifically without clearly knowing who owns the KD and how they operate it) but it sounds like we need to at least: A) Mandate that MDDs watch out for that sort of thing (for at least the good-natured MDDs) and B) Explicitly mentioning the possibility for this in Security Considerations. Emil > > -Ekr > > > > On Tue, 14 Feb 2017 at 21:37, Bernard Aboba > wrote: > > Presumably the MDD would check the SSRC against the endpoint > address so as to avoid forgery. > > On Feb 14, 2017, at 6:14 PM, Emil Ivov > wrote: > >> While looking at the specs it wasn't immediately obvious to me >> exactly what would prevent participant A in a PERC call to >> impersonate participant B by simply sending with their SSRC. >> Everyone's e2e key is known to everyone else and all the keys >> are symmetric. >> >> Have I missed something or is this a known limitation that we >> have stated in the docs? If so could someone please point me >> to the relevant place? >> >> Thanks, >> Emil >> >> -- >> https://jitsi.org >> -- >> sent from my mobile >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >> > > -- > sent from my mobile > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > > > -- Emil Ivov, Ph.D. 303 Colorado Street, #1600 Chief Video Architect Austin, TX, USA Atlassian MOBILE:+1.512.420.6968 https://atlassian.com eivov@atlassian.com From nobody Wed Feb 15 10:09:50 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3228412966C for ; Wed, 15 Feb 2017 10:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 n43uJFnjwivB for ; Wed, 15 Feb 2017 10:09:46 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 8FF851295D1 for ; Wed, 15 Feb 2017 10:09:46 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id v200so85885697ywc.3 for ; Wed, 15 Feb 2017 10:09:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aNkLLEEOluaimZiNBAkIjb8D4G2D7lVK334H+FhUFvU=; b=iTs5CuIwu2KzfTHjhK+knqHbW1bxWFZY38Dxso4jv3GypZF58UkCEb/zsx3nSvrTmq ChpluQFEYNrF76kfq6sguchKGkTd4WqgECk6LlGNWKGVJxX2G8/ST/6TCIPqEHb+vn0F ENWfyO6oerUlbci1JSPVIB2M7E5XrVmkT0KvDuEneZxTARp1RwfNeycB1di8Nv+TLrZT aiVOeTMUWUff3xvUGhX1YYy3sg3L+uAkkR5pRJDwV6o0KOBCL++p/U+1JJW7cGrgdCRo QZTa3rnvb5YAqsgnO4mA0u8FngjuYskEPSGzUSvRhjUzQ0ubHxI9lSjq1szos7ztIU5j rg/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aNkLLEEOluaimZiNBAkIjb8D4G2D7lVK334H+FhUFvU=; b=ILBx7vIoUn4EX8n8lLPkt0tZQ44r6NdeJh7B1cPTNwyHgcRqb8F1rPlatPiEOwJwOL rlLm1mMCWWotBhvVPY8Q9JOX0eC+kCzGQn2Q/T+CGiuyjrlHG7bmuKoh4HZvHtpT7kZR YDZ8/yDYQrp8YftdkbOhBYXs/VZy5YFqK8zwFo+PXFmpgjT+MX2UjRyjbTcVNsR8l+t0 eegJOM1voMFCvvwaPpIgOx35TcLgj/f+NQDRPd7cGd2of9RE+K3W1DhD0lnrullueywf PjJMyp/QBJtMOeO8J2fQF1thuyQTeYCAYurmTpxAweYrZL0JNajLh7NvDuEXwLIG7Orz 62Lw== X-Gm-Message-State: AMke39nWGYzX/71+zNJreWZBfCwozrdkgD5DAavmZwOrx0WL+zfwu88buDgRa0CV8xOcYgpwCxcf49ayx4+Uzg== X-Received: by 10.129.162.151 with SMTP id z145mr26958964ywg.337.1487182185750; Wed, 15 Feb 2017 10:09:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Wed, 15 Feb 2017 10:09:05 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 15 Feb 2017 10:09:05 -0800 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=94eb2c11555ee652120548959526 Archived-At: Cc: "perc@ietf.org" , Bernard Aboba Subject: Re: [Perc] Impersonation X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 18:09:49 -0000 --94eb2c11555ee652120548959526 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 15, 2017 at 9:56 AM, Emil Ivov wrote: > > > On 2/15/17 12:00 AM, Eric Rescorla wrote: > >> >> >> On Tue, Feb 14, 2017 at 8:11 PM, Emil Ivov > > wrote: >> >> That would be one way, yeah, but then isn't the whole idea of PERC >> to not trust the mdd? >> >> >> No. It's to have confidentiality against the MDD. >> >> >> If thats all we have then we are basicaly saying: we don't trust the >> mdd to not attack us, but we surely trust it to prevent others from >> attacking us ... >> >> >> No, because the limit of the attack is allowing one member of the >> conference (which the MDD cannot control) to impersonate another. >> > > You lost me. How do you know what the relationship is between the MDD and > that participant and that they are not actually controlled by the same > party? That's largely outside the threat model here. Anyways, it is hard to argue how big of a deal this is without having a > full implementation in mind (specifically without clearly knowing who owns > the KD and how they operate it) but it sounds like we need to at least: > > A) Mandate that MDDs watch out for that sort of thing (for at least the > good-natured MDDs) and > B) Explicitly mentioning the possibility for this in Security > Considerations. > Sure. -Ekr > > Emil > > >> -Ekr >> >> >> >> On Tue, 14 Feb 2017 at 21:37, Bernard Aboba > > wrote: >> >> Presumably the MDD would check the SSRC against the endpoint >> address so as to avoid forgery. >> >> On Feb 14, 2017, at 6:14 PM, Emil Ivov > > wrote: >> >> While looking at the specs it wasn't immediately obvious to me >>> exactly what would prevent participant A in a PERC call to >>> impersonate participant B by simply sending with their SSRC. >>> Everyone's e2e key is known to everyone else and all the keys >>> are symmetric. >>> >>> Have I missed something or is this a known limitation that we >>> have stated in the docs? If so could someone please point me >>> to the relevant place? >>> >>> Thanks, >>> Emil >>> >>> -- >>> https://jitsi.org >>> -- >>> sent from my mobile >>> _______________________________________________ >>> Perc mailing list >>> Perc@ietf.org >>> https://www.ietf.org/mailman/listinfo/perc >>> >>> >> >> -- >> sent from my mobile >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >> >> >> >> > -- > Emil Ivov, Ph.D. 303 Colorado Street, #1600 > Chief Video Architect Austin, TX, USA > Atlassian MOBILE:+1.512.420.6968 > https://atlassian.com eivov@atlassian.com > --94eb2c11555ee652120548959526 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Feb 15, 2017 at 9:56 AM, Emil Ivov <eivov@atlassian.com&= gt; wrote:


On 2/15/17 12:00 AM, Eric Rescorla wrote:


On Tue, Feb 14, 2017 at 8:11 PM, Emil Ivov <eivov@atlassian.com
 <mailto:eivov@a= tlassian.com>> wrote:

=C2=A0 =C2=A0 That would be one way, yeah, but then isn't the whole ide= a of PERC
=C2=A0 =C2=A0 to not trust the mdd?


No. It's to have confidentiality against the MDD.


=C2=A0 =C2=A0 If thats all we have then we are basicaly saying: we don'= t trust the
=C2=A0 =C2=A0 mdd to not attack us, but we surely trust it to prevent other= s from
=C2=A0 =C2=A0 attacking us ...


No, because the limit of the attack is allowing one member of the
conference (which the MDD cannot control) to impersonate another.

You lost me. How do you know what the relationship is between the MDD and t= hat participant and that they are not actually controlled by the same party= ?

That's largely outside the threat mod= el here.


Anyways, it is hard to argue how big of a deal this is without having a ful= l implementation in mind (specifically without clearly knowing who owns the= KD and how they operate it) but it sounds like we need to at least:

A) Mandate that MDDs watch out for that sort of thing (for at least the goo= d-natured MDDs) and
B) Explicitly mentioning the possibility for this in Security Consideration= s.

Sure.

-Ekr<= /div>
=C2=A0

Emil


-Ekr



=C2=A0 =C2=A0 On Tue, 14 Feb 2017 at 21:37, Bernard Aboba <bernard.aboba@gmail.com=
=C2=A0 =C2=A0 <mailto:bernard.aboba@gmail.com>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Presumably the MDD would check the SSRC against= the endpoint
=C2=A0 =C2=A0 =C2=A0 =C2=A0 address so as to avoid forgery.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Feb 14, 2017, at 6:14 PM, Emil Ivov <eivov@atlassian.com
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:eivov@atlassian.com>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 While looking at the specs it wasn't immedi= ately obvious to me
=C2=A0 =C2=A0 =C2=A0 =C2=A0 exactly what would prevent participant A in a P= ERC call to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 impersonate participant B by simply sending wit= h their SSRC.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Everyone's e2e key is known to everyone els= e and all the keys
=C2=A0 =C2=A0 =C2=A0 =C2=A0 are symmetric.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Have I missed something or is this a known limi= tation that we
=C2=A0 =C2=A0 =C2=A0 =C2=A0 have stated in the docs? If so could someone pl= ease point me
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to the relevant place?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Emil

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://jitsi.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sent from my mobile
=C2=A0 =C2=A0 =C2=A0 =C2=A0 __________________________________________= _____
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Perc mailing list
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Perc@ietf.org <mailto:Perc@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/l= istinfo/perc
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailm= an/listinfo/perc>

=C2=A0 =C2=A0 --
=C2=A0 =C2=A0 sent from my mobile

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Perc mailing list
 =C2=A0 =C2=A0 Perc@ietf.= org <mailto:Perc@= ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/p= erc
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listin= fo/perc>



--
Emil Ivov, Ph.D.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0303 Colorado Street, #1600
Chief Video Architect=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Austin, TX, USA
Atlassian=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MOBILE:+1.512.420.6968
http= s://atlassian.com=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 eivov@atlassia= n.com

--94eb2c11555ee652120548959526-- From nobody Wed Feb 15 22:23:13 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F641295C6 for ; Wed, 15 Feb 2017 22:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 fDgnG_I_jBrF for ; Wed, 15 Feb 2017 22:23:09 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 092331295C5 for ; Wed, 15 Feb 2017 22:23:08 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAS12518; Thu, 16 Feb 2017 06:23:06 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 16 Feb 2017 06:23:05 +0000 Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by NKGEML413-HUB.china.huawei.com (10.98.56.74) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 16 Feb 2017 14:22:56 +0800 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0301.000; Thu, 16 Feb 2017 14:22:51 +0800 From: Roni Even To: Emil Ivov , Eric Rescorla Thread-Topic: [Perc] Impersonation Thread-Index: AQHSh7YPwyRxbk7DqEODJwxSIoaLAqFrIBFA Date: Thu, 16 Feb 2017 06:22:50 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD774722@DGGEMM506-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.58A5454A.0100, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8d0f895a053f2097c11a7d4c3c191ed1 Archived-At: Cc: "perc@ietf.org" , Bernard Aboba Subject: Re: [Perc] Impersonation X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 06:23:12 -0000 Emil, When I look at the MDD I see a decomposed entity. A application server and = a media server (RFC5567). PERC MDD is only about the second entity (media s= erver). The KDF will connect to the application server via signaling (can b= e part of the application server) and with the MDD on the media path (e.g. = tunneling DTLS SRTP) with no actual knowledge about the conference roster. The MDD as a media server does not know about the participants, it only kno= ws about which stream to receive and how to switch them. =20 I think that the issue you raise about a participant using another user's S= SRC can be identified by the MDD or probably by the participants through th= e RTCP receiver reports if they notices that wrong SSRC was used, I assume = that also the attacking party will send the RTCP sender reports with the im= personating SSRC. BTW: wouldn't this cause an SSRC collision? Roni > -----Original Message----- > From: Perc [mailto:perc-bounces@ietf.org] On Behalf Of Emil Ivov > Sent: =E9=E5=ED=A0=E3 15 =F4=E1=F8=E5=E0=F8 2017 19:56 > To: Eric Rescorla > Cc: perc@ietf.org; Bernard Aboba > Subject: Re: [Perc] Impersonation >=20 >=20 >=20 > On 2/15/17 12:00 AM, Eric Rescorla wrote: > > > > > > On Tue, Feb 14, 2017 at 8:11 PM, Emil Ivov > > wrote: > > > > That would be one way, yeah, but then isn't the whole idea of PERC > > to not trust the mdd? > > > > > > No. It's to have confidentiality against the MDD. > > > > > > If thats all we have then we are basicaly saying: we don't trust th= e > > mdd to not attack us, but we surely trust it to prevent others from > > attacking us ... > > > > > > No, because the limit of the attack is allowing one member of the > > conference (which the MDD cannot control) to impersonate another. >=20 > You lost me. How do you know what the relationship is between the MDD > and that participant and that they are not actually controlled by the sam= e > party? >=20 > Anyways, it is hard to argue how big of a deal this is without having a f= ull > implementation in mind (specifically without clearly knowing who owns the > KD and how they operate it) but it sounds like we need to at > least: >=20 > A) Mandate that MDDs watch out for that sort of thing (for at least the g= ood- > natured MDDs) and > B) Explicitly mentioning the possibility for this in Security Considerati= ons. >=20 > Emil >=20 > > > > -Ekr > > > > > > > > On Tue, 14 Feb 2017 at 21:37, Bernard Aboba > > > wrote: > > > > Presumably the MDD would check the SSRC against the endpoint > > address so as to avoid forgery. > > > > On Feb 14, 2017, at 6:14 PM, Emil Ivov > > wrote: > > > >> While looking at the specs it wasn't immediately obvious to me > >> exactly what would prevent participant A in a PERC call to > >> impersonate participant B by simply sending with their SSRC. > >> Everyone's e2e key is known to everyone else and all the keys > >> are symmetric. > >> > >> Have I missed something or is this a known limitation that we > >> have stated in the docs? If so could someone please point me > >> to the relevant place? > >> > >> Thanks, > >> Emil > >> > >> -- > >> https://jitsi.org > >> -- > >> sent from my mobile > >> _______________________________________________ > >> Perc mailing list > >> Perc@ietf.org > >> https://www.ietf.org/mailman/listinfo/perc > >> > > > > -- > > sent from my mobile > > > > _______________________________________________ > > Perc mailing list > > Perc@ietf.org > > https://www.ietf.org/mailman/listinfo/perc > > > > > > >=20 > -- > Emil Ivov, Ph.D. 303 Colorado Street, #1600 > Chief Video Architect Austin, TX, USA > Atlassian MOBILE:+1.512.420.6968 > https://atlassian.com eivov@atlassian.com >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc From nobody Thu Feb 16 07:49:22 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467DA129D55 for ; Thu, 16 Feb 2017 07:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=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 xdMEq5Q0TB9n for ; Thu, 16 Feb 2017 07:49:18 -0800 (PST) Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) (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 4EE3B129D53 for ; Thu, 16 Feb 2017 07:49:18 -0800 (PST) Received: by mail-oi0-f51.google.com with SMTP id u143so10346935oif.3 for ; Thu, 16 Feb 2017 07:49:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=mANHAzu3FV8LUJPeKBrK75ndsnf9mH/I/EoxPAA+7zc=; b=AfDYBU3wI4U5aJL0v+2Yt66O/qVyu5yyFdjg/ESvrSZIR0p3Yn+2/Kvn7m3xndf83M Fg5NmkDrE/urjJHhzds4DA0G1wNfW7bW6Q88dxnztM4mIryq5Mu4BpL/SF5OJcitKBpt otbksodCuggERu4PlsJ0STJgdNohmpmy2UoCd2dUzXA5EzUDQy8EUG43LP/TIXMBCLDq iS2khgq0h/06ublzUnoDdUJ4G+jEFLIGIEqFW5R4rGak0sj55iJq2QEBXxSKPlfNRy79 lR+N6ByIEhNC7bsvyWHk5KjTosTP617RWuIE5AjS1FlOq2mu+TwViaOl1F6509vCRC+o CxPA== X-Gm-Message-State: AMke39nUKmTYoEwEWNzleOY4buH9x08NpPJbyyx94r7BUl6U0HQGy1TSY2KHI//dt5g8FA== X-Received: by 10.202.60.86 with SMTP id j83mr1348011oia.27.1487260157458; Thu, 16 Feb 2017 07:49:17 -0800 (PST) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id w84sm3119332oiw.21.2017.02.16.07.49.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 07:49:15 -0800 (PST) To: Roni Even , Eric Rescorla References: <6E58094ECC8D8344914996DAD28F1CCD774722@DGGEMM506-MBX.china.huawei.com> From: Emil Ivov Organization: Atlassian Message-ID: Date: Thu, 16 Feb 2017 09:49:14 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD774722@DGGEMM506-MBX.china.huawei.com> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "perc@ietf.org" , Bernard Aboba Subject: Re: [Perc] Impersonation X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:49:20 -0000 Hey Roni, On 2/16/17 12:22 AM, Roni Even wrote: > Emil, When I look at the MDD I see a decomposed entity. A application > server and a media server (RFC5567). PERC MDD is only about the > second entity (media server). The KDF will connect to the application > server via signaling (can be part of the application server) and with > the MDD on the media path (e.g. tunneling DTLS SRTP) with no actual > knowledge about the conference roster. The MDD as a media server does > not know about the participants, it only knows about which stream to > receive and how to switch them. I think that the issue you raise > about a participant using another user's SSRC can be identified by > the MDD Yes, I agree, but then that weakens the promise of PERC as it makes it rely on servers to do the right thing. The reason why this bothers me (and I know this is vague ... but then again so is PERC in many respects) is that, in an ideal world, PERC would provide generic clients, such as browsers, to tell their users: "you are safe!" The same way browsers do with https. The same way some rich clients do with ZRTP. A client/browser doesn't get to do a lot of explaining here. Basically any nuances beyond "you are" or "you aren't" are likely lost on users. Relying on servers to do something, anything, in order for the conference to be safe, basically removes the option for a generic client (such as a browser) to certify a conference as safe. That might still be just fine for a bunch of other use cases, like for example corporate deployments or people who just want to be able to not answer certain subpoenas. I am just pointing out that in this case we don't get to have the case that is most relevant to generic users. > or probably by the participants through the RTCP receiver > reports if they notices that wrong SSRC was used, I assume that also > the attacking party will send the RTCP sender reports with the > impersonating SSRC. BTW: wouldn't this cause an SSRC collision? Well ... potentially, and that's a good thought, but that still depends on what the MDD/SFU does. So same points apply. First we need to mandate what the servers have to do and second clients are now dependent on servers to do the right thing. Emil > Roni > > >> -----Original Message----- From: Perc >> [mailto:perc-bounces@ietf.org] On Behalf Of Emil Ivov Sent: >> 15 2017 19:56 To: Eric Rescorla Cc: perc@ietf.org; Bernard >> Aboba Subject: Re: [Perc] Impersonation >> >> >> >> On 2/15/17 12:00 AM, Eric Rescorla wrote: >>> >>> >>> On Tue, Feb 14, 2017 at 8:11 PM, Emil Ivov >> > wrote: >>> >>> That would be one way, yeah, but then isn't the whole idea of >>> PERC to not trust the mdd? >>> >>> >>> No. It's to have confidentiality against the MDD. >>> >>> >>> If thats all we have then we are basicaly saying: we don't trust >>> the mdd to not attack us, but we surely trust it to prevent >>> others from attacking us ... >>> >>> >>> No, because the limit of the attack is allowing one member of >>> the conference (which the MDD cannot control) to impersonate >>> another. >> >> You lost me. How do you know what the relationship is between the >> MDD and that participant and that they are not actually controlled >> by the same party? >> >> Anyways, it is hard to argue how big of a deal this is without >> having a full implementation in mind (specifically without clearly >> knowing who owns the KD and how they operate it) but it sounds like >> we need to at least: >> >> A) Mandate that MDDs watch out for that sort of thing (for at least >> the good- natured MDDs) and B) Explicitly mentioning the >> possibility for this in Security Considerations. >> >> Emil >> >>> >>> -Ekr >>> >>> >>> >>> On Tue, 14 Feb 2017 at 21:37, Bernard Aboba >> >> > wrote: >>> >>> Presumably the MDD would check the SSRC against the endpoint >>> address so as to avoid forgery. >>> >>> On Feb 14, 2017, at 6:14 PM, Emil Ivov >> > wrote: >>> >>>> While looking at the specs it wasn't immediately obvious to me >>>> exactly what would prevent participant A in a PERC call to >>>> impersonate participant B by simply sending with their SSRC. >>>> Everyone's e2e key is known to everyone else and all the keys >>>> are symmetric. >>>> >>>> Have I missed something or is this a known limitation that we >>>> have stated in the docs? If so could someone please point me to >>>> the relevant place? >>>> >>>> Thanks, Emil >>>> >>>> -- https://jitsi.org -- sent from my mobile >>>> _______________________________________________ Perc mailing >>>> list Perc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/perc >>>> >>> >>> -- sent from my mobile >>> >>> _______________________________________________ Perc mailing >>> list Perc@ietf.org >>> https://www.ietf.org/mailman/listinfo/perc >>> >>> >>> >> >> -- Emil Ivov, Ph.D. 303 Colorado Street, #1600 >> Chief Video Architect Austin, TX, USA Atlassian >> MOBILE:+1.512.420.6968 https://atlassian.com >> eivov@atlassian.com >> >> _______________________________________________ Perc mailing list >> Perc@ietf.org https://www.ietf.org/mailman/listinfo/perc > -- Emil Ivov, Ph.D. 303 Colorado Street, #1600 Chief Video Architect Austin, TX, USA Atlassian MOBILE:+1.512.420.6968 https://atlassian.com eivov@atlassian.com From nobody Thu Feb 16 07:55:22 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4325A129639 for ; Thu, 16 Feb 2017 07:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 PGNt9gD7MKZA for ; Thu, 16 Feb 2017 07:55:19 -0800 (PST) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (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 DB42D1295A6 for ; Thu, 16 Feb 2017 07:55:13 -0800 (PST) Received: by mail-yb0-x231.google.com with SMTP id 123so5359179ybe.3 for ; Thu, 16 Feb 2017 07:55:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kTJsVNmGHEuLnLF157RyZVYcBryG9xlD9HzEXo4c1xU=; b=sRngXSU5Fv7OsDT2d0obcxKKoz9cN01LLsxpHr2A7yuv0WZXupEU2Q0MPoSrLR8YLF FtI/u5bT348xBXJ2Q7MIm/OJzR0aSOvAjY0+epE1vj4ecbCSFtZIPcWgKbN5V6MjV7kh FDmqgrYtXD9dlFzXcNO31O/KQqYV28s3z4OAgKNA+nUYmgC2y7+pQfRHGDTHoONsA5mN 7hXK9ugkKjicJYk3zJCyqB2AdpGWCtZ9UHl83XOXRP7bfPdeDuGq1oZQ9NAjQ2UKAKCS zklC9ZzLhkMJjr+B8Jy5r7cve3NinYg44DP7qOpJ6RrTrx4Kwp0FNxQcQwkrvmUi0QHT 5pKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kTJsVNmGHEuLnLF157RyZVYcBryG9xlD9HzEXo4c1xU=; b=V6JNxmJyf0p6UoTIfLjRrEd8YcHJfOZri223wXHoW0QrYuyc+01hoKMfaWWGfvsvWy kATceIb5ZlTPqJJHY4KhvNVEBQjhaefNTBxrNaqR9ySK1xz0j/pjV0H4fKtoe8bx9ZDD 3E+/GjJV897Zx0OgoKFcsh6Q0EgnI2wI1t7iUopOnACQv/78Ls46/pi7xfPx3QbdHYSQ KVcK+meUAG15tblYbJdvSHe3sG7RKnpCopfBBX08RhdDykW9jSBi7cB16H+9eALjK4xH MhMERQIdH4v++Q6cBEjit2FBt7v31eLYK6L8SBDXmAYkapcxEzYSgZ+jqxb6068dyVO7 nzEQ== X-Gm-Message-State: AMke39nh6a4XIhjohMFtY8boR3S+Nl+pWRj6tNIa7pb/OULvcHqxZd4jUXe21CV74ZvicTed0xIe4TLls4ED2Q== X-Received: by 10.37.14.69 with SMTP id 66mr2108858ybo.64.1487260513045; Thu, 16 Feb 2017 07:55:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Thu, 16 Feb 2017 07:54:32 -0800 (PST) In-Reply-To: References: <6E58094ECC8D8344914996DAD28F1CCD774722@DGGEMM506-MBX.china.huawei.com> From: Eric Rescorla Date: Thu, 16 Feb 2017 07:54:32 -0800 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=001a113e930c9229700548a7d201 Archived-At: Cc: Roni Even , "perc@ietf.org" , Bernard Aboba Subject: Re: [Perc] Impersonation X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:55:21 -0000 --001a113e930c9229700548a7d201 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This property has been known about from the very beginning of PERC. The only way to deal with this AFAICT, is to digitally sign the packets (or use TESLA). I'm pretty sure I made this point in some early meeting. "Safe" isn't a meaningful security property. Think of PERC as rather trying to approximate the security properties you would have if you had a giant shared conference in which the MDD were replaced with broadcast transport. -Ekr On Thu, Feb 16, 2017 at 7:49 AM, Emil Ivov wrote: > Hey Roni, > > On 2/16/17 12:22 AM, Roni Even wrote: > >> Emil, When I look at the MDD I see a decomposed entity. A application >> server and a media server (RFC5567). PERC MDD is only about the >> second entity (media server). The KDF will connect to the application >> server via signaling (can be part of the application server) and with >> the MDD on the media path (e.g. tunneling DTLS SRTP) with no actual >> knowledge about the conference roster. The MDD as a media server does >> not know about the participants, it only knows about which stream to >> receive and how to switch them. I think that the issue you raise >> about a participant using another user's SSRC can be identified by >> the MDD >> > > Yes, I agree, but then that weakens the promise of PERC as it makes it > rely on servers to do the right thing. > > The reason why this bothers me (and I know this is vague ... but then > again so is PERC in many respects) is that, in an ideal world, PERC would > provide generic clients, such as browsers, to tell their users: "you are > safe!" > > The same way browsers do with https. The same way some rich clients do > with ZRTP. > > A client/browser doesn't get to do a lot of explaining here. Basically an= y > nuances beyond "you are" or "you aren't" are likely lost on users. > > Relying on servers to do something, anything, in order for the conference > to be safe, basically removes the option for a generic client (such as a > browser) to certify a conference as safe. > > That might still be just fine for a bunch of other use cases, like for > example corporate deployments or people who just want to be able to not > answer certain subpoenas. > > I am just pointing out that in this case we don't get to have the case > that is most relevant to generic users. > > or probably by the participants through the RTCP receiver >> reports if they notices that wrong SSRC was used, I assume that also >> the attacking party will send the RTCP sender reports with the >> impersonating SSRC. BTW: wouldn't this cause an SSRC collision? >> > > Well ... potentially, and that's a good thought, but that still depends o= n > what the MDD/SFU does. So same points apply. First we need to mandate wha= t > the servers have to do and second clients are now dependent on servers to > do the right thing. > > Emil > > > Roni >> >> >> -----Original Message----- From: Perc >>> [mailto:perc-bounces@ietf.org] On Behalf Of Emil Ivov Sent: =D7=99=D7= =95=D7=9D =D7=93 >>> 15 =D7=A4=D7=91=D7=A8=D7=95=D7=90=D7=A8 2017 19:56 To: Eric Rescorla Cc= : perc@ietf.org; Bernard >>> Aboba Subject: Re: [Perc] Impersonation >>> >>> >>> >>> On 2/15/17 12:00 AM, Eric Rescorla wrote: >>> >>>> >>>> >>>> On Tue, Feb 14, 2017 at 8:11 PM, Emil Ivov >>> > wrote: >>>> >>>> That would be one way, yeah, but then isn't the whole idea of >>>> PERC to not trust the mdd? >>>> >>>> >>>> No. It's to have confidentiality against the MDD. >>>> >>>> >>>> If thats all we have then we are basicaly saying: we don't trust >>>> the mdd to not attack us, but we surely trust it to prevent >>>> others from attacking us ... >>>> >>>> >>>> No, because the limit of the attack is allowing one member of >>>> the conference (which the MDD cannot control) to impersonate >>>> another. >>>> >>> >>> You lost me. How do you know what the relationship is between the >>> MDD and that participant and that they are not actually controlled >>> by the same party? >>> >>> Anyways, it is hard to argue how big of a deal this is without >>> having a full implementation in mind (specifically without clearly >>> knowing who owns the KD and how they operate it) but it sounds like >>> we need to at least: >>> >>> A) Mandate that MDDs watch out for that sort of thing (for at least >>> the good- natured MDDs) and B) Explicitly mentioning the >>> possibility for this in Security Considerations. >>> >>> Emil >>> >>> >>>> -Ekr >>>> >>>> >>>> >>>> On Tue, 14 Feb 2017 at 21:37, Bernard Aboba >>>> >>> >> >>>> > wrote: >>>> >>>> Presumably the MDD would check the SSRC against the endpoint >>>> address so as to avoid forgery. >>>> >>>> On Feb 14, 2017, at 6:14 PM, Emil Ivov >>> > wrote: >>>> >>>> While looking at the specs it wasn't immediately obvious to me >>>>> exactly what would prevent participant A in a PERC call to >>>>> impersonate participant B by simply sending with their SSRC. >>>>> Everyone's e2e key is known to everyone else and all the keys >>>>> are symmetric. >>>>> >>>>> Have I missed something or is this a known limitation that we >>>>> have stated in the docs? If so could someone please point me to >>>>> the relevant place? >>>>> >>>>> Thanks, Emil >>>>> >>>>> -- https://jitsi.org -- sent from my mobile >>>>> _______________________________________________ Perc mailing >>>>> list Perc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/perc >>>>> >>>>> >>>> >>>> -- sent from my mobile >>>> >>>> _______________________________________________ Perc mailing >>>> list Perc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/perc >>>> >>>> >>>> >>>> >>> -- Emil Ivov, Ph.D. 303 Colorado Street, #1600 >>> Chief Video Architect Austin, TX, USA Atlassian >>> MOBILE:+1.512.420.6968 https://atlassian.com >>> eivov@atlassian.com >>> >>> _______________________________________________ Perc mailing list >>> Perc@ietf.org https://www.ietf.org/mailman/listinfo/perc >>> >> >> > -- > Emil Ivov, Ph.D. 303 Colorado Street, #1600 > Chief Video Architect Austin, TX, USA > Atlassian MOBILE:+1.512.420.6968 > https://atlassian.com eivov@atlassian.com > --001a113e930c9229700548a7d201 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This property has been known about from the very beginning= of PERC. The
only way to deal with this AFAICT, is to digitally sign t= he packets (or use
TESLA). I'm pretty sure I made this point = in some early meeting.

"Safe" isn't = a meaningful security property. Think of PERC as rather trying
to= approximate the security properties you would have if you had a giant
shared conference in which the MDD were replaced with broadcast trans= port.

-Ekr


On Thu, Feb 16, 2017 at 7:49 AM, Emil Ivov= <eivov@atlassian.com> wrote:
Hey Roni,

On 2/16/17 12:22 AM, Roni Even wrote:
Emil, When I look at the MDD I see a decomposed entity. A application
server and a media server (RFC5567). PERC MDD is only about the
second entity (media server). The KDF will connect to the application
server via signaling (can be part of the application server) and with
the MDD on the media path (e.g. tunneling DTLS SRTP) with no actual
knowledge about the conference roster. The MDD as a media server does
not know about the participants, it only knows about which stream to
receive and how to switch them. I think that the issue you raise
about a participant using another user's SSRC can be identified by
the MDD

 Yes, I agree, but then that weakens the promise of PERC as it makes it rely= on servers to do the right thing.

The reason why this bothers me (and I know this is vague ... but then again= so is PERC in many respects) is that, in an ideal world, PERC would provid= e generic clients, such as browsers, to tell their users: "you are saf= e!"

The same way browsers do with https. The same way some rich clients do with= ZRTP.

A client/browser doesn't get to do a lot of explaining here. Basically = any nuances beyond "you are" or "you aren't" are li= kely lost on users.

Relying on servers to do something, anything, in order for the conference t= o be safe, basically removes the option for a generic client (such as a bro= wser) to certify a conference as safe.

That might still be just fine for a bunch of other use cases, like for exam= ple corporate deployments or people who just want to be able to not answer = certain subpoenas.

I am just pointing out that in this case we don't get to have the case = that is most relevant to generic users.

or probably by the participants through the RTCP receiver
reports if they notices that wrong SSRC was used, I assume that also
the attacking party will send the RTCP sender reports with the
impersonating SSRC. BTW: wouldn't this cause an SSRC collision?

 Well ... potentially, and that's a good thought, but that still depends= on what the MDD/SFU does. So same points apply. First we need to mandate w= hat the servers have to do and second clients are now dependent on servers = to do the right thing.

Emil


Roni


-----Original Message----- From: Perc
[mailto:perc-bou= nces@ietf.org] On Behalf Of Emil Ivov Sent: =D7=99=D7=95=D7=9D =D7=93 15 =D7=A4=D7=91=D7=A8=D7=95=D7=90=D7=A8 2017 19:56 To: Eric Rescorla Cc: perc@ietf.org; Bernard=
Aboba Subject: Re: [Perc] Impersonation



On 2/15/17 12:00 AM, Eric Rescorla wrote:


On Tue, Feb 14, 2017 at 8:11 PM, Emil Ivov <eivov@atlassian.com
<mailto:eivov@a= tlassian.com>> wrote:

That would be one way, yeah, but then isn't the whole idea of
PERC to not trust the mdd?


No. It's to have confidentiality against the MDD.


If thats all we have then we are basicaly saying: we don't trust
the mdd to not attack us, but we surely trust it to prevent
others from attacking us ...


No, because the limit of the attack is allowing one member of
the conference (which the MDD cannot control) to impersonate
another.

You lost me. How do you know what the relationship is between the
MDD and that participant and that they are not actually controlled
by the same party?

Anyways, it is hard to argue how big of a deal this is without
having a full implementation in mind (specifically without clearly
knowing who owns the KD and how they operate it) but it sounds like
we need to at least:

A) Mandate that MDDs watch out for that sort of thing (for at least
the good- natured MDDs) and B) Explicitly mentioning the
possibility for this in Security Considerations.

Emil


-Ekr



On Tue, 14 Feb 2017 at 21:37, Bernard Aboba
<bernard.ab= oba@gmail.com
<mailto:ber= nard.aboba@gmail.com>> wrote:

Presumably the MDD would check the SSRC against the endpoint
address so as to avoid forgery.

On Feb 14, 2017, at 6:14 PM, Emil Ivov <eivov@atlassian.com
<mailto:eivov@a= tlassian.com>> wrote:

While looking at the specs it wasn't immediately obvious to me
exactly what would prevent participant A in a PERC call to
impersonate participant B by simply sending with their SSRC.
Everyone's e2e key is known to everyone else and all the keys
are symmetric.

Have I missed something or is this a known limitation that we
have stated in the docs? If so could someone please point me to
the relevant place?

Thanks, Emil

-- https= ://jitsi.org -- sent from my mobile
_______________________________________________ Perc mailing
list Perc@ietf.org &= lt;mailto:Perc@ietf.org<= /a>>
https://www.ietf.org/mailman/listinfo/perc
<https://www.ietf.org/mailman/listinfo/perc>= ;

-- sent from my mobile

_______________________________________________ Perc mailing
list Perc@ietf.org &= lt;mailto:Perc@ietf.org<= /a>>
https://www.ietf.org/mailman/listinfo/perc
<https://www.ietf.org/mailman/listinfo/perc>= ;



-- Emil Ivov, Ph.D.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0303 Colorado Street, #1600
Chief Video Architect=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Austin, TX, USA Atlassian
MOBILE:+1.512.420.6968 https://atlassian.com
eivov@atlassian.co= m

_______________________________________________ Perc mailing list
Perc@ietf.org https://www.ietf.org/mailman/listinfo/perc


--
Emil Ivov, Ph.D.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0303 Colorado Street, #1600
Chief Video Architect=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Austin, TX, USA
Atlassian=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MOBILE:+1.512.420.6968
http= s://atlassian.com=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 eivov@atlassia= n.com

--001a113e930c9229700548a7d201-- From nobody Thu Feb 16 08:24:27 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2401129DB3 for ; Thu, 16 Feb 2017 08:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=atlassian-com.20150623.gappssmtp.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 MtMM_qIqQdVE for ; Thu, 16 Feb 2017 08:24:22 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 0AFBA129DB6 for ; Thu, 16 Feb 2017 08:24:17 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id c85so70650318wmi.1 for ; Thu, 16 Feb 2017 08:24:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=atlassian-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=F44sG/QjHA1ZIVKfB3mWqYWlCC5fMZMWwAUkAtzNqwU=; b=A7HV7Q1OoEy2XXyPVlCp/6EeQ+FW+BNDUvN6+IdGVchSkcXhsxOpc9GEqV6A6CoisZ +MxGID+g8ALs59NK3OBxMiiKx6FCxY3iXYKePJDo2fVceOcmbHKe+Sg4IyPPxO805GQy NkWJNVfPaAuryYyA46DlX6vybso8wexbT3Rn7xj/N0dvmG33b2Cdk1bhOA2WPbrzLjRM DV/eMmjbG1V4Kye2niHabXpJEEDnCoht7DqoaYVcAIzZ2szDNedwOjWThQuz8p6Xv3a/ DjYBdt1dEZOY+c0gF69qy34P/l6QyJjlo1R2mucFmG5zENOfA89RhOHOxobJa3oluirH pzGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=F44sG/QjHA1ZIVKfB3mWqYWlCC5fMZMWwAUkAtzNqwU=; b=i7DboXB7XgvIO6wwbh3NegR9T5Y5rgzUo2T8AqGmzaHUt4gg6FKOM4/1HTPhvaoR8X 2HvVEbI12XwOwV/egsybI9maoWzgQ4ONqLu8POvEmHexyy+4gL3sbbgcN3LiDJ7lPVso gBX40mz4JWcQlJDx67GQ3lrI7lweQjR84FiJUGgs/we2FDs/WGWvokT2Ucg7QSqRjoVR Evs8Ljc1uXnxou4PTp/4lRZ9YfAjFpQB1Du8zLpuBIkpqi1cPOriHJNCw5DoqoBc7GJA rvyCfmY/m/Fk3T33oijG0lrb1Md+vRavWoI2Sz6xU3uBWcXajwteS5arNc/3paPNOfb+ YPUg== X-Gm-Message-State: AMke39ktbf1gwpAsXCLU6Tgj4pnMWPXIORKRKrp9QeVzkM/A4dW7yuamPk3xKHPVPe1in7eY X-Received: by 10.28.102.67 with SMTP id a64mr14035649wmc.140.1487262255214; Thu, 16 Feb 2017 08:24:15 -0800 (PST) Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com. [74.125.82.52]) by smtp.gmail.com with ESMTPSA id d1sm9543343wrb.62.2017.02.16.08.24.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 08:24:14 -0800 (PST) Received: by mail-wm0-f52.google.com with SMTP id v77so19275331wmv.0 for ; Thu, 16 Feb 2017 08:24:14 -0800 (PST) X-Received: by 10.28.136.13 with SMTP id k13mr3248989wmd.94.1487262253935; Thu, 16 Feb 2017 08:24:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.175.4 with HTTP; Thu, 16 Feb 2017 08:23:53 -0800 (PST) In-Reply-To: References: <6E58094ECC8D8344914996DAD28F1CCD774722@DGGEMM506-MBX.china.huawei.com> From: Emil Ivov Date: Thu, 16 Feb 2017 10:23:53 -0600 X-Gmail-Original-Message-ID: Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Roni Even , "perc@ietf.org" , Bernard Aboba Subject: Re: [Perc] Impersonation X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 16:24:25 -0000 On Thu, Feb 16, 2017 at 9:54 AM, Eric Rescorla wrote: > This property has been known about from the very beginning of PERC. The > only way to deal with this AFAICT, is to digitally sign the packets (or u= se > TESLA). I'm pretty sure I made this point in some early meeting. Could be, it wasn't crystal clear to me. That's fine. > "Safe" isn't a meaningful security property. No one is claiming that it is. (Not from a protocol design perspective). "Safe" however is an indication that users expect from RTC clients. > Think of PERC as rather trying > to approximate the security properties you would have if you had a giant > shared conference in which the MDD were replaced with broadcast transport= . Well, if I think of it that way, then the giant full mess call definitely seems prone to providing significantly better security properties than what PERC is describing. And to be clear, I don't mean to steer this thread in the direction of rethinking PERC. I am more interested in making sure that at least some parts of it (such as double) can be re-used for something more ambitious. Emil > -Ekr > > > On Thu, Feb 16, 2017 at 7:49 AM, Emil Ivov wrote: >> >> Hey Roni, >> >> On 2/16/17 12:22 AM, Roni Even wrote: >>> >>> Emil, When I look at the MDD I see a decomposed entity. A application >>> server and a media server (RFC5567). PERC MDD is only about the >>> second entity (media server). The KDF will connect to the application >>> server via signaling (can be part of the application server) and with >>> the MDD on the media path (e.g. tunneling DTLS SRTP) with no actual >>> knowledge about the conference roster. The MDD as a media server does >>> not know about the participants, it only knows about which stream to >>> receive and how to switch them. I think that the issue you raise >>> about a participant using another user's SSRC can be identified by >>> the MDD >> >> >> Yes, I agree, but then that weakens the promise of PERC as it makes it >> rely on servers to do the right thing. >> >> The reason why this bothers me (and I know this is vague ... but then >> again so is PERC in many respects) is that, in an ideal world, PERC woul= d >> provide generic clients, such as browsers, to tell their users: "you are >> safe!" >> >> The same way browsers do with https. The same way some rich clients do >> with ZRTP. >> >> A client/browser doesn't get to do a lot of explaining here. Basically a= ny >> nuances beyond "you are" or "you aren't" are likely lost on users. >> >> Relying on servers to do something, anything, in order for the conferenc= e >> to be safe, basically removes the option for a generic client (such as a >> browser) to certify a conference as safe. >> >> That might still be just fine for a bunch of other use cases, like for >> example corporate deployments or people who just want to be able to not >> answer certain subpoenas. >> >> I am just pointing out that in this case we don't get to have the case >> that is most relevant to generic users. >> >>> or probably by the participants through the RTCP receiver >>> reports if they notices that wrong SSRC was used, I assume that also >>> the attacking party will send the RTCP sender reports with the >>> impersonating SSRC. BTW: wouldn't this cause an SSRC collision? >> >> >> Well ... potentially, and that's a good thought, but that still depends = on >> what the MDD/SFU does. So same points apply. First we need to mandate wh= at >> the servers have to do and second clients are now dependent on servers t= o do >> the right thing. >> >> Emil >> >> >>> Roni >>> >>> >>>> -----Original Message----- From: Perc >>>> [mailto:perc-bounces@ietf.org] On Behalf Of Emil Ivov Sent: =D7=99=D7= =95=D7=9D =D7=93 >>>> 15 =D7=A4=D7=91=D7=A8=D7=95=D7=90=D7=A8 2017 19:56 To: Eric Rescorla C= c: perc@ietf.org; Bernard >>>> Aboba Subject: Re: [Perc] Impersonation >>>> >>>> >>>> >>>> On 2/15/17 12:00 AM, Eric Rescorla wrote: >>>>> >>>>> >>>>> >>>>> On Tue, Feb 14, 2017 at 8:11 PM, Emil Ivov >>>> > wrote: >>>>> >>>>> That would be one way, yeah, but then isn't the whole idea of >>>>> PERC to not trust the mdd? >>>>> >>>>> >>>>> No. It's to have confidentiality against the MDD. >>>>> >>>>> >>>>> If thats all we have then we are basicaly saying: we don't trust >>>>> the mdd to not attack us, but we surely trust it to prevent >>>>> others from attacking us ... >>>>> >>>>> >>>>> No, because the limit of the attack is allowing one member of >>>>> the conference (which the MDD cannot control) to impersonate >>>>> another. >>>> >>>> >>>> You lost me. How do you know what the relationship is between the >>>> MDD and that participant and that they are not actually controlled >>>> by the same party? >>>> >>>> Anyways, it is hard to argue how big of a deal this is without >>>> having a full implementation in mind (specifically without clearly >>>> knowing who owns the KD and how they operate it) but it sounds like >>>> we need to at least: >>>> >>>> A) Mandate that MDDs watch out for that sort of thing (for at least >>>> the good- natured MDDs) and B) Explicitly mentioning the >>>> possibility for this in Security Considerations. >>>> >>>> Emil >>>> >>>>> >>>>> -Ekr >>>>> >>>>> >>>>> >>>>> On Tue, 14 Feb 2017 at 21:37, Bernard Aboba >>>> >>>> >>>> >>>>> > wrote: >>>>> >>>>> Presumably the MDD would check the SSRC against the endpoint >>>>> address so as to avoid forgery. >>>>> >>>>> On Feb 14, 2017, at 6:14 PM, Emil Ivov >>>> > wrote: >>>>> >>>>>> While looking at the specs it wasn't immediately obvious to me >>>>>> exactly what would prevent participant A in a PERC call to >>>>>> impersonate participant B by simply sending with their SSRC. >>>>>> Everyone's e2e key is known to everyone else and all the keys >>>>>> are symmetric. >>>>>> >>>>>> Have I missed something or is this a known limitation that we >>>>>> have stated in the docs? If so could someone please point me to >>>>>> the relevant place? >>>>>> >>>>>> Thanks, Emil >>>>>> >>>>>> -- https://jitsi.org -- sent from my mobile >>>>>> _______________________________________________ Perc mailing >>>>>> list Perc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/perc >>>>>> >>>>> >>>>> >>>>> -- sent from my mobile >>>>> >>>>> _______________________________________________ Perc mailing >>>>> list Perc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/perc >>>>> >>>>> >>>>> >>>> >>>> -- Emil Ivov, Ph.D. 303 Colorado Street, #1600 >>>> Chief Video Architect Austin, TX, USA Atlassian >>>> MOBILE:+1.512.420.6968 https://atlassian.com >>>> eivov@atlassian.com >>>> >>>> _______________________________________________ Perc mailing list >>>> Perc@ietf.org https://www.ietf.org/mailman/listinfo/perc >>> >>> >> >> -- >> Emil Ivov, Ph.D. 303 Colorado Street, #1600 >> Chief Video Architect Austin, TX, USA >> Atlassian MOBILE:+1.512.420.6968 >> https://atlassian.com eivov@atlassian.com > > --=20 Emil Ivov, Ph.D. 303 Colorado Street, #1600 Chief Video Architect Austin, TX, USA Atlassian MOBILE:+1.512.420.6968 https://atlassian.com eivov@atlassian.com From nobody Thu Feb 16 08:30:25 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC81129503 for ; Thu, 16 Feb 2017 08:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 M6aqTdf_qJBi for ; Thu, 16 Feb 2017 08:30:22 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 0D5781270B4 for ; Thu, 16 Feb 2017 08:30:22 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id l19so10677993ywc.2 for ; Thu, 16 Feb 2017 08:30:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/io9WntT44cvZYNgLDguXox66LEbj2rl7hGbdpcAjoo=; b=pj36BWnBXNLAYP7GzMmY4SV5F07pG2s06gayhrtJ8/uQ7bZf1SOXqnvFdS5fXGekx5 iQNXvUfPdmP1Zx/nFeK9+6AOq4sWqFGDjfF6F8caDlYGh0IOIknnw+WLzyr4QtZn5c6C 6Y1rwngFTx4MN7HospEEwZtV3GxWv9jMyH0CP8G2bGKpP0zHMjIXh9xeq7/sPXqveeUr IBlnZP9w49LnpoMbPct1QWZfoseJtuc5hsiL2gqVTo2QVAEZyIs1Jy/s9+Y8EkCATsjf /ZD13TMI/BSR0RIBzORyqcAZTvip3VTc7CavLiEES3w9CHIofRc0YXc2Qy9CHKO0g6bG 6g8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/io9WntT44cvZYNgLDguXox66LEbj2rl7hGbdpcAjoo=; b=pgPDF6lPuX1rD6OTqjnUzCC5gJmLdzd7MmjtK1pK8iGprI3ENm+Mvkm7/Ji+BONNP9 xJYXmn7FKiYAy3KDjN2k443PyyY2vPBdow/ZO0QqVPqR60GVYfkrrpsoAQo8zDimzuns M9/lVv3DXeZryb8l1J8oEyTb09PWuo4gEYU2sp6NBooqwE0ITpDrvyhca6pbiVCG5pTv 6GYefPfzCfQ2+v8uuZOWwMu3GUmtNtJWwqiL3qHp6lqaorEpxovfyI9n6xvx/oXjYLhp xk9H0ZWknINaBMNLSQDvWm5oB+dPotDaJ+2ZipGajPrkdpdlT2z6y4qspJSg2Pst0SGT Ri+A== X-Gm-Message-State: AMke39n91r0pY38Zaq6tcaUGW30+CYbDj3LWncUXFz/8caLsaZKE+nrehHldTNgHaLYWOhMTTuE17qSZIn+Z2g== X-Received: by 10.129.162.151 with SMTP id z145mr2264943ywg.337.1487262621159; Thu, 16 Feb 2017 08:30:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.224.131 with HTTP; Thu, 16 Feb 2017 08:29:39 -0800 (PST) In-Reply-To: References: <6E58094ECC8D8344914996DAD28F1CCD774722@DGGEMM506-MBX.china.huawei.com> From: Eric Rescorla Date: Thu, 16 Feb 2017 08:29:39 -0800 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=94eb2c11555e3920f30548a8505a Archived-At: Cc: Roni Even , "perc@ietf.org" , Bernard Aboba Subject: Re: [Perc] Impersonation X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 16:30:24 -0000 --94eb2c11555e3920f30548a8505a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 16, 2017 at 8:23 AM, Emil Ivov wrote: > On Thu, Feb 16, 2017 at 9:54 AM, Eric Rescorla wrote: > > This property has been known about from the very beginning of PERC. The > > only way to deal with this AFAICT, is to digitally sign the packets (or > use > > TESLA). I'm pretty sure I made this point in some early meeting. > > Could be, it wasn't crystal clear to me. That's fine. > > > "Safe" isn't a meaningful security property. > > No one is claiming that it is. (Not from a protocol design perspective). > > "Safe" however is an indication that users expect from RTC clients. > > > Think of PERC as rather trying > > to approximate the security properties you would have if you had a gian= t > > shared conference in which the MDD were replaced with broadcast > transport. > > Well, if I think of it that way, then the giant full mess call > definitely seems prone to providing significantly better security > properties than what PERC is describing. > Yes, a full mesh call has better security properties. I thought that was clear. PERC is a compromise design that is intended to have the dataflow properties of an MCU/SFU with as good privacy properties as we can get. > I am more interested in making sure that at least some parts of it > (such as double) can be re-used for something more ambitious. > Well, the design in which double is embedded basically has this property. A= s noted above, you would need something other than double. -Ekr > > Emil > > > -Ekr > > > > > > On Thu, Feb 16, 2017 at 7:49 AM, Emil Ivov wrote: > >> > >> Hey Roni, > >> > >> On 2/16/17 12:22 AM, Roni Even wrote: > >>> > >>> Emil, When I look at the MDD I see a decomposed entity. A application > >>> server and a media server (RFC5567). PERC MDD is only about the > >>> second entity (media server). The KDF will connect to the application > >>> server via signaling (can be part of the application server) and with > >>> the MDD on the media path (e.g. tunneling DTLS SRTP) with no actual > >>> knowledge about the conference roster. The MDD as a media server does > >>> not know about the participants, it only knows about which stream to > >>> receive and how to switch them. I think that the issue you raise > >>> about a participant using another user's SSRC can be identified by > >>> the MDD > >> > >> > >> Yes, I agree, but then that weakens the promise of PERC as it makes it > >> rely on servers to do the right thing. > >> > >> The reason why this bothers me (and I know this is vague ... but then > >> again so is PERC in many respects) is that, in an ideal world, PERC > would > >> provide generic clients, such as browsers, to tell their users: "you a= re > >> safe!" > >> > >> The same way browsers do with https. The same way some rich clients do > >> with ZRTP. > >> > >> A client/browser doesn't get to do a lot of explaining here. Basically > any > >> nuances beyond "you are" or "you aren't" are likely lost on users. > >> > >> Relying on servers to do something, anything, in order for the > conference > >> to be safe, basically removes the option for a generic client (such as= a > >> browser) to certify a conference as safe. > >> > >> That might still be just fine for a bunch of other use cases, like for > >> example corporate deployments or people who just want to be able to no= t > >> answer certain subpoenas. > >> > >> I am just pointing out that in this case we don't get to have the case > >> that is most relevant to generic users. > >> > >>> or probably by the participants through the RTCP receiver > >>> reports if they notices that wrong SSRC was used, I assume that also > >>> the attacking party will send the RTCP sender reports with the > >>> impersonating SSRC. BTW: wouldn't this cause an SSRC collision? > >> > >> > >> Well ... potentially, and that's a good thought, but that still depend= s > on > >> what the MDD/SFU does. So same points apply. First we need to mandate > what > >> the servers have to do and second clients are now dependent on servers > to do > >> the right thing. > >> > >> Emil > >> > >> > >>> Roni > >>> > >>> > >>>> -----Original Message----- From: Perc > >>>> [mailto:perc-bounces@ietf.org] On Behalf Of Emil Ivov Sent: =D7=99= =D7=95=D7=9D =D7=93 > >>>> 15 =D7=A4=D7=91=D7=A8=D7=95=D7=90=D7=A8 2017 19:56 To: Eric Rescorla= Cc: perc@ietf.org; Bernard > >>>> Aboba Subject: Re: [Perc] Impersonation > >>>> > >>>> > >>>> > >>>> On 2/15/17 12:00 AM, Eric Rescorla wrote: > >>>>> > >>>>> > >>>>> > >>>>> On Tue, Feb 14, 2017 at 8:11 PM, Emil Ivov >>>>> > wrote: > >>>>> > >>>>> That would be one way, yeah, but then isn't the whole idea of > >>>>> PERC to not trust the mdd? > >>>>> > >>>>> > >>>>> No. It's to have confidentiality against the MDD. > >>>>> > >>>>> > >>>>> If thats all we have then we are basicaly saying: we don't trust > >>>>> the mdd to not attack us, but we surely trust it to prevent > >>>>> others from attacking us ... > >>>>> > >>>>> > >>>>> No, because the limit of the attack is allowing one member of > >>>>> the conference (which the MDD cannot control) to impersonate > >>>>> another. > >>>> > >>>> > >>>> You lost me. How do you know what the relationship is between the > >>>> MDD and that participant and that they are not actually controlled > >>>> by the same party? > >>>> > >>>> Anyways, it is hard to argue how big of a deal this is without > >>>> having a full implementation in mind (specifically without clearly > >>>> knowing who owns the KD and how they operate it) but it sounds like > >>>> we need to at least: > >>>> > >>>> A) Mandate that MDDs watch out for that sort of thing (for at least > >>>> the good- natured MDDs) and B) Explicitly mentioning the > >>>> possibility for this in Security Considerations. > >>>> > >>>> Emil > >>>> > >>>>> > >>>>> -Ekr > >>>>> > >>>>> > >>>>> > >>>>> On Tue, 14 Feb 2017 at 21:37, Bernard Aboba > >>>> > >>>> >>>>> > >>>>> > wrote: > >>>>> > >>>>> Presumably the MDD would check the SSRC against the endpoint > >>>>> address so as to avoid forgery. > >>>>> > >>>>> On Feb 14, 2017, at 6:14 PM, Emil Ivov >>>>> > wrote: > >>>>> > >>>>>> While looking at the specs it wasn't immediately obvious to me > >>>>>> exactly what would prevent participant A in a PERC call to > >>>>>> impersonate participant B by simply sending with their SSRC. > >>>>>> Everyone's e2e key is known to everyone else and all the keys > >>>>>> are symmetric. > >>>>>> > >>>>>> Have I missed something or is this a known limitation that we > >>>>>> have stated in the docs? If so could someone please point me to > >>>>>> the relevant place? > >>>>>> > >>>>>> Thanks, Emil > >>>>>> > >>>>>> -- https://jitsi.org -- sent from my mobile > >>>>>> _______________________________________________ Perc mailing > >>>>>> list Perc@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/perc > >>>>>> > >>>>> > >>>>> > >>>>> -- sent from my mobile > >>>>> > >>>>> _______________________________________________ Perc mailing > >>>>> list Perc@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/perc > >>>>> > >>>>> > >>>>> > >>>> > >>>> -- Emil Ivov, Ph.D. 303 Colorado Street, #1600 > >>>> Chief Video Architect Austin, TX, USA Atlassian > >>>> MOBILE:+1.512.420.6968 https://atlassian.com > >>>> eivov@atlassian.com > >>>> > >>>> _______________________________________________ Perc mailing list > >>>> Perc@ietf.org https://www.ietf.org/mailman/listinfo/perc > >>> > >>> > >> > >> -- > >> Emil Ivov, Ph.D. 303 Colorado Street, #1600 > >> Chief Video Architect Austin, TX, USA > >> Atlassian MOBILE:+1.512.420.6968 > >> https://atlassian.com eivov@atlassian.com > > > > > > > > -- > Emil Ivov, Ph.D. 303 Colorado Street, #1600 > Chief Video Architect Austin, TX, USA > Atlassian MOBILE:+1.512.420.6968 > https://atlassian.com eivov@atlassian.com > --94eb2c11555e3920f30548a8505a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 16, 2017 at 8:23 AM, Emil Ivov <eivov@atlassian.com&= gt; wrote:
On Thu= , Feb 16, 2017 at 9:54 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> This property has been known about from the very beginning of PERC. Th= e
> only way to deal with this AFAICT, is to digitally sign the packets (o= r use
> TESLA). I'm pretty sure I made this point in some early meeting.
Could be, it wasn't crystal clear to me. That's fine.

> "Safe" isn't a meaningful security property.

No one is claiming that it is. (Not from a protocol design perspecti= ve).

"Safe" however is an indication that users expect from RTC client= s.

> Think of PERC as rather trying
> to approximate the security properties you would have if you had a gia= nt
> shared conference in which the MDD were replaced with broadcast transp= ort.

Well, if I think of it that way, then the giant full mess call
definitely seems prone to providing significantly better security
properties than what PERC is describing.

Yes, a full mesh call has better security properties. I thought that was = clear.
PERC is a compromise design that is intended to have the d= ataflow
properties of an MCU/SFU with as good privacy properties = as we can get.

=C2=A0
I am more interested in making sure that at least some parts of it
(such as double) can be re-used for something more ambitious.

Well, the design in which double is embedded basical= ly has this property. As
noted above, you would need something ot= her than double.

-Ekr
=C2=A0

Emil

> -Ekr
>
>
> On Thu, Feb 16, 2017 at 7:49 AM, Emil Ivov <eivov@atlassian.com> wrote:
>>
>> Hey Roni,
>>
>> On 2/16/17 12:22 AM, Roni Even wrote:
>>>
>>> Emil, When I look at the MDD I see a decomposed entity. A appl= ication
>>> server and a media server (RFC5567). PERC MDD is only about th= e
>>> second entity (media server). The KDF will connect to the appl= ication
>>> server via signaling (can be part of the application server) a= nd with
>>> the MDD on the media path (e.g. tunneling DTLS SRTP) with no a= ctual
>>> knowledge about the conference roster. The MDD as a media serv= er does
>>> not know about the participants, it only knows about which str= eam to
>>> receive and how to switch them. I think that the issue you rai= se
>>> about a participant using another user's SSRC can be ident= ified by
>>> the MDD
>>
>>
>> Yes, I agree, but then that weakens the promise of PERC as it make= s it
>> rely on servers to do the right thing.
>>
>> The reason why this bothers me (and I know this is vague ... but t= hen
>> again so is PERC in many respects) is that, in an ideal world, PER= C would
>> provide generic clients, such as browsers, to tell their users: &q= uot;you are
>> safe!"
>>
>> The same way browsers do with https. The same way some rich client= s do
>> with ZRTP.
>>
>> A client/browser doesn't get to do a lot of explaining here. B= asically any
>> nuances beyond "you are" or "you aren't" a= re likely lost on users.
>>
>> Relying on servers to do something, anything, in order for the con= ference
>> to be safe, basically removes the option for a generic client (suc= h as a
>> browser) to certify a conference as safe.
>>
>> That might still be just fine for a bunch of other use cases, like= for
>> example corporate deployments or people who just want to be able t= o not
>> answer certain subpoenas.
>>
>> I am just pointing out that in this case we don't get to have = the case
>> that is most relevant to generic users.
>>
>>> or probably by the participants through the RTCP receiver
>>> reports if they notices that wrong SSRC was used, I assume tha= t also
>>> the attacking party will send the RTCP sender reports with the=
>>> impersonating SSRC. BTW: wouldn't this cause an SSRC colli= sion?
>>
>>
>> Well ... potentially, and that's a good thought, but that stil= l depends on
>> what the MDD/SFU does. So same points apply. First we need to mand= ate what
>> the servers have to do and second clients are now dependent on ser= vers to do
>> the right thing.
>>
>> Emil
>>
>>
>>> Roni
>>>
>>>
>>>> -----Original Message----- From: Perc
>>>> [mailto:perc-boun= ces@ietf.org] On Behalf Of Emil Ivov Sent: =D7=99=D7=95=D7=9D =D7=93 >>>> 15 =D7=A4=D7=91=D7=A8=D7=95=D7=90=D7=A8 2017 19:56 To: Eri= c Rescorla Cc: perc@ietf.org; Bernard<= br> >>>> Aboba Subject: Re: [Perc] Impersonation
>>>>
>>>>
>>>>
>>>> On 2/15/17 12:00 AM, Eric Rescorla wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Feb 14, 2017 at 8:11 PM, Emil Ivov <eivov@atlassian.com
>>>>> <mailto:eivo= v@atlassian.com>> wrote:
>>>>>
>>>>> That would be one way, yeah, but then isn't the wh= ole idea of
>>>>> PERC to not trust the mdd?
>>>>>
>>>>>
>>>>> No. It's to have confidentiality against the MDD.<= br> >>>>>
>>>>>
>>>>> If thats all we have then we are basicaly saying: we d= on't trust
>>>>> the mdd to not attack us, but we surely trust it to pr= event
>>>>> others from attacking us ...
>>>>>
>>>>>
>>>>> No, because the limit of the attack is allowing one me= mber of
>>>>> the conference (which the MDD cannot control) to imper= sonate
>>>>> another.
>>>>
>>>>
>>>> You lost me. How do you know what the relationship is betw= een the
>>>> MDD and that participant and that they are not actually co= ntrolled
>>>> by the same party?
>>>>
>>>> Anyways, it is hard to argue how big of a deal this is wit= hout
>>>> having a full implementation in mind (specifically without= clearly
>>>> knowing who owns the KD and how they operate it) but it so= unds like
>>>> we need to at least:
>>>>
>>>> A) Mandate that MDDs watch out for that sort of thing (for= at least
>>>> the good- natured MDDs) and B) Explicitly mentioning the >>>> possibility for this in Security Considerations.
>>>>
>>>> Emil
>>>>
>>>>>
>>>>> -Ekr
>>>>>
>>>>>
>>>>>
>>>>> On Tue, 14 Feb 2017 at 21:37, Bernard Aboba
>>>>
>>>> <bernard.abo= ba@gmail.com
>>>>>
>>>>> <mailto:= bernard.aboba@gmail.com>> wrote:
>>>>>
>>>>> Presumably the MDD would check the SSRC against the en= dpoint
>>>>> address so as to avoid forgery.
>>>>>
>>>>> On Feb 14, 2017, at 6:14 PM, Emil Ivov <eivov@atlassian.com
>>>>> <mailto:eivo= v@atlassian.com>> wrote:
>>>>>
>>>>>> While looking at the specs it wasn't immediate= ly obvious to me
>>>>>> exactly what would prevent participant A in a PERC= call to
>>>>>> impersonate participant B by simply sending with t= heir SSRC.
>>>>>> Everyone's e2e key is known to everyone else a= nd all the keys
>>>>>> are symmetric.
>>>>>>
>>>>>> Have I missed something or is this a known limitat= ion that we
>>>>>> have stated in the docs? If so could someone pleas= e point me to
>>>>>> the relevant place?
>>>>>>
>>>>>> Thanks, Emil
>>>>>>
>>>>>> -- https://jitsi.org -- sent from my mobile
>>>>>> _____________________________________________= __ Perc mailing
>>>>>> list Perc@ietf.or= g <mailto:Perc@ietf.org>
>>>>>> https://www.ietf.org/mailman/listinfo/perc
>>>>>> <https://www.ietf.org/mailman/= listinfo/perc>
>>>>>
>>>>>
>>>>> -- sent from my mobile
>>>>>
>>>>> _______________________________________________ P= erc mailing
>>>>> list Perc@ietf.org <mailto:Perc@ietf.org>
>>>>> https://www.ietf.org/mailman/lis= tinfo/perc
>>>>> <https://www.ietf.org/mailman/listinfo/perc>
>>>>>
>>>>>
>>>>
>>>> -- Emil Ivov, Ph.D.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0303 Colorado Street, #1600
>>>> Chief Video Architect=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Austin, TX, USA Atlassian
>>>> MOBILE:+1.512.420.6968 https://atlassian.com
>>>> eivov@atlassian.com=
>>>>
>>>> _______________________________________________ Perc = mailing list
>>>> Perc@ietf.org https://www.ietf.org/mailman/listinfo/perc
>>>
>>>
>>
>> --
>> Emil Ivov, Ph.D.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0303 Colorado Street, #1600
>> Chief Video Architect=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Austin, TX, USA
>> Atlassian=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MOBILE:+1.512.420.6968
>> https://atlassian.com=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 eivov@atlassian.com >
>



--
Emil Ivov, Ph.D.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0303 Colorado Street, #1600
Chief Video Architect=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Austin, TX, USA
Atlassian=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MOBILE:+1.512.420.6968
http= s://atlassian.com=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 eivov@atlassian.com

--94eb2c11555e3920f30548a8505a-- From nobody Thu Feb 16 12:06:18 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE64A12941A for ; Thu, 16 Feb 2017 12:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=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 iDeLHbo0rn7R for ; Thu, 16 Feb 2017 12:06:14 -0800 (PST) Received: from mail-ot0-f172.google.com (mail-ot0-f172.google.com [74.125.82.172]) (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 5FBDD128E18 for ; Thu, 16 Feb 2017 12:06:14 -0800 (PST) Received: by mail-ot0-f172.google.com with SMTP id t47so18708067ota.1 for ; Thu, 16 Feb 2017 12:06:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=ssZRo8Cpq0s6GNWLSLklv1JL/FvVQ+Q0OEwbwFq5vMo=; b=AeXrFmV4T/HZ0ufJPZfIRo3iepvZ93JJWbOkRKr7cnPNVlVTVuA1sjDj9n7J+WDQmr IVQTHfF5zlhpIvtRUaue+hB+hG37wBrk/tr8RAfCHCW07xpPHJIqJJoMFvW4Kp++oS80 ddsiBkDR9m9i651qiJfuu4LDIkvNwaHSTDUcwmwqGGD2DG13xpBZkyVHkR43HFZMioVp IkiYg79OfcUARX/QBbsb9RyyeTTJ9lqR1emYGkixVaZMuNysRMhzq0898EdpI7bK0PiJ P4yJhF+cfkErBbFDYovcUGuwa2h+2odRTeL0ZA7gK0FqfjcixZzzKWW7RUEhnCF2DpwW g/jg== X-Gm-Message-State: AMke39l5FnwncO7FKfk749mfSJi2lCSMnzIfLwwlXkob1MoWJ7QyzmDNcVZJGlUdVkAQDw== X-Received: by 10.157.52.66 with SMTP id v60mr2224533otb.61.1487275573505; Thu, 16 Feb 2017 12:06:13 -0800 (PST) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id g6sm3389451otb.10.2017.02.16.12.06.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 12:06:12 -0800 (PST) To: Eric Rescorla References: <6E58094ECC8D8344914996DAD28F1CCD774722@DGGEMM506-MBX.china.huawei.com> From: Emil Ivov Organization: Atlassian Message-ID: Date: Thu, 16 Feb 2017 14:06:12 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Roni Even , "perc@ietf.org" , Bernard Aboba Subject: Re: [Perc] Impersonation X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 20:06:16 -0000 On 2/16/17 10:29 AM, Eric Rescorla wrote: > > > On Thu, Feb 16, 2017 at 8:23 AM, Emil Ivov > wrote: > > On Thu, Feb 16, 2017 at 9:54 AM, Eric Rescorla > wrote: > > This property has been known about from the very beginning of PERC. The > > only way to deal with this AFAICT, is to digitally sign the packets (or use > > TESLA). I'm pretty sure I made this point in some early meeting. > > Could be, it wasn't crystal clear to me. That's fine. > > > "Safe" isn't a meaningful security property. > > No one is claiming that it is. (Not from a protocol design perspective). > > "Safe" however is an indication that users expect from RTC clients. > > > Think of PERC as rather trying > > to approximate the security properties you would have if you had a giant > > shared conference in which the MDD were replaced with broadcast transport. > > Well, if I think of it that way, then the giant full mess call > definitely seems prone to providing significantly better security > properties than what PERC is describing. > > > Yes, a full mesh call has better security properties. I thought that was > clear. Didn't you just say, the goal of PERC is to approximate that? > PERC is a compromise design that is intended to have the dataflow > properties of an MCU/SFU with as good privacy properties as we can get. > > > > I am more interested in making sure that at least some parts of it > (such as double) can be re-used for something more ambitious. > > > Well, the design in which double is embedded basically has this property. As > noted above, you would need something other than double. I don't believe that this is a requirement that stems from the design or goals of PERC, but I also don't have an exact change I am ready to debate now, so I'd rather postpone this discussion until later. Emil > > -Ekr > > > > Emil > > > -Ekr > > > > > > On Thu, Feb 16, 2017 at 7:49 AM, Emil Ivov > wrote: > >> > >> Hey Roni, > >> > >> On 2/16/17 12:22 AM, Roni Even wrote: > >>> > >>> Emil, When I look at the MDD I see a decomposed entity. A > application > >>> server and a media server (RFC5567). PERC MDD is only about the > >>> second entity (media server). The KDF will connect to the > application > >>> server via signaling (can be part of the application server) and > with > >>> the MDD on the media path (e.g. tunneling DTLS SRTP) with no actual > >>> knowledge about the conference roster. The MDD as a media server > does > >>> not know about the participants, it only knows about which stream to > >>> receive and how to switch them. I think that the issue you raise > >>> about a participant using another user's SSRC can be identified by > >>> the MDD > >> > >> > >> Yes, I agree, but then that weakens the promise of PERC as it > makes it > >> rely on servers to do the right thing. > >> > >> The reason why this bothers me (and I know this is vague ... but then > >> again so is PERC in many respects) is that, in an ideal world, > PERC would > >> provide generic clients, such as browsers, to tell their users: > "you are > >> safe!" > >> > >> The same way browsers do with https. The same way some rich > clients do > >> with ZRTP. > >> > >> A client/browser doesn't get to do a lot of explaining here. > Basically any > >> nuances beyond "you are" or "you aren't" are likely lost on users. > >> > >> Relying on servers to do something, anything, in order for the > conference > >> to be safe, basically removes the option for a generic client > (such as a > >> browser) to certify a conference as safe. > >> > >> That might still be just fine for a bunch of other use cases, > like for > >> example corporate deployments or people who just want to be able > to not > >> answer certain subpoenas. > >> > >> I am just pointing out that in this case we don't get to have the > case > >> that is most relevant to generic users. > >> > >>> or probably by the participants through the RTCP receiver > >>> reports if they notices that wrong SSRC was used, I assume that also > >>> the attacking party will send the RTCP sender reports with the > >>> impersonating SSRC. BTW: wouldn't this cause an SSRC collision? > >> > >> > >> Well ... potentially, and that's a good thought, but that still > depends on > >> what the MDD/SFU does. So same points apply. First we need to > mandate what > >> the servers have to do and second clients are now dependent on > servers to do > >> the right thing. > >> > >> Emil > >> > >> > >>> Roni > >>> > >>> > >>>> -----Original Message----- From: Perc > >>>> [mailto:perc-bounces@ietf.org ] > On Behalf Of Emil Ivov Sent: יום ד > >>>> 15 פברואר 2017 19:56 To: Eric Rescorla Cc: perc@ietf.org > ; Bernard > >>>> Aboba Subject: Re: [Perc] Impersonation > >>>> > >>>> > >>>> > >>>> On 2/15/17 12:00 AM, Eric Rescorla wrote: > >>>>> > >>>>> > >>>>> > >>>>> On Tue, Feb 14, 2017 at 8:11 PM, Emil Ivov > > >>>>> >> wrote: > >>>>> > >>>>> That would be one way, yeah, but then isn't the whole idea of > >>>>> PERC to not trust the mdd? > >>>>> > >>>>> > >>>>> No. It's to have confidentiality against the MDD. > >>>>> > >>>>> > >>>>> If thats all we have then we are basicaly saying: we don't trust > >>>>> the mdd to not attack us, but we surely trust it to prevent > >>>>> others from attacking us ... > >>>>> > >>>>> > >>>>> No, because the limit of the attack is allowing one member of > >>>>> the conference (which the MDD cannot control) to impersonate > >>>>> another. > >>>> > >>>> > >>>> You lost me. How do you know what the relationship is between the > >>>> MDD and that participant and that they are not actually controlled > >>>> by the same party? > >>>> > >>>> Anyways, it is hard to argue how big of a deal this is without > >>>> having a full implementation in mind (specifically without clearly > >>>> knowing who owns the KD and how they operate it) but it sounds like > >>>> we need to at least: > >>>> > >>>> A) Mandate that MDDs watch out for that sort of thing (for at least > >>>> the good- natured MDDs) and B) Explicitly mentioning the > >>>> possibility for this in Security Considerations. > >>>> > >>>> Emil > >>>> > >>>>> > >>>>> -Ekr > >>>>> > >>>>> > >>>>> > >>>>> On Tue, 14 Feb 2017 at 21:37, Bernard Aboba > >>>> > >>>> > >>>>> > >>>>> >> wrote: > >>>>> > >>>>> Presumably the MDD would check the SSRC against the endpoint > >>>>> address so as to avoid forgery. > >>>>> > >>>>> On Feb 14, 2017, at 6:14 PM, Emil Ivov > >>>>> >> wrote: > >>>>> > >>>>>> While looking at the specs it wasn't immediately obvious to me > >>>>>> exactly what would prevent participant A in a PERC call to > >>>>>> impersonate participant B by simply sending with their SSRC. > >>>>>> Everyone's e2e key is known to everyone else and all the keys > >>>>>> are symmetric. > >>>>>> > >>>>>> Have I missed something or is this a known limitation that we > >>>>>> have stated in the docs? If so could someone please point me to > >>>>>> the relevant place? > >>>>>> > >>>>>> Thanks, Emil > >>>>>> > >>>>>> -- https://jitsi.org -- sent from my mobile > >>>>>> _______________________________________________ Perc mailing > >>>>>> list Perc@ietf.org > > > >>>>>> https://www.ietf.org/mailman/listinfo/perc > > >>>>>> > > >>>>> > >>>>> > >>>>> -- sent from my mobile > >>>>> > >>>>> _______________________________________________ Perc mailing > >>>>> list Perc@ietf.org > > > >>>>> https://www.ietf.org/mailman/listinfo/perc > > >>>>> > > >>>>> > >>>>> > >>>> > >>>> -- Emil Ivov, Ph.D. 303 Colorado Street, #1600 > >>>> Chief Video Architect Austin, TX, USA Atlassian > >>>> MOBILE:+1.512.420.6968 > https://atlassian.com > >>>> eivov@atlassian.com > >>>> > >>>> _______________________________________________ Perc mailing list > >>>> Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > > >>> > >>> > >> > >> -- > >> Emil Ivov, Ph.D. 303 Colorado Street, #1600 > >> Chief Video Architect Austin, TX, USA > >> Atlassian MOBILE:+1.512.420.6968 > > >> https://atlassian.com eivov@atlassian.com > > > > > > > > > -- > Emil Ivov, Ph.D. 303 Colorado Street, #1600 > Chief Video Architect Austin, TX, USA > Atlassian MOBILE:+1.512.420.6968 > > https://atlassian.com eivov@atlassian.com > > > -- Emil Ivov, Ph.D. 303 Colorado Street, #1600 Chief Video Architect Austin, TX, USA Atlassian MOBILE:+1.512.420.6968 https://atlassian.com eivov@atlassian.com From nobody Thu Feb 16 12:34:16 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C06129590 for ; Thu, 16 Feb 2017 12:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 O1aU6AnkFFVN for ; Thu, 16 Feb 2017 12:34:12 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 43DC8129531 for ; Thu, 16 Feb 2017 12:34:12 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id u68so14125172ywg.0 for ; Thu, 16 Feb 2017 12:34:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vgWKneeVi7DZJn0KdVqNxSv30C+rUlY38QzB+wPk0is=; b=JxMDEgAEo66T2JAxAa3sDp/1A7U/mlZt56Z6WnPIKtSXyHvT5CnwWCgYGxdJBloKLi nzCxCY+hfhqWJ/UMw9G+fyP4cnWeAGrFL7KL8jBES/GgF3f3ZsBT7NrFucOKjRlBpKkQ nu/M/oSXrp5rnojQdEf14+V+p8a4N+c35LCvXf7Y4H3XKo+Lnb/uqqGPRLslN0h44EMi zaYHFLN8VditsWuIXl2pyWeHKiSa20pTKMaCbacA4WZyXTFKlwz84Tjfi6d2QXIti3gt ktDYJ6ze07dufnda3PWzqCoRhbB0N84n1uqUi2/ecxYPPbYoQvZLLZvv6ePMHEzcF2Vn VCtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vgWKneeVi7DZJn0KdVqNxSv30C+rUlY38QzB+wPk0is=; b=q8ScVr8oKCEYubbxbmVeggfoOHvNjS4y11igjRbAaMzp/DJj3Ah57kQXm5E0xtqoVq yATP0VPCy3wmUiEvrn78WqOQzKtb8fJmBum8NS8KIV6nHzIbAGIvk4fm1xMj8VLmoMFQ 0nU26rPnh9e3lx1FgcZB6/3ZdKYdNMqLOcMi5EYm99+AxstLYe1n8jzS8pb7ui46j23m 5y4rix0a4NOJOOCEoP+NYktIxhny6FQ6B85JWAigIiV/AGgNbSEUPAQA8on7CGrMg5ev L7d+OWushneIqSZuAraEExIJyUx2b2sX0yH9N5DuETEStYvfbzo+kSTttDzsKIIJG712 8X/A== X-Gm-Message-State: AMke39ksUpfK/mURtTsWp+MS7zPw7Y29qtKKqhYeo9TtqY+MWwgGinzS/DbJKCYmHoF0ighAkLPUAKS6QkY3Xg== X-Received: by 10.129.125.84 with SMTP id y81mr3019952ywc.120.1487277251278; Thu, 16 Feb 2017 12:34:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Thu, 16 Feb 2017 12:33:30 -0800 (PST) In-Reply-To: References: <6E58094ECC8D8344914996DAD28F1CCD774722@DGGEMM506-MBX.china.huawei.com> From: Eric Rescorla Date: Thu, 16 Feb 2017 12:33:30 -0800 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=001a114928ba3eff680548abb83e Archived-At: Cc: Roni Even , "perc@ietf.org" , Bernard Aboba Subject: Re: [Perc] Impersonation X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 20:34:14 -0000 --001a114928ba3eff680548abb83e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 16, 2017 at 12:06 PM, Emil Ivov wrote: > > > On 2/16/17 10:29 AM, Eric Rescorla wrote: > >> >> >> On Thu, Feb 16, 2017 at 8:23 AM, Emil Ivov > > wrote: >> >> On Thu, Feb 16, 2017 at 9:54 AM, Eric Rescorla > > wrote: >> > This property has been known about from the very beginning of PERC= . >> The >> > only way to deal with this AFAICT, is to digitally sign the packet= s >> (or use >> > TESLA). I'm pretty sure I made this point in some early meeting. >> >> Could be, it wasn't crystal clear to me. That's fine. >> >> > "Safe" isn't a meaningful security property. >> >> No one is claiming that it is. (Not from a protocol design >> perspective). >> >> "Safe" however is an indication that users expect from RTC clients. >> >> > Think of PERC as rather trying >> > to approximate the security properties you would have if you had a >> giant >> > shared conference in which the MDD were replaced with broadcast >> transport. >> >> Well, if I think of it that way, then the giant full mess call >> definitely seems prone to providing significantly better security >> properties than what PERC is describing. >> >> >> Yes, a full mesh call has better security properties. I thought that was >> clear. >> > > Didn't you just say, the goal of PERC is to approximate that? No. It's an approximation to broadcast. -Ekr > > > PERC is a compromise design that is intended to have the dataflow >> properties of an MCU/SFU with as good privacy properties as we can get. >> >> >> >> I am more interested in making sure that at least some parts of it >> (such as double) can be re-used for something more ambitious. >> >> >> Well, the design in which double is embedded basically has this property= . >> As >> noted above, you would need something other than double. >> > > I don't believe that this is a requirement that stems from the design or > goals of PERC, but I also don't have an exact change I am ready to debate > now, so I'd rather postpone this discussion until later. > > Emil > > >> -Ekr >> >> >> >> Emil >> >> > -Ekr >> > >> > >> > On Thu, Feb 16, 2017 at 7:49 AM, Emil Ivov > > wrote: >> >> >> >> Hey Roni, >> >> >> >> On 2/16/17 12:22 AM, Roni Even wrote: >> >>> >> >>> Emil, When I look at the MDD I see a decomposed entity. A >> application >> >>> server and a media server (RFC5567). PERC MDD is only about the >> >>> second entity (media server). The KDF will connect to the >> application >> >>> server via signaling (can be part of the application server) and >> with >> >>> the MDD on the media path (e.g. tunneling DTLS SRTP) with no >> actual >> >>> knowledge about the conference roster. The MDD as a media server >> does >> >>> not know about the participants, it only knows about which strea= m >> to >> >>> receive and how to switch them. I think that the issue you raise >> >>> about a participant using another user's SSRC can be identified = by >> >>> the MDD >> >> >> >> >> >> Yes, I agree, but then that weakens the promise of PERC as it >> makes it >> >> rely on servers to do the right thing. >> >> >> >> The reason why this bothers me (and I know this is vague ... but >> then >> >> again so is PERC in many respects) is that, in an ideal world, >> PERC would >> >> provide generic clients, such as browsers, to tell their users: >> "you are >> >> safe!" >> >> >> >> The same way browsers do with https. The same way some rich >> clients do >> >> with ZRTP. >> >> >> >> A client/browser doesn't get to do a lot of explaining here. >> Basically any >> >> nuances beyond "you are" or "you aren't" are likely lost on users= . >> >> >> >> Relying on servers to do something, anything, in order for the >> conference >> >> to be safe, basically removes the option for a generic client >> (such as a >> >> browser) to certify a conference as safe. >> >> >> >> That might still be just fine for a bunch of other use cases, >> like for >> >> example corporate deployments or people who just want to be able >> to not >> >> answer certain subpoenas. >> >> >> >> I am just pointing out that in this case we don't get to have the >> case >> >> that is most relevant to generic users. >> >> >> >>> or probably by the participants through the RTCP receiver >> >>> reports if they notices that wrong SSRC was used, I assume that >> also >> >>> the attacking party will send the RTCP sender reports with the >> >>> impersonating SSRC. BTW: wouldn't this cause an SSRC collision? >> >> >> >> >> >> Well ... potentially, and that's a good thought, but that still >> depends on >> >> what the MDD/SFU does. So same points apply. First we need to >> mandate what >> >> the servers have to do and second clients are now dependent on >> servers to do >> >> the right thing. >> >> >> >> Emil >> >> >> >> >> >>> Roni >> >>> >> >>> >> >>>> -----Original Message----- From: Perc >> >>>> [mailto:perc-bounces@ietf.org ] >> On Behalf Of Emil Ivov Sent: =D7=99=D7=95=D7=9D =D7=93 >> >>>> 15 =D7=A4=D7=91=D7=A8=D7=95=D7=90=D7=A8 2017 19:56 To: Eric Res= corla Cc: perc@ietf.org >> ; Bernard >> >>>> Aboba Subject: Re: [Perc] Impersonation >> >>>> >> >>>> >> >>>> >> >>>> On 2/15/17 12:00 AM, Eric Rescorla wrote: >> >>>>> >> >>>>> >> >>>>> >> >>>>> On Tue, Feb 14, 2017 at 8:11 PM, Emil Ivov >> >> >>>>> >> >> wrote: >> >>>>> >> >>>>> That would be one way, yeah, but then isn't the whole idea of >> >>>>> PERC to not trust the mdd? >> >>>>> >> >>>>> >> >>>>> No. It's to have confidentiality against the MDD. >> >>>>> >> >>>>> >> >>>>> If thats all we have then we are basicaly saying: we don't tru= st >> >>>>> the mdd to not attack us, but we surely trust it to prevent >> >>>>> others from attacking us ... >> >>>>> >> >>>>> >> >>>>> No, because the limit of the attack is allowing one member of >> >>>>> the conference (which the MDD cannot control) to impersonate >> >>>>> another. >> >>>> >> >>>> >> >>>> You lost me. How do you know what the relationship is between t= he >> >>>> MDD and that participant and that they are not actually >> controlled >> >>>> by the same party? >> >>>> >> >>>> Anyways, it is hard to argue how big of a deal this is without >> >>>> having a full implementation in mind (specifically without >> clearly >> >>>> knowing who owns the KD and how they operate it) but it sounds >> like >> >>>> we need to at least: >> >>>> >> >>>> A) Mandate that MDDs watch out for that sort of thing (for at >> least >> >>>> the good- natured MDDs) and B) Explicitly mentioning the >> >>>> possibility for this in Security Considerations. >> >>>> >> >>>> Emil >> >>>> >> >>>>> >> >>>>> -Ekr >> >>>>> >> >>>>> >> >>>>> >> >>>>> On Tue, 14 Feb 2017 at 21:37, Bernard Aboba >> >>>> >> >>>> >> >>>>> >> >>>>> > >> wrote: >> >>>>> >> >>>>> Presumably the MDD would check the SSRC against the endpoint >> >>>>> address so as to avoid forgery. >> >>>>> >> >>>>> On Feb 14, 2017, at 6:14 PM, Emil Ivov > >> >>>>> >> >> wrote: >> >>>>> >> >>>>>> While looking at the specs it wasn't immediately obvious to m= e >> >>>>>> exactly what would prevent participant A in a PERC call to >> >>>>>> impersonate participant B by simply sending with their SSRC. >> >>>>>> Everyone's e2e key is known to everyone else and all the keys >> >>>>>> are symmetric. >> >>>>>> >> >>>>>> Have I missed something or is this a known limitation that we >> >>>>>> have stated in the docs? If so could someone please point me = to >> >>>>>> the relevant place? >> >>>>>> >> >>>>>> Thanks, Emil >> >>>>>> >> >>>>>> -- https://jitsi.org -- sent from my mobile >> >>>>>> _______________________________________________ Perc mailing >> >>>>>> list Perc@ietf.org >> > >> >>>>>> https://www.ietf.org/mailman/listinfo/perc >> >> >>>>>> > > >> >>>>> >> >>>>> >> >>>>> -- sent from my mobile >> >>>>> >> >>>>> _______________________________________________ Perc mailing >> >>>>> list Perc@ietf.org >> > >> >>>>> https://www.ietf.org/mailman/listinfo/perc >> >> >>>>> > > >> >>>>> >> >>>>> >> >>>> >> >>>> -- Emil Ivov, Ph.D. 303 Colorado Street, >> #1600 >> >>>> Chief Video Architect Austin, TX, USA Atlassian >> >>>> MOBILE:+1.512.420.6968 >> https://atlassian.com >> >>>> eivov@atlassian.com >> >>>> >> >>>> _______________________________________________ Perc mailing >> list >> >>>> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >> >> >>> >> >>> >> >> >> >> -- >> >> Emil Ivov, Ph.D. 303 Colorado Street, #1600 >> >> Chief Video Architect Austin, TX, USA >> >> Atlassian MOBILE:+1.512.420.6968 >> >> >> https://atlassian.com eivov@atlassian.com >> >> > >> > >> >> >> >> -- >> Emil Ivov, Ph.D. 303 Colorado Street, #1600 >> Chief Video Architect Austin, TX, USA >> Atlassian MOBILE:+1.512.420.6968 >> >> https://atlassian.com eivov@atlassian.com >> >> >> >> > -- > Emil Ivov, Ph.D. 303 Colorado Street, #1600 > Chief Video Architect Austin, TX, USA > Atlassian MOBILE:+1.512.420.6968 > https://atlassian.com eivov@atlassian.com > --001a114928ba3eff680548abb83e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 16, 2017 at 12:06 PM, Emil Ivov <eivov@atlassian.com= > wrote:


On 2/16/17 10:29 AM, Eric Rescorla wrote:


On Thu, Feb 16, 2017 at 8:23 AM, Emil Ivov <eivov@atlassian.com
 <mailto:eivov@a= tlassian.com>> wrote:

=C2=A0 =C2=A0 On Thu, Feb 16, 2017 at 9:54 AM, Eric Rescorla <ekr@rtfm.com
 =C2=A0 =C2=A0 <mailto:= ekr@rtfm.com>> wrote:
=C2=A0 =C2=A0 > This property has been known about from the very beginni= ng of PERC. The
=C2=A0 =C2=A0 > only way to deal with this AFAICT, is to digitally sign = the packets (or use
=C2=A0 =C2=A0 > TESLA). I'm pretty sure I made this point in some ea= rly meeting.

=C2=A0 =C2=A0 Could be, it wasn't crystal clear to me. That's fine.=

=C2=A0 =C2=A0 > "Safe" isn't a meaningful security propert= y.

=C2=A0 =C2=A0 No one is claiming that it is. (Not from a protocol design pe= rspective).

=C2=A0 =C2=A0 "Safe" however is an indication that users expect f= rom RTC clients.

=C2=A0 =C2=A0 > Think of PERC as rather trying
=C2=A0 =C2=A0 > to approximate the security properties you would have if= you had a giant
=C2=A0 =C2=A0 > shared conference in which the MDD were replaced with br= oadcast transport.

=C2=A0 =C2=A0 Well, if I think of it that way, then the giant full mess cal= l
=C2=A0 =C2=A0 definitely seems prone to providing significantly better secu= rity
=C2=A0 =C2=A0 properties than what PERC is describing.


Yes, a full mesh call has better security properties. I thought that was clear.

Didn't you just say, the goal of PERC is to approximate that?

No. It's an approximation to broadcast.

-Ekr
=C2=A0
=

PERC is a compromise design that is intended to have the dataflow
properties of an MCU/SFU with as good privacy properties as we can get.



=C2=A0 =C2=A0 I am more interested in making sure that at least some parts = of it
=C2=A0 =C2=A0 (such as double) can be re-used for something more ambitious.=


Well, the design in which double is embedded basically has this property. A= s
noted above, you would need something other than double.

 I don't believe that this is a requirement that stems from the design o= r goals of PERC, but I also don't have an exact change I am ready to de= bate now, so I'd rather postpone this discussion until later.

Emil


-Ekr



=C2=A0 =C2=A0 Emil

=C2=A0 =C2=A0 > -Ekr
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > On Thu, Feb 16, 2017 at 7:49 AM, Emil Ivov <eivov@atlassian.com
=C2=A0 =C2=A0 <mailto:eivov@atlassian.com>> wrote:
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Hey Roni,
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> On 2/16/17 12:22 AM, Roni Even wrote:
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> Emil, When I look at the MDD I see a decomposed = entity. A
=C2=A0 =C2=A0 application
=C2=A0 =C2=A0 >>> server and a media server (RFC5567). PERC MDD is= only about the
=C2=A0 =C2=A0 >>> second entity (media server). The KDF will conne= ct to the
=C2=A0 =C2=A0 application
=C2=A0 =C2=A0 >>> server via signaling (can be part of the applica= tion server) and
=C2=A0 =C2=A0 with
=C2=A0 =C2=A0 >>> the MDD on the media path (e.g. tunneling DTLS S= RTP) with no actual
=C2=A0 =C2=A0 >>> knowledge about the conference roster. The MDD a= s a media server
=C2=A0 =C2=A0 does
=C2=A0 =C2=A0 >>> not know about the participants, it only knows a= bout which stream to
=C2=A0 =C2=A0 >>> receive and how to switch them. I think that the= issue you raise
=C2=A0 =C2=A0 >>> about a participant using another user's SSR= C can be identified by
=C2=A0 =C2=A0 >>> the MDD
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Yes, I agree, but then that weakens the promise of P= ERC as it
=C2=A0 =C2=A0 makes it
=C2=A0 =C2=A0 >> rely on servers to do the right thing.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> The reason why this bothers me (and I know this is v= ague ... but then
=C2=A0 =C2=A0 >> again so is PERC in many respects) is that, in an id= eal world,
=C2=A0 =C2=A0 PERC would
=C2=A0 =C2=A0 >> provide generic clients, such as browsers, to tell t= heir users:
=C2=A0 =C2=A0 "you are
=C2=A0 =C2=A0 >> safe!"
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> The same way browsers do with https. The same way so= me rich
=C2=A0 =C2=A0 clients do
=C2=A0 =C2=A0 >> with ZRTP.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> A client/browser doesn't get to do a lot of expl= aining here.
=C2=A0 =C2=A0 Basically any
=C2=A0 =C2=A0 >> nuances beyond "you are" or "you aren= 't" are likely lost on users.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Relying on servers to do something, anything, in ord= er for the
=C2=A0 =C2=A0 conference
=C2=A0 =C2=A0 >> to be safe, basically removes the option for a gener= ic client
=C2=A0 =C2=A0 (such as a
=C2=A0 =C2=A0 >> browser) to certify a conference as safe.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> That might still be just fine for a bunch of other u= se cases,
=C2=A0 =C2=A0 like for
=C2=A0 =C2=A0 >> example corporate deployments or people who just wan= t to be able
=C2=A0 =C2=A0 to not
=C2=A0 =C2=A0 >> answer certain subpoenas.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> I am just pointing out that in this case we don'= t get to have the
=C2=A0 =C2=A0 case
=C2=A0 =C2=A0 >> that is most relevant to generic users.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>> or probably by the participants through the RTCP= receiver
=C2=A0 =C2=A0 >>> reports if they notices that wrong SSRC was used= , I assume that also
=C2=A0 =C2=A0 >>> the attacking party will send the RTCP sender re= ports with the
=C2=A0 =C2=A0 >>> impersonating SSRC. BTW: wouldn't this cause= an SSRC collision?
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Well ... potentially, and that's a good thought,= but that still
=C2=A0 =C2=A0 depends on
=C2=A0 =C2=A0 >> what the MDD/SFU does. So same points apply. First w= e need to
=C2=A0 =C2=A0 mandate what
=C2=A0 =C2=A0 >> the servers have to do and second clients are now de= pendent on
=C2=A0 =C2=A0 servers to do
=C2=A0 =C2=A0 >> the right thing.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Emil
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>> Roni
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>>> -----Original Message----- From: Perc
=C2=A0 =C2=A0 >>>> [mailto:perc-bounces@ietf.org <mailto:perc-bounces@ietf.org>]
=C2=A0 =C2=A0 On Behalf Of Emil Ivov Sent: =D7=99=D7=95=D7=9D =D7=93
=C2=A0 =C2=A0 >>>> 15 =D7=A4=D7=91=D7=A8=D7=95=D7=90=D7=A8 2017= 19:56 To: Eric Rescorla Cc: perc@ietf.org
 =C2=A0 =C2=A0 <mailto:perc@ietf.org>; Bernard
=C2=A0 =C2=A0 >>>> Aboba Subject: Re: [Perc] Impersonation
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> On 2/15/17 12:00 AM, Eric Rescorla wrote: =C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>> On Tue, Feb 14, 2017 at 8:11 PM, Emil Iv= ov
=C2=A0 =C2=A0 <= eivov@atlassian.com <mailto:eivov@atlassian.com>
 =C2=A0 =C2=A0 >>>>> <mailto:eivov@atlassian.com <mailto:eivov@atlassian.com>>= ;> wrote:
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>> That would be one way, yeah, but then is= n't the whole idea of
=C2=A0 =C2=A0 >>>>> PERC to not trust the mdd?
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>> No. It's to have confidentiality aga= inst the MDD.
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>> If thats all we have then we are basical= y saying: we don't trust
=C2=A0 =C2=A0 >>>>> the mdd to not attack us, but we surely = trust it to prevent
=C2=A0 =C2=A0 >>>>> others from attacking us ...
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>> No, because the limit of the attack is a= llowing one member of
=C2=A0 =C2=A0 >>>>> the conference (which the MDD cannot con= trol) to impersonate
=C2=A0 =C2=A0 >>>>> another.
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> You lost me. How do you know what the relati= onship is between the
=C2=A0 =C2=A0 >>>> MDD and that participant and that they are n= ot actually controlled
=C2=A0 =C2=A0 >>>> by the same party?
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> Anyways, it is hard to argue how big of a de= al this is without
=C2=A0 =C2=A0 >>>> having a full implementation in mind (specif= ically without clearly
=C2=A0 =C2=A0 >>>> knowing who owns the KD and how they operate= it) but it sounds like
=C2=A0 =C2=A0 >>>> we need to at least:
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> A) Mandate that MDDs watch out for that sort= of thing (for at least
=C2=A0 =C2=A0 >>>> the good- natured MDDs) and B) Explicitly me= ntioning the
=C2=A0 =C2=A0 >>>> possibility for this in Security Considerati= ons.
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> Emil
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>> -Ekr
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>> On Tue, 14 Feb 2017 at 21:37, Bernard Ab= oba
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> <bernard.aboba@gmail.com <mailto:bernard.aboba@gmail.com<= /a>>
=C2=A0 =C2=A0 >>>>>
 =C2=A0 =C2=A0 >>>>> <mailto:bernard.aboba@gmail.com
=C2=A0 =C2=A0 <mailto:bernard.aboba@gmail.com>>> wrote:
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>> Presumably the MDD would check the SSRC = against the endpoint
=C2=A0 =C2=A0 >>>>> address so as to avoid forgery.
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>> On Feb 14, 2017, at 6:14 PM, Emil Ivov &= lt;eivov@atlassian= .com
=C2=A0 =C2=A0 <mailto:eivov@atlassian.com>
 =C2=A0 =C2=A0 >>>>> <mailto:eivov@atlassian.com <mailto:eivov@atlassian.com>>= ;> wrote:
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>>> While looking at the specs it wasn&#= 39;t immediately obvious to me
=C2=A0 =C2=A0 >>>>>> exactly what would prevent participa= nt A in a PERC call to
=C2=A0 =C2=A0 >>>>>> impersonate participant B by simply = sending with their SSRC.
=C2=A0 =C2=A0 >>>>>> Everyone's e2e key is known to e= veryone else and all the keys
=C2=A0 =C2=A0 >>>>>> are symmetric.
=C2=A0 =C2=A0 >>>>>>
=C2=A0 =C2=A0 >>>>>> Have I missed something or is this a= known limitation that we
=C2=A0 =C2=A0 >>>>>> have stated in the docs? If so could= someone please point me to
=C2=A0 =C2=A0 >>>>>> the relevant place?
=C2=A0 =C2=A0 >>>>>>
=C2=A0 =C2=A0 >>>>>> Thanks, Emil
=C2=A0 =C2=A0 >>>>>>
=C2=A0 =C2=A0 >>>>>> -- https://jitsi.org -- sent from my mob= ile
=C2=A0 =C2=A0 >>>>>> _______________________________= ________________ Perc mailing
=C2=A0 =C2=A0 >>>>>> list Perc@ietf.org <mailto:Perc@ietf.org>
 =C2=A0 =C2=A0 <mailto:Perc@ietf.org <mailto:Perc@ietf.org>>
=C2=A0 =C2=A0 >>>>>> https://www.ietf.or= g/mailman/listinfo/perc
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listin= fo/perc>
=C2=A0 =C2=A0 >>>>>> <https://www.iet= f.org/mailman/listinfo/perc
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listin= fo/perc>>
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>> -- sent from my mobile
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>> ___________________________________= ____________ Perc mailing
=C2=A0 =C2=A0 >>>>> list Perc@ietf.org <mailto:Perc@ietf.org>
 =C2=A0 =C2=A0 <mailto:Perc@ietf.org <mailto:Perc@ietf.org>>
=C2=A0 =C2=A0 >>>>> https://www.ietf.org/ma= ilman/listinfo/perc
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listin= fo/perc>
=C2=A0 =C2=A0 >>>>> <https://www.ietf.or= g/mailman/listinfo/perc
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listin= fo/perc>>
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> -- Emil Ivov, Ph.D.=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0303 Colorado Street, #1= 600
=C2=A0 =C2=A0 >>>> Chief Video Architect=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Austin, TX, USA Atlassian
 =C2=A0 =C2=A0 >>>> MOBILE:+1.512.420.6968 <tel:%2B1.512.= 420.6968>
=C2=A0 =C2=A0 https://atlassian.com
=C2=A0 =C2=A0 >>>> eivov@atlassian.com <mailto:eivov@atlassian.com>
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> _______________________________________= ________ Perc mailing list
=C2=A0 =C2=A0 >>>> Perc@ietf.org <mailto:Perc@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/p= erc
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listin= fo/perc>
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> --
=C2=A0 =C2=A0 >> Emil Ivov, Ph.D.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0303 Colorado Street, #1600
=C2=A0 =C2=A0 >> Chief Video Architect=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Austin, TX, USA
=C2=A0 =C2=A0 >> Atlassian=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MOBILE:+1.512.420.6= 968
 =C2=A0 =C2=A0 <tel:%2B1.512.420.6968>
=C2=A0 =C2=A0 >> https://atlassian.com=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 eivov@atlassian.com
=C2=A0 =C2=A0 <mailto:eivov@atlassian.com>
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >



=C2=A0 =C2=A0 --
=C2=A0 =C2=A0 Emil Ivov, Ph.D.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0303 Colorado Street, #1600
=C2=A0 =C2=A0 Chief Video Architect=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Austin, TX, USA
=C2=A0 =C2=A0 Atlassian=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MOBILE:+1.512.420.6968 =C2=A0 =C2=A0 <tel:%2B1.512.420.6968>
=C2=A0 =C2=A0 https://atlassian.com=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 = eivov@atlassian.com
=C2=A0 =C2=A0 <mailto:eivov@atlassian.com>



--
Emil Ivov, Ph.D.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0303 Colorado Street, #1600
Chief Video Architect=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Austin, TX, USA
Atlassian=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MOBILE:+1.512.420.6968
http= s://atlassian.com=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 eivov@atlassia= n.com

--001a114928ba3eff680548abb83e-- From nobody Thu Feb 16 14:40:13 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB66124281 for ; Thu, 16 Feb 2017 14:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.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 6cPFEarGGZ_A for ; Thu, 16 Feb 2017 14:40:10 -0800 (PST) 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 B72C4129762 for ; Thu, 16 Feb 2017 14:39:49 -0800 (PST) Received: from [192.168.1.20] (cpe-098-122-167-029.nc.res.rr.com [98.122.167.29] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id v1GMdkxe014354 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Feb 2017 17:39:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1487284787; bh=kycEtwlhR63lLdTPaIqRwH6ZqvEk7gSBi7D7imGekb8=; h=From:To:Subject:Date:In-Reply-To:References:Reply-To; b=ddC+L3UXlf9DHnm51nxnyr1gCiWlwmH1ZHiTyuybyXl6ojp9+Mq8AgfaY0+Z0hXwL uFqKoCuz14mWpBxyh2+kYOgPpbqy7uUA1B3NnbB3lrDAs+BQw4f3CKeRgaULvGci11 awhlfQhGoaCj3OkZGWdDEMOHS8zHq3aeZKvagRBM= From: "Paul E. Jones" To: "Emil Ivov" , "perc@ietf.org" Date: Thu, 16 Feb 2017 22:39:47 +0000 Message-Id: In-Reply-To: References: User-Agent: eM_Client/7.0.28492.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB8A248F9A-03F4-4F06-822F-A664A78D1DB8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Thu, 16 Feb 2017 17:39:47 -0500 (EST) Archived-At: Subject: Re: [Perc] Impersonation X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 16 Feb 2017 22:40:12 -0000 --------=_MB8A248F9A-03F4-4F06-822F-A664A78D1DB8 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Emil, The endpoint is a trusted entity in the current design. As it's=20 trusted, the assumption is Alice would not put Bob's audio into her flow=20 or pretend to be Bob by misappropriating his SSRC or other information=20 (e.g., CNAME). Paul ------ Original Message ------ From: "Emil Ivov" To: "perc@ietf.org" Sent: 2/14/2017 9:14:40 PM Subject: [Perc] Impersonation >While looking at the specs it wasn't immediately obvious to me exactly=20 >what would prevent participant A in a PERC call to impersonate=20 >participant B by simply sending with their SSRC. Everyone's e2e key is=20 >known to everyone else and all the keys are symmetric. > >Have I missed something or is this a known limitation that we have=20 >stated in the docs? If so could someone please point me to the relevant=20 >place? > >Thanks, >Emil > >-- >https://jitsi.org >-- >sent from my mobile --------=_MB8A248F9A-03F4-4F06-822F-A664A78D1DB8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Emil,

The endpoint= is a trusted entity in the current design. =C2=A0As it's trusted, the assum= ption is Alice would not put Bob's audio into her flow or pretend to be Bob = by misappropriating his SSRC or other information (e.g., CNAME).

Paul

------ Original Message ------
From: "Emil Ivov" <eivov@atl= assian.com>
To: "perc@ietf.org" <perc@ietf.org= >
Sent: 2/14/2017 9:14:40 PM
Subject: [Perc] Impersonation

While looking at the specs it wasn't immediately obvious to me exactly = what would prevent participant A in a PERC call to impersonate participant = B by simply sending with their SSRC. Everyone's e2e key is known to everyo= ne else and all the keys are symmetric.

Have I m= issed something or is this a known limitation that we have stated in the do= cs? If so could someone please point me to the relevant place?
Thanks,
Emil

--=C2=A0
--
sent from m= y mobile
--------=_MB8A248F9A-03F4-4F06-822F-A664A78D1DB8--