From nobody Wed Sep 9 03:00:33 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1B61B3080 for ; Wed, 9 Sep 2015 03:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jv_rcnIRvwol for ; Wed, 9 Sep 2015 03:00:30 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 860A31B307E for ; Wed, 9 Sep 2015 03:00:30 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-a5-55f0033c11c9 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D7.66.27359.C3300F55; Wed, 9 Sep 2015 12:00:28 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.3.248.2; Wed, 9 Sep 2015 12:00:27 +0200 To: From: Magnus Westerlund Message-ID: <55F0033B.8080408@ericsson.com> Date: Wed, 9 Sep 2015 12:00:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKJMWRmVeSWpSXmKPExsUyM+Jvja4N84dQgzOfjCxWL5zO6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJ7505kLLrBVrHzZzd7AuI61i5GTQ0LARGJxyyF2CFtM4sK9 9WxdjFwcQgJHGSXmX7rCBOEsY5RoPXYcrEpEQFjix4WJYDabgIXEzR+NbCC2sICXxK3/X5hA bF4BbYlzdzYwdzFycLAIqEh82+ADEhYViJHo+bWBDaJEUOLkzCcsICXMAvYSD7aWgYSZBeQl mrfOZgaxhYCmNDR1sE5g5JuFpGMWQscsJB0LGJlXMYoWpxYn5aYbGemlFmUmFxfn5+nlpZZs YgSG08Etvw12ML587niIUYCDUYmHd8Gk96FCrIllxZW5hxilOViUxHmbmR6ECgmkJ5akZqem FqQWxReV5qQWH2Jk4uCUamAsOMO7/AXHZrPpDCZajb2+fEziOzYsFpSSvLtK4+J5SV9nWdOz ydGHumV8f3y4lWG4U/kl944HR0S8mObZlfe2Tqxdd/RyYqa/v2XWXqaPzz/aqu/Z6Mxe5TZb +mjjK2m3I8xXF8oq1VnaHL74pHdCm8UJNtt23gOZbrmSbhdPsmzcfdFwLrMSS3FGoqEWc1Fx IgDlHTtsCAIAAA== Archived-At: Subject: [Perc] What is happening with the design team for E2E protection in SRTP X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 10:00:32 -0000 Hi, To my understanding the chairs where going to start up a design team for discussing and developing a proposal for how the end-to-end protection should be done in SRTP. Considering that it is only slightly more than a month to draft cut-off and 1,5 months to Yokohama, if we should make any progress prior to that we need to get started. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Sep 24 14:46:39 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFEAE1B2D30 for ; Thu, 24 Sep 2015 14:46:37 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkls4Wf8UNOP for ; Thu, 24 Sep 2015 14:46:36 -0700 (PDT) Received: from mail-io0-f181.google.com (mail-io0-f181.google.com [209.85.223.181]) (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 0F0D61B2D3B for ; Thu, 24 Sep 2015 14:46:25 -0700 (PDT) Received: by iofb144 with SMTP id b144so92261099iof.1 for ; Thu, 24 Sep 2015 14:46:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=B52NxcPx7QRHWbeGOlpI1Wg9SkLSnFJHO/SVwCXZDXs=; b=mZnh06WrdfN+W237aHU4choBhtD8V2uGmgh4ZWRfqkCvTxoFqSVKUJdW9QdQj9RjIW Knz/bK1K83oMMncw+t6mVQg+VqfYiWVPNaWEntuIEGA8yHmaTBReRQPOSpt0+6hYxOxc 0DqsbbcmvwFfOND8eRqn+aP7EjpYJeW3tSVMUv3eGQ9btOKJaGFqqmCMZgNgoMDOPkLR kTqML/7f+Fj0pl8klnFi9itC6vrAFZcDtJgATsL/Wwk/uU+kInCi1V4TI/a9qynXorKB fjtmXNciJJ3BcT3K2hUXNvlyKRGInIuSBWwBZ9FoZp75Q/ZXA9fn+3BuBZv/4R9dtqpp ap2w== X-Gm-Message-State: ALoCoQmoxR6lIJf8ZIMDiNnPKIEuiTuZtsEaFlUmetRaK+A1VQGpOGc6SSe8HSd3f1nH2gibFwX8 X-Received: by 10.107.16.158 with SMTP id 30mr3190193ioq.50.1443131184298; Thu, 24 Sep 2015 14:46:24 -0700 (PDT) Received: from aither.local ([2601:282:4201:ef5b:b4f1:9b43:b766:6d96]) by smtp.googlemail.com with ESMTPSA id 68sm384764ioz.5.2015.09.24.14.46.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Sep 2015 14:46:23 -0700 (PDT) To: perc@ietf.org References: <55F0033B.8080408@ericsson.com> From: Peter Saint-Andre - &yet Message-ID: <56046F2D.7080605@andyet.net> Date: Thu, 24 Sep 2015 15:46:21 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55F0033B.8080408@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Perc] What is happening with the design team for E2E protection in SRTP X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 21:46:38 -0000 On 9/9/15 4:00 AM, Magnus Westerlund wrote: > Hi, > > To my understanding the chairs where going to start up a design team for > discussing and developing a proposal for how the end-to-end protection > should be done in SRTP. > > Considering that it is only slightly more than a month to draft cut-off > and 1,5 months to Yokohama, if we should make any progress prior to that > we need to get started. Any further news on this? Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Sep 24 19:11:42 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23C21B34A8 for ; Thu, 24 Sep 2015 19:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgu-d3RZ6Ruz for ; Thu, 24 Sep 2015 19:11:39 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA83C1B34AB for ; Thu, 24 Sep 2015 19:11:38 -0700 (PDT) Received: by lacrr8 with SMTP id rr8so4381191lac.2 for ; Thu, 24 Sep 2015 19:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GTXfYZO7pjTWv4N9Xl8iEmW+FbPl6ItmnxMEmRgRTqw=; b=NN1Q0iqM6Ya55NYddvaPs/KoEork2t0FkTUNQlNH4iFxUGsKB+Vm80SiFrghnfnQ4k QilMfyElYigVGxMz+ExGbruSNuWug9nzl8Bn6fr6rkTlb3UEEV5BrJx+zJHucncWukB3 fV0D6+RE9RHsWiVT5FJStjhcZrH/rw8GnItb89BMpYz22NkUzbOE/t75tc/gJwOGd1pB LG1R9dpC94SouXdKN7xyT3zl1ZqtNOHf0SNqkcWgKqriFKg/lRr707MqesBrEGK7glB9 YB23xsOyU+vu4aNgkdXhYIVCUiV9gdNvWaShJEAPPJu3qfXKZAegr7XDWAxiAp0Tt9kx rqtQ== MIME-Version: 1.0 X-Received: by 10.25.212.5 with SMTP id l5mr540106lfg.118.1443147096894; Thu, 24 Sep 2015 19:11:36 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.2.163 with HTTP; Thu, 24 Sep 2015 19:11:36 -0700 (PDT) In-Reply-To: <55F0033B.8080408@ericsson.com> References: <55F0033B.8080408@ericsson.com> Date: Thu, 24 Sep 2015 22:11:36 -0400 X-Google-Sender-Auth: 7kMLYM-pDhdEr6fYv9YKDX5sntU Message-ID: From: Phillip Hallam-Baker To: Magnus Westerlund Content-Type: multipart/alternative; boundary=001a1141292211b6ff052088de7d Archived-At: Cc: perc@ietf.org Subject: Re: [Perc] What is happening with the design team for E2E protection in SRTP X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 02:11:42 -0000 --001a1141292211b6ff052088de7d Content-Type: text/plain; charset=UTF-8 On Wed, Sep 9, 2015 at 6:00 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > To my understanding the chairs where going to start up a design team for > discussing and developing a proposal for how the end-to-end protection > should be done in SRTP. > > Considering that it is only slightly more than a month to draft cut-off > and 1,5 months to Yokohama, if we should make any progress prior to that we > need to get started. > > Cheers > > Magnus Westerlund > Is this set in stone or are people willing to consider how to do it differently. There is a technique called proxy re-encryption, or recryption as we are calling it for short. In your normal public key encryption scheme you have an encryption key and a decryption key and that is it. In a Diffie-Hellman scheme, i.e. all the ECC schemes we might use there is a third option. A person with a decryption key can generate a recryption key that allows a third party to take a message encrypted under encryption key X and recrypt it to encryption key Y without ever having the ability to decrypt the message. This has been applied to mailing lists so that messages can be sent to the list under a single encryption key and then remailed to a set of recipients under their encryption key without the remailer having decryption capability. Only the administrator of the list (who knows the decryption key) can add or remove users. And only the administrator needs to know all the members of the list. So think of a mailing list as a security label. If you are a authorized for that label you get to see the traffic, otherwise you do not. In a recryption scheme, a security label is associated with a public encryption key. Anyone who posts documents to that label encrypts them under that key. The administrator of the security label knows the decryption key. Granting read access to the label to a recipient means calculating the recryption key for the recipient's public encryption key and posting it to the service. We can think of a chat room or a video cam room as a security label. Whoever sets up the room gets to decide who can join or not. Those decisions are made on their local machine which is the only place that is vulnerable to a disclosure breach. The service is just a dumb remailer/directory/recryptor. The math is pretty straightforward. If you understand how DH works, recryption is pretty straghtforward. As far as IP goes, Matt Blaze invented the idea 20 years ago before we had so many devices we really needed it. The DH version is ten years old. --001a1141292211b6ff052088de7d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Sep 9, 2015 at 6:00 AM, Magnus Westerlund <= ;magnus= .westerlund@ericsson.com> wrote:
Hi,

To my understanding the chairs where going to start up a design team for di= scussing and developing a proposal for how the end-to-end protection should= be done in SRTP.

Considering that it is only slightly more than a month to draft cut-off and= 1,5 months to Yokohama, if we should make any progress prior to that we ne= ed to get started.

Cheers

Magnus Westerlund

Is this set in stone = or are people willing to consider how to do it differently.=C2=A0

There is a technique called proxy re-encryption, or recrypt= ion as we are calling it for short. In your normal public key encryption sc= heme you have an encryption key and a decryption key and that is it.
<= div>
In a Diffie-Hellman scheme, i.e. all the ECC schemes we = might use there is a third option. A person with a decryption key can gener= ate a recryption key that allows a third party to take a message encrypted = under encryption key X and recrypt it to encryption key Y without ever havi= ng the ability to decrypt the message.


<= div>This has been applied to mailing lists so that messages can be sent to = the list under a single encryption key and then remailed to a set of recipi= ents under their encryption key without the remailer having decryption capa= bility. Only the administrator of the list (who knows the decryption key) c= an add or remove users. And only the administrator needs to know all the me= mbers of the list.

So think of a mailing list as a= security label. If you are a authorized for that label you get to see the = traffic, otherwise you do not.

In a recryption sch= eme, a security label is associated with a public encryption key. Anyone wh= o posts documents to that label encrypts them under that key. The administr= ator of the security label knows the decryption key. Granting read access t= o the label to a recipient means calculating the recryption key for the rec= ipient's public encryption key and posting it to the service.

We can think of a chat room or a video cam room as a securi= ty label. Whoever sets up the room gets to decide who can join or not. Thos= e decisions are made on their local machine which is the only place that is= vulnerable to a disclosure breach. The service is just a dumb remailer/dir= ectory/recryptor.


The math is prett= y straightforward. If you understand how DH works, recryption is pretty str= aghtforward.

As far as IP goes, Matt Blaze invente= d the idea 20 years ago before we had so many devices we really needed it. = The DH version is ten years old.=C2=A0


<= div>

--001a1141292211b6ff052088de7d-- From nobody Mon Sep 28 18:46:47 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626571B2D31 for ; Mon, 28 Sep 2015 18:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSQCCqxF2Lt6 for ; Mon, 28 Sep 2015 18:46:43 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 122DF1B2D2E for ; Mon, 28 Sep 2015 18:46:42 -0700 (PDT) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id t8T1kZYr021122 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Sep 2015 21:46:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1443491195; bh=b5UDlQXVFkBH7g0S3Eiubr6HHZ+jiX9+WtL0LNs8AAA=; h=From:To:Subject:Cc:Date:In-Reply-To:Reply-To; b=Pol/FMcVLpOq1MpAVHOHW6VGhNC9aGC5UgHHQWkFsk4UZ/ei/OUhZ/co+0lo72O77 AC8EO6+fmG+Ai0c8tMyPopQdJOsGKwrajhdT0Z1G1IbGKJtnNQrFICl33UuQtvp6wi Gois0bFEx3/DAqeCoL8v+TDVySDBhfrmqNLFXN90= From: "Paul E. Jones" To: "Phillip Hallam-Baker" , "Magnus Westerlund" Date: Tue, 29 Sep 2015 01:46:42 +0000 Message-Id: In-Reply-To: User-Agent: eM_Client/6.0.23181.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB938F2EC7-4CFE-4F1E-9E69-BEA824EBB2B9" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (dublin.packetizer.com [10.109.150.103]); Mon, 28 Sep 2015 21:46:35 -0400 (EDT) Archived-At: Cc: perc@ietf.org Subject: Re: [Perc] What is happening with the design team for E2E protection in SRTP X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 01:46:45 -0000 --------=_MB938F2EC7-4CFE-4F1E-9E69-BEA824EBB2B9 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Phillip, Noting is set in stone, yet. I have a couple of questions: 1) How large is the ciphertext for these schemes vs. the plaintext? =20 With the symmetric cryptography used on SRTP, the size of the ciphertext= =20 equals the plaintext. 2) I think you're saying a middlebox could receive a message encrypted=20 using key X (that it does not know) and re-encrypt that so that key Y is= =20 used to decrypt. I assume the middlebox is using a public key Y and=20 only the corresponding private key for Y can decrypt it? Paul ------ Original Message ------ From: "Phillip Hallam-Baker" To: "Magnus Westerlund" Cc: perc@ietf.org Sent: 9/24/2015 10:11:36 PM Subject: Re: [Perc] What is happening with the design team for E2E=20 protection in SRTP > > >On Wed, Sep 9, 2015 at 6:00 AM, Magnus Westerlund=20 > wrote: >>Hi, >> >>To my understanding the chairs where going to start up a design team=20 >>for discussing and developing a proposal for how the end-to-end=20 >>protection should be done in SRTP. >> >>Considering that it is only slightly more than a month to draft=20 >>cut-off and 1,5 months to Yokohama, if we should make any progress=20 >>prior to that we need to get started. >> >>Cheers >> >>Magnus Westerlund > >Is this set in stone or are people willing to consider how to do it=20 >differently. > >There is a technique called proxy re-encryption, or recryption as we=20 >are calling it for short. In your normal public key encryption scheme=20 >you have an encryption key and a decryption key and that is it. > >In a Diffie-Hellman scheme, i.e. all the ECC schemes we might use there= =20 >is a third option. A person with a decryption key can generate a=20 >recryption key that allows a third party to take a message encrypted=20 >under encryption key X and recrypt it to encryption key Y without ever=20 >having the ability to decrypt the message. > > >This has been applied to mailing lists so that messages can be sent to=20 >the list under a single encryption key and then remailed to a set of=20 >recipients under their encryption key without the remailer having=20 >decryption capability. Only the administrator of the list (who knows=20 >the decryption key) can add or remove users. And only the administrator= =20 >needs to know all the members of the list. > >So think of a mailing list as a security label. If you are a authorized= =20 >for that label you get to see the traffic, otherwise you do not. > >In a recryption scheme, a security label is associated with a public=20 >encryption key. Anyone who posts documents to that label encrypts them=20 >under that key. The administrator of the security label knows the=20 >decryption key. Granting read access to the label to a recipient means=20 >calculating the recryption key for the recipient's public encryption=20 >key and posting it to the service. > >We can think of a chat room or a video cam room as a security label.=20 >Whoever sets up the room gets to decide who can join or not. Those=20 >decisions are made on their local machine which is the only place that=20 >is vulnerable to a disclosure breach. The service is just a dumb=20 >remailer/directory/recryptor. > > >The math is pretty straightforward. If you understand how DH works,=20 >recryption is pretty straghtforward. > >As far as IP goes, Matt Blaze invented the idea 20 years ago before we=20 >had so many devices we really needed it. The DH version is ten years=20 >old. > > > > --------=_MB938F2EC7-4CFE-4F1E-9E69-BEA824EBB2B9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Phillip,
 
Noting is set in stone, yet.
 
I have a couple of questions:
 
1) How large is the ciphertext for these schemes vs. the plaintext?&nb= sp; With the symmetric cryptography used on SRTP, the size of the ciphertex= t equals the plaintext.
2) I think you're saying a middlebox could receive a message encrypted= using key X (that it does not know) and re-encrypt that so that key Y is= used to decrypt.  I assume the middlebox is using a public key Y and= only the corresponding private key for Y can decrypt it?
 
Paul
 
------ Original Message ------
From: "Phillip Hallam-Baker" <phill@hallambaker.com>
To: "Magnus Westerlund" <magnus.westerlund@ericsson.com>
Sent: 9/24/2015 10:11:36 PM
Subject: Re: [Perc] What is happening with the design team for E2E = protection in SRTP
 


On Wed, Sep 9, 2015 at 6:00 AM, Magnus Westerlund= <magn= us.westerlund@ericsson.com> wrote:
Hi,

To my understanding= the chairs where going to start up a design team for discussing and develo= ping a proposal for how the end-to-end protection should be done in SRTP.
Considering that it is only slightly more than a month to draft cut-o= ff and 1,5 months to Yokohama, if we should make any progress prior to that= we need to get started.

Cheers

Magnus Westerlund

Is this set in stone or are people willing to consider how to do it= differently. 

There is a technique called proxy re-encryption, or recryption as we= are calling it for short. In your normal public key encryption scheme you= have an encryption key and a decryption key and that is it.

In a Diffie-Hellman scheme, i.e. all the ECC schemes we might use ther= e is a third option. A person with a decryption key can generate a recrypti= on key that allows a third party to take a message encrypted under encrypti= on key X and recrypt it to encryption key Y without ever having the ability= to decrypt the message.


This has been applied to mailing lists so that messages can be sent= to the list under a single encryption key and then remailed to a set of= recipients under their encryption key without the remailer having decrypti= on capability. Only the administrator of the list (who knows the decryption= key) can add or remove users. And only the administrator needs to know = all the members of the list.

So think of a mailing list as a security label. If you are a authorize= d for that label you get to see the traffic, otherwise you do not.

In a recryption scheme, a security label is associated with a public= encryption key. Anyone who posts documents to that label encrypts them = under that key. The administrator of the security label knows the decryptio= n key. Granting read access to the label to a recipient means calculating= the recryption key for the recipient's public encryption key and posting= it to the service.

We can think of a chat room or a video cam room as a security label.= Whoever sets up the room gets to decide who can join or not. Those decisio= ns are made on their local machine which is the only place that is vulnerab= le to a disclosure breach. The service is just a dumb remailer/directory/re= cryptor.


The math is pretty straightforward. If you understand how DH works,= recryption is pretty straghtforward.

As far as IP goes, Matt Blaze invented the idea 20 years ago before= we had so many devices we really needed it. The DH version is ten years= old. 




--------=_MB938F2EC7-4CFE-4F1E-9E69-BEA824EBB2B9-- From nobody Mon Sep 28 20:22:51 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E681B2D8E for ; Mon, 28 Sep 2015 20:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMuhnFSD8l0i for ; Mon, 28 Sep 2015 20:22:47 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (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 1C9191B2D98 for ; Mon, 28 Sep 2015 20:22:47 -0700 (PDT) Received: by labzv5 with SMTP id zv5so36723034lab.1 for ; Mon, 28 Sep 2015 20:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=byMeX+aIfAfis7pSYmy+JoYBHZ4enPJa4rMGOx8VI30=; b=q+cJCCRlaWVYrHvNTV42YDPhlbXCKwQsSf1JuzS39iM5EdL6/oS2YhpA/wuSf+mgB+ AW4vp7W4XLDQHFhu3glfYWZHPw9kzzUUZS/yvXltQPfcvUfLZsw3zb5lwSPBi4VRAQou ZD4KfNT1/uLMNEDxG9ZUTuthPKYtGWT3Rjz7HRfo2h4vEeGGaaJyg9S23gYc1DauhCOs hnPHO1SB2Ey5/evozBlEYWS7lZtHmYSLEvtI23aikJU0sVR3FAI5AtCiZJIqZFjDxuLE bZqmKCp9QWSZbpt/Vn5AcAtj9aSrmA1Q7o09XeUHDMcGgfgL2k+ND44KmEtIs36wGER5 AkRw== MIME-Version: 1.0 X-Received: by 10.152.198.201 with SMTP id je9mr1975762lac.79.1443496964708; Mon, 28 Sep 2015 20:22:44 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.2.163 with HTTP; Mon, 28 Sep 2015 20:22:44 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Sep 2015 23:22:44 -0400 X-Google-Sender-Auth: kkgj-E1E2IUqhNe6LEDM63Aw4c4 Message-ID: From: Phillip Hallam-Baker To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=001a11348c04d0e1c10520da537d Archived-At: Cc: Magnus Westerlund , perc@ietf.org Subject: Re: [Perc] What is happening with the design team for E2E protection in SRTP X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 03:22:50 -0000 --001a11348c04d0e1c10520da537d Content-Type: text/plain; charset=UTF-8 On Mon, Sep 28, 2015 at 9:46 PM, Paul E. Jones wrote: > Phillip, > > Noting is set in stone, yet. > > I have a couple of questions: > > 1) How large is the ciphertext for these schemes vs. the plaintext? With > the symmetric cryptography used on SRTP, the size of the ciphertext equals > the plaintext. > Where do the symmetric keys for the session encryption come from? This would only affect the key exchange and then only to a rather small degree. The bulk data would be encrypted under AES as per normal. This is a scheme you would use in place of RSA or DH for setting up the ASE key. Crypto data would be of the order of 56 bytes for the maximum strength keys. In other words, not worth worrying about. One of the nice features of this scheme is that it makes multiparty communication look pretty much like a two party communication from the bandwidth point of view. 2) I think you're saying a middlebox could receive a message encrypted > using key X (that it does not know) and re-encrypt that so that key Y is > used to decrypt. I assume the middlebox is using a public key Y and only > the corresponding private key for Y can decrypt it? > Well what we are doing here is actually setting up a symmetric session key that is used as the key for an AES session. [doing this in straight DH and forgetting the modulo reduction] So lets say that the public key of the group is e^X and the public key of the user is e^Y and the recryption key is R. Note that this public/private key is only used for this particular group and nothing else. Alice wants to set up a session. So she chooses a private key A and sends e^A to the recryptor. The agreed key is e^AX The recryptor knows only R. To add a user to the group, the administrator generates a Y, e^Y for them and calculates the recryption key R = X-Y for that user. The administrator knows all the values of Y. But that is OK because this key will only be used for this particular group and the administrator can read all the messages anyway. Since the recryptor has to save per-user state, we might as well encrypt Y under the public key of each user and send it along with the message. Or we could calculate that as the output of a key agreement on the user's key. So lets say the user's key is U, e^U, the administrator might calculate Y=e^XU The practical upshot of this is that the recryptor can convert the decryption blob for the group to a per user decryption blob but that is all. The recryptor cannot decrypt the message and this is provably a zero knowledge situation. > Paul > > ------ Original Message ------ > From: "Phillip Hallam-Baker" > To: "Magnus Westerlund" > Cc: perc@ietf.org > Sent: 9/24/2015 10:11:36 PM > Subject: Re: [Perc] What is happening with the design team for E2E > protection in SRTP > > > > > On Wed, Sep 9, 2015 at 6:00 AM, Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > >> Hi, >> >> To my understanding the chairs where going to start up a design team for >> discussing and developing a proposal for how the end-to-end protection >> should be done in SRTP. >> >> Considering that it is only slightly more than a month to draft cut-off >> and 1,5 months to Yokohama, if we should make any progress prior to that we >> need to get started. >> >> Cheers >> >> Magnus Westerlund >> > > Is this set in stone or are people willing to consider how to do it > differently. > > There is a technique called proxy re-encryption, or recryption as we are > calling it for short. In your normal public key encryption scheme you have > an encryption key and a decryption key and that is it. > > In a Diffie-Hellman scheme, i.e. all the ECC schemes we might use there is > a third option. A person with a decryption key can generate a recryption > key that allows a third party to take a message encrypted under encryption > key X and recrypt it to encryption key Y without ever having the ability to > decrypt the message. > > > This has been applied to mailing lists so that messages can be sent to the > list under a single encryption key and then remailed to a set of recipients > under their encryption key without the remailer having decryption > capability. Only the administrator of the list (who knows the decryption > key) can add or remove users. And only the administrator needs to know all > the members of the list. > > So think of a mailing list as a security label. If you are a authorized > for that label you get to see the traffic, otherwise you do not. > > In a recryption scheme, a security label is associated with a public > encryption key. Anyone who posts documents to that label encrypts them > under that key. The administrator of the security label knows the > decryption key. Granting read access to the label to a recipient means > calculating the recryption key for the recipient's public encryption key > and posting it to the service. > > We can think of a chat room or a video cam room as a security label. > Whoever sets up the room gets to decide who can join or not. Those > decisions are made on their local machine which is the only place that is > vulnerable to a disclosure breach. The service is just a dumb > remailer/directory/recryptor. > > > The math is pretty straightforward. If you understand how DH works, > recryption is pretty straghtforward. > > As far as IP goes, Matt Blaze invented the idea 20 years ago before we had > so many devices we really needed it. The DH version is ten years old. > > > > > --001a11348c04d0e1c10520da537d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Sep 28, 2015 at 9:46 PM, Paul E. Jones <paulej@packetizer.= com> wrote:
Phillip,
=C2=A0
Noting is set in stone, yet.
=C2=A0
I have a couple of questions:
=C2=A0
1) How large is the ciphertext for these schemes vs. the plaintext?=C2= =A0 With the symmetric cryptography used on SRTP, the size of the ciphertex= t=C2=A0equals the plaintext.

Wh= ere do the symmetric keys for the session encryption come from?
<= br>
This would only affect the key exchange and then only to a ra= ther small degree. The bulk data would be encrypted under AES as per normal= . This is a scheme you would use in place of RSA or DH for setting up the A= SE key.

Crypto data would be of the order of 56 by= tes for the maximum strength keys. In other words, not worth worrying about= . One of the nice features of this scheme is that it makes multiparty commu= nication look pretty much like a two party communication from the bandwidth= point of view.


2) I think you're saying a middlebox could receive a message encry= pted using key X (that it does not know) and re-encrypt that so that key Y = is used to decrypt.=C2=A0 I assume the middlebox is using a public key Y an= d only the corresponding private key for Y can decrypt it?

Well what we are doing here is actually setting up a = symmetric session key that is used as the key for an AES session.

[doing this in straight DH and forgetting the modulo reduct= ion]

So lets say that the public key of the group = is e^X and the public key of the user is e^Y and the recryption key is R.

Note that this public/private key is only used for = this particular group and nothing else.

Alice want= s to set up a session. So she chooses a private key A and sends e^A to the = recryptor. The agreed key is e^AX

The recryptor kn= ows only R.

To add a user to the group, the admini= strator generates a Y, e^Y for them and calculates the recryption key R =3D= X-Y for that user.=C2=A0


The admin= istrator knows all the values of Y. But that is OK because this key will on= ly be used for this particular group and the administrator can read all the= messages anyway.

Since the recryptor has to save = per-user state, we might as well encrypt Y under the public key of each use= r and send it along with the message. Or we could calculate that as the out= put of a key agreement on the user's key.

So l= ets say the user's key is U, e^U, the administrator might calculate Y= =3De^XU


The practical upshot of thi= s is that the recryptor can convert the decryption blob for the group to a = per user decryption blob but that is all. The recryptor cannot decrypt the = message and this is provably a zero knowledge situation.

=C2=A0
Paul
=C2=A0
------ Original Message ------
From: "Phillip Hallam-Baker" <phill@hallambaker.com>
To: "Magnus Westerlund" <magnus.westerlund@ericsson.com><= /div>
Sent: 9/24/2015 10:11:36 PM
Subject: Re: [Perc] What is happening with the design team for E2E pro= tection in SRTP
=C2=A0


On Wed, Sep 9, 2015 at 6:00 AM, Magnus Westerlun= d <magnus.westerlund@ericsson.com> wrote:
Hi,

To my understanding the ch= airs where going to start up a design team for discussing and developing a = proposal for how the end-to-end protection should be done in SRTP.

C= onsidering that it is only slightly more than a month to draft cut-off and = 1,5 months to Yokohama, if we should make any progress prior to that we nee= d to get started.

Cheers

Magnus Westerlund

Is this set in stone or are people willing to consider how to do it di= fferently.=C2=A0

There is a technique called proxy re-encryption, or recryption as we a= re calling it for short. In your normal public key encryption scheme you ha= ve an encryption key and a decryption key and that is it.

In a Diffie-Hellman scheme, i.e. all the ECC schemes we might use ther= e is a third option. A person with a decryption key can generate a recrypti= on key that allows a third party to take a message encrypted under encrypti= on key X and recrypt it to encryption key Y without ever having the ability= to decrypt the message.


This has been applied to mailing lists so that messages can be sent to= the list under a single encryption key and then remailed to a set of recip= ients under their encryption key without the remailer having decryption cap= ability. Only the administrator of the list (who knows the decryption key) = can add or remove users. And only the administrator needs to know all the m= embers of the list.

So think of a mailing list as a security label. If you are a authorize= d for that label you get to see the traffic, otherwise you do not.

In a recryption scheme, a security label is associated with a public e= ncryption key. Anyone who posts documents to that label encrypts them under= that key. The administrator of the security label knows the decryption key= . Granting read access to the label to a recipient means calculating the re= cryption key for the recipient's public encryption key and posting it t= o the service.

We can think of a chat room or a video cam room as a security label. W= hoever sets up the room gets to decide who can join or not. Those decisions= are made on their local machine which is the only place that is vulnerable= to a disclosure breach. The service is just a dumb remailer/directory/recr= yptor.


The math is pretty straightforward. If you understand how DH works, re= cryption is pretty straghtforward.

As far as IP goes, Matt Blaze invented the idea 20 years ago before we= had so many devices we really needed it. The DH version is ten years old.= =C2=A0





--001a11348c04d0e1c10520da537d-- From nobody Mon Sep 28 21:31:37 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9B11B2E02 for ; Mon, 28 Sep 2015 21:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 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, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKSQFXpoHPVN for ; Mon, 28 Sep 2015 21:31:33 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC3AC1B2E01 for ; Mon, 28 Sep 2015 21:31:33 -0700 (PDT) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id t8T4VRvf001535 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Sep 2015 00:31:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1443501088; bh=FhZKILo67xuhahKKBLemq9HuhRjGqs3cvcRJ1Ip+h9U=; h=From:To:Subject:Cc:Date:In-Reply-To:Reply-To; b=kGYTXOzQzkckNrWP5weapFtsQW8q5MKtcdFDxkEffUtgLSmffiRNAoyCNHPJE0RU4 496HO1I8UKhROi6s89etK85e3Uk/YnlIni+fWJNZri5yanseYDd03i3G+0CGpZ7cto xfwcDxg2pQXqc/r4/KZNgc+yuWVBskYZnHFFP/ZE= From: "Paul E. Jones" To: "Phillip Hallam-Baker" Date: Tue, 29 Sep 2015 04:31:34 +0000 Message-Id: In-Reply-To: User-Agent: eM_Client/6.0.23181.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB5A2D4FB8-E5BE-48D2-A31A-EC0822873649" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (dublin.packetizer.com [10.109.150.103]); Tue, 29 Sep 2015 00:31:28 -0400 (EDT) Archived-At: Cc: Magnus Westerlund , perc@ietf.org Subject: Re: [Perc] What is happening with the design team for E2E protection in SRTP X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 04:31:36 -0000 --------=_MB5A2D4FB8-E5BE-48D2-A31A-EC0822873649 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Phillip, >>1) How large is the ciphertext for these schemes vs. the plaintext? =20 >>With the symmetric cryptography used on SRTP, the size of the=20 >>ciphertext equals the plaintext. > >Where do the symmetric keys for the session encryption come from? In today's deployment, they either come from session signaling over the=20 wire (transitive trust model) or from DTLS-SRTP exchanges (but the=20 fingerprints for DTLS connections are still often exchanged in=20 signaling). There are exceptions, but I think that's the most popular=20 models. For perc and newer systems in general, increased focus on security is=20 going to force changes. Using trusted third parties to verify=20 signatures, etc., is likely, but nothing is specified for perc thus far. >This would only affect the key exchange and then only to a rather small= =20 >degree. The bulk data would be encrypted under AES as per normal. This=20 >is a scheme you would use in place of RSA or DH for setting up the ASE=20 >key. Initial key exchange is not a big deal -- regardless of what we do. And= =20 if we develop a mechanism for efficiently re-keying the conference, then= =20 all the better. What's most important is the size of the data packets=20 on the wire. If the scheme allows for comparably-efficient ciphertext=20 steeams, then that's good. >Crypto data would be of the order of 56 bytes for the maximum strength=20 >keys. In other words, not worth worrying about. One of the nice=20 >features of this scheme is that it makes multiparty communication look=20 >pretty much like a two party communication from the bandwidth point of=20 >view. And that's important. >>2) I think you're saying a middlebox could receive a message encrypted= =20 >>using key X (that it does not know) and re-encrypt that so that key Y=20 >>is used to decrypt. I assume the middlebox is using a public key Y=20 >>and only the corresponding private key for Y can decrypt it? > >Well what we are doing here is actually setting up a symmetric session=20 >key that is used as the key for an AES session. > >[doing this in straight DH and forgetting the modulo reduction] > >So lets say that the public key of the group is e^X and the public key=20 >of the user is e^Y and the recryption key is R. > >Note that this public/private key is only used for this particular=20 >group and nothing else. > >Alice wants to set up a session. So she chooses a private key A and=20 >sends e^A to the recryptor. The agreed key is e^AX > >The recryptor knows only R. > >To add a user to the group, the administrator generates a Y, e^Y for=20 >them and calculates the recryption key R =3D X-Y for that user. > > >The administrator knows all the values of Y. But that is OK because=20 >this key will only be used for this particular group and the=20 >administrator can read all the messages anyway. > >Since the recryptor has to save per-user state, we might as well=20 >encrypt Y under the public key of each user and send it along with the=20 >message. Or we could calculate that as the output of a key agreement on= =20 >the user's key. > >So lets say the user's key is U, e^U, the administrator might calculate= =20 >Y=3De^XU > > >The practical upshot of this is that the recryptor can convert the=20 >decryption blob for the group to a per user decryption blob but that is= =20 >all. The recryptor cannot decrypt the message and this is provably a=20 >zero knowledge situation. OK, I get the gist of what you're suggesting, but I need a more complete= =20 write-up to get it clear in my head. Do you have suggestions for=20 reading? What should be clear to me, though, and isn't is "why". I think I=20 understand that each participant in the conference has a distinct key=20 and there is a separate key used by the recryptor. So, with two=20 encryption steps a media flow arrives at an endpoint and it can decrypt=20 it. By why use two encryption steps? I'm missing the security benefit=20 of that vs. all members of the conference using the same symmetric key=20 and the conference server taking no action on the E2E encrypted part of=20 the packet. Does this help with "revoking" a key from a user? Does it make it more=20 efficient to distribute keys to new users? Does it address issues where= =20 a person joins late and is given a key, but can (if they had the data=20 packets) decrypt previously-transmitted media? (Protecting the=20 confidentiality of the conference as users come and leave is important=20 considerations; I should not be able to decrypt packets after I leave or= =20 that were sent before I join.) Paul --------=_MB5A2D4FB8-E5BE-48D2-A31A-EC0822873649 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Phillip,
 
 
1) How large is the ciphertext for these schemes vs. the plaintext?&nb= sp; With the symmetric cryptography used on SRTP, the size of the ciphertex= t equals the plaintext.

Where do the symmetric keys for the session encryption come from?
 
In today's deployment, they either come from session signaling over= the wire (transitive trust model) or from DTLS-SRTP exchanges (but the = fingerprints for DTLS connections are still often exchanged in signaling).&= nbsp; There are exceptions, but I think that's the most popular models.
 
For perc and newer systems in general, increased focus on security = is going to force changes.  Using trusted third parties to verify sign= atures, etc., is likely, but nothing is specified for perc thus far.
 
 
This would only affect the key exchange and then only to a rather smal= l degree. The bulk data would be encrypted under AES as per normal. This= is a scheme you would use in place of RSA or DH for setting up the ASE = key.
 
Initial key exchange is not a big deal -- regardless of what we do.&nb= sp; And if we develop a mechanism for efficiently re-keying the conference,= then all the better.  What's most important is the size of the data= packets on the wire.  If the scheme allows for comparably-efficient= ciphertext steeams, then that's good.
 
Crypto data would be of the order of 56 bytes for the maximum strength= keys. In other words, not worth worrying about. One of the nice features= of this scheme is that it makes multiparty communication look pretty much= like a two party communication from the bandwidth point of view.
 
And that's important.
 
2) I think you're saying a middlebox could receive a message encrypted= using key X (that it does not know) and re-encrypt that so that key Y is= used to decrypt.  I assume the middlebox is using a public key Y and= only the corresponding private key for Y can decrypt it?

Well what we are doing here is actually setting up a symmetric session= key that is used as the key for an AES session.

[doing this in straight DH and forgetting the modulo reduction]

So lets say that the public key of the group is e^X and the public = key of the user is e^Y and the recryption key is R.

Note that this public/private key is only used for this particular = group and nothing else.

Alice wants to set up a session. So she chooses a private key A and= sends e^A to the recryptor. The agreed key is e^AX

The recryptor knows only R.

To add a user to the group, the administrator generates a Y, e^Y for= them and calculates the recryption key R =3D X-Y for that user. 


The administrator knows all the values of Y. But that is OK because= this key will only be used for this particular group and the administrator= can read all the messages anyway.

Since the recryptor has to save per-user state, we might as well encry= pt Y under the public key of each user and send it along with the message.= Or we could calculate that as the output of a key agreement on the user's= key.

So lets say the user's key is U, e^U, the administrator might calculat= e Y=3De^XU


The practical upshot of this is that the recryptor can convert the = decryption blob for the group to a per user decryption blob but that is = all. The recryptor cannot decrypt the message and this is provably a zero= knowledge situation.
 
OK, I get the gist of what you're suggesting, but I need a more= complete write-up to get it clear in my head.  Do you have suggestion= s for reading?
 
What should be clear to me, though, and isn't is "why".  I t= hink I understand that each participant in the conference has a distin= ct key and there is a separate key used by the recryptor.  So, with= two encryption steps a media flow arrives at an endpoint and it can decryp= t it.  By why use two encryption steps?  I'm missing the security= benefit of that vs. all members of the conference using the same symmetric= key and the conference server taking no action on the E2E encrypted part= of the packet.
 
Does this help with "revoking" a key from a user?  Does it make= it more efficient to distribute keys to new users?  Does it address= issues where a person joins late and is given a key, but can (if they had= the data packets) decrypt previously-transmitted media?  (Protecting= the confidentiality of the conference as users come and leave is important= considerations; I should not be able to decrypt packets after I leave or= that were sent before I join.)
 
Paul
 
--------=_MB5A2D4FB8-E5BE-48D2-A31A-EC0822873649-- From nobody Tue Sep 29 05:23:59 2015 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2A41B31EA for ; Tue, 29 Sep 2015 05:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UZxPmuzIkVz for ; Tue, 29 Sep 2015 05:23:55 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (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 4FDD21B31E5 for ; Tue, 29 Sep 2015 05:23:55 -0700 (PDT) Received: by laclj5 with SMTP id lj5so6154037lac.3 for ; Tue, 29 Sep 2015 05:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=fN8F0/8vAdgsN4QH12hMKwzBR+krgp+LeepKO5Spo7s=; b=MtOfqg31gcJOIPAVta59z5CmUGQ0CNTIZJ1/t6tNFRB3SBqwdDTyL/UlIYG05wxyD2 WivPM7LBuSizUvV0izjyTNJKlrqJU3YaXAUEU96MOe8cpjSZwvOflhnGqGFDES0uqTpx 9LXDIQJcFGDMQAS7qKTeYPOpmLOAVuSWSk7D/xuiGgFsVN/PwGPnva1epC59eeYjaLzF IIWcODGYUwYeDCSYxojyEF7pzvdlKBq7pTKfOx4ujkMjlknY4qrWZmszLpo8kh8Lzgqz f+44MPG7zvc+1aTGA1CtPIkWI1ARi7FyMQzRgCYtsvQoHKRdFUSdwBMJUpVjQn9BVxrA E8+g== MIME-Version: 1.0 X-Received: by 10.152.4.130 with SMTP id k2mr7292115lak.103.1443529433344; Tue, 29 Sep 2015 05:23:53 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.2.163 with HTTP; Tue, 29 Sep 2015 05:23:53 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Sep 2015 08:23:53 -0400 X-Google-Sender-Auth: Phb0nxv1n0qs9QaQjJGffIxnYus Message-ID: From: Phillip Hallam-Baker To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=089e0141a18018f5220520e1e318 Archived-At: Cc: Magnus Westerlund , perc@ietf.org Subject: Re: [Perc] What is happening with the design team for E2E protection in SRTP X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 12:23:58 -0000 --089e0141a18018f5220520e1e318 Content-Type: text/plain; charset=UTF-8 On Tue, Sep 29, 2015 at 12:31 AM, Paul E. Jones wrote: > Phillip, > ... > > What should be clear to me, though, and isn't is "why". I think I > understand that each participant in the conference has a distinct key and > there is a separate key used by the recryptor. So, with two encryption > steps a media flow arrives at an endpoint and it can decrypt it. By why > use two encryption steps? I'm missing the security benefit of that vs. all > members of the conference using the same symmetric key and the conference > server taking no action on the E2E encrypted part of the packet. > > Does this help with "revoking" a key from a user? Does it make it more > efficient to distribute keys to new users? Does it address issues where a > person joins late and is given a key, but can (if they had the data > packets) decrypt previously-transmitted media? (Protecting the > confidentiality of the conference as users come and leave is important > considerations; I should not be able to decrypt packets after I leave or > that were sent before I join.) > The point of doing two encryption steps instead of one is to shrink the security perimeter and reduce the trust in the cloud service that does session setup. I am concerned with hardening systems to make them 'PRISM-proof' and 'Snowden-proof'. We all know about the problem of pervasive surveillance but the risk of system administrator malfeasance is equally important. Particularly if the contact service is going to be hosted by a third party. This approach gives end to end security. The contact service can add or remove members from the conference but can only add them from the list created by the group administrator. In this respect, the contact service is untrusted. It cannot ever get access to the content. If you want to support revocation however, the contact service becomes trusted to enforce the revocation but not performing recryption for the revoked party. So this is a trusted-untrusted service. The cloud service is trusted to provide security refinements but a breach of the contact service does not cause disclosure of content. If you want to change either the composition of the group or change the administrator, you will need to perform a rekey of the group. But that need not cause any sort of interruption in service. Just keep the old keys running until the rekey event is complete. As for further documentation, there isn't very much at all. You can look up 'Proxy Re-Encryption' on wikipedia and there is a link to a bibliography of a half dozen papers. This is not a technique I invented, Matt Blaze did that 20 odd years ago. But nobody seems to have done anything with it since or realized the true potential. This should be a basic building block for crypto protocols. It is how you make any two party communication into a multiparty communication. --089e0141a18018f5220520e1e318 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Sep 29, 2015 at 12:31 AM, Paul E. Jones <<= a href=3D"mailto:paulej@packetizer.com" target=3D"_blank">paulej@packetizer= .com> wrote:
Phillip,
...=C2=A0
=C2=A0
What should be clear to me, though, and isn't is "why".= =C2=A0 I=C2=A0think I understand=C2=A0that each participant in the conferen= ce has a distinct key and there is a separate key used by the recryptor.=C2= =A0 So, with two encryption steps a media flow arrives at an endpoint and i= t can decrypt it.=C2=A0 By why use two encryption steps?=C2=A0 I'm miss= ing the security benefit of that vs. all members of the conference using th= e same symmetric key and the conference server taking no action on the E2E = encrypted part of the packet.
=C2=A0
Does this help with "revoking" a key from a user?=C2=A0 Does= it make it more efficient to distribute keys to new users?=C2=A0 Does it a= ddress issues where a person joins late and is given a key, but can (if the= y had the data packets) decrypt previously-transmitted media?=C2=A0 (Protec= ting the confidentiality of the conference as users come and leave is impor= tant considerations; I should not be able to decrypt packets after I leave = or that were sent before I join.)

The point of doing two encryption steps instead of one is to shrin= k the security perimeter and reduce the trust in the cloud service that doe= s session setup.

I am concerned with hardening sys= tems to make them 'PRISM-proof' and 'Snowden-proof'. We all= know about the problem of pervasive surveillance but the risk of system ad= ministrator malfeasance is equally important. Particularly if the contact s= ervice is going to be hosted by a third party.

Thi= s approach gives end to end security. The contact service can add or remove= members from the conference but can only add them from the list created by= the group administrator.

In this respect, the con= tact service is untrusted. It cannot ever get access to the content.
<= div>

If you want to support revocation however= , the contact service becomes trusted to enforce the revocation but not per= forming recryption for the revoked party. So this is a trusted-untrusted se= rvice. The cloud service is trusted to provide security refinements but a b= reach of the contact service does not cause disclosure of content.

If you want to change either the composition of the group = or change the administrator, you will need to perform a rekey of the group.= But that need not cause any sort of interruption in service. Just keep the= old keys running until the rekey event is complete.


As for further documentation, there isn't very much a= t all. You can look up 'Proxy Re-Encryption' on wikipedia and there= is a link to a bibliography of a half dozen papers. This is not a techniqu= e I invented, Matt Blaze did that 20 odd years ago. But nobody seems to hav= e done anything with it since or realized the true potential.
This should be a basic building block for crypto protocols. It = is how you make any two party communication into a multiparty communication= .


--089e0141a18018f5220520e1e318--