From nobody Mon Mar 5 08:36:14 2018 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E3B12D94A; Mon, 5 Mar 2018 08:36:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152026777190.14664.14205046869444483604@ietfa.amsl.com> Date: Mon, 05 Mar 2018 08:36:11 -0800 Archived-At: Subject: [Perc] I-D Action: draft-ietf-perc-srtp-ekt-diet-07.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 16:36:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Privacy Enhanced RTP Conferencing WG of the IETF. Title : Encrypted Key Transport for DTLS and Secure RTP Authors : Cullen Jennings John Mattsson David A. McGrew Dan Wing Flemming Andreason Filename : draft-ietf-perc-srtp-ekt-diet-07.txt Pages : 24 Date : 2018-03-05 Abstract: Encrypted Key Transport (EKT) is an extension to DTLS and Secure Real-time Transport Protocol (SRTP) that provides for the secure transport of SRTP master keys, rollover counters, and other information within SRTP. This facility enables SRTP for decentralized conferences by distributing a common key to all of the conference endpoints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-perc-srtp-ekt-diet-07 https://datatracker.ietf.org/doc/html/draft-ietf-perc-srtp-ekt-diet-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-srtp-ekt-diet-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 5 08:36:40 2018 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FD212D96C; Mon, 5 Mar 2018 08:36:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152026777794.14652.5724880215858557853@ietfa.amsl.com> Date: Mon, 05 Mar 2018 08:36:17 -0800 Archived-At: Subject: [Perc] I-D Action: draft-ietf-perc-double-08.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 16:36:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Privacy Enhanced RTP Conferencing WG of the IETF. Title : SRTP Double Encryption Procedures Authors : Cullen Jennings Paul E. Jones Richard Barnes Adam Roach Filename : draft-ietf-perc-double-08.txt Pages : 17 Date : 2018-03-05 Abstract: In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some RTP parameters, while still providing strong end-to-end security guarantees. This document defines SRTP procedures that use two separate but related cryptographic operations to provide hop-by-hop and end-to-end security guarantees. Both the end-to-end and hop-by-hop cryptographic algorithms can utilize an authenticated encryption with associated data scheme or take advantage of future SRTP transforms with different properties. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-perc-double/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-perc-double-08 https://datatracker.ietf.org/doc/html/draft-ietf-perc-double-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-double-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 5 12:42:49 2018 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF48B12E8AE; Mon, 5 Mar 2018 12:42:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152028255793.31686.1111304896659432242@ietfa.amsl.com> Date: Mon, 05 Mar 2018 12:42:37 -0800 Archived-At: Subject: [Perc] I-D Action: draft-ietf-perc-private-media-framework-06.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 20:42:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Privacy Enhanced RTP Conferencing WG of the IETF. Title : A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing Authors : Paul E. Jones David Benham Christian Groves Filename : draft-ietf-perc-private-media-framework-06.txt Pages : 24 Date : 2018-03-05 Abstract: This document describes a solution framework for ensuring that media confidentiality and integrity are maintained end-to-end within the context of a switched conferencing environment where media distributors are not trusted with the end-to-end media encryption keys. The solution aims to build upon existing security mechanisms defined for the real-time transport protocol (RTP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-perc-private-media-framework-06 https://datatracker.ietf.org/doc/html/draft-ietf-perc-private-media-framework-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-private-media-framework-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 6 16:43:56 2018 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 7DFE9126FB3 for ; Tue, 6 Mar 2018 16:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-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 O-Ld5bn7GTQi for ; Tue, 6 Mar 2018 16:43:54 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::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 061161200FC for ; Tue, 6 Mar 2018 16:43:54 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id f6so334034vkh.6 for ; Tue, 06 Mar 2018 16:43:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=iPj4DhIANRNjz0lVk7sJa4LbbHpyMwZkJfsu0LF2YRE=; b=Vv3qjgxs/0KTMOJchRRHZ4VkdQmiVclXR0ic9mwTVOxcmRdPEjQXPXcYpsWC4OenAi KXbEUDCps8IA+VRy0aWVzolauRh4csBWLyxxmK41eBp/iPvOj2lDMEdg3SAeDenA7YVT rm8zsCZB/FrFCnQhQ11wEboWa6adoJtu8p6ZwDxSJB8beuIJSDRJXGJOrw025PdrpmlN ZtFODNbrPh/6prqbkhraJELUBnMFu9VssNt6w+kgfZDrlrUY0SUqLf2e+i1CFGiKQiP6 l+0iz7ZH6HR2h9RyL8umUnXL2WNor6OhEnemIU/4cpe57wuahhz2H5VQwJIg9PFjnIPD wsug== 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=iPj4DhIANRNjz0lVk7sJa4LbbHpyMwZkJfsu0LF2YRE=; b=UF+QTMH58rh0tyLSYy5iKeCv74pVXJacEflLlokaJtYMJsZKAt96U2/zQplPSihOPU jG6hRB650TorNjb2/p0/QOpeD0jqIPzCUOsY3NHwiLsGuvFUdVcdgj/7KR6ABzx/b9uf HOe7Fvg22Jv2gMJgZlTokLH5Y6AmPeZbquHTLAOVjANo2y/liFjzMT/BmqrXc51XASI/ +a9bajnJUkrJghTzNHmmO4TcxE0sduR3O1CpgGlDR+rYK2dbcgPEk7v+STBtW2S9Huwi CE+vbUazAb+gHhJCYpIKY5RDxdesCpIsUgUiNkqa2bKL+CULMvbrrF0jrD/jB+EYRQJY NCHA== X-Gm-Message-State: APf1xPBHPAhMh3U1ImyzhfYatIdrhutpQtL3iuko71QqvD2QQe41BbIQ yW+jJW7GLPCgdog8Cls5tVA8UqeN2j1p40ceoiovSA== X-Google-Smtp-Source: AG47ELswdpkvTbGQxZ104MzM9Ctg91loLBvKg1hsdsbJOoNIIols6zDAxEw9MYIxaaNLJYzyYaSbyT6t7XDXdXIBxo0= X-Received: by 10.31.59.139 with SMTP id i133mr14441696vka.4.1520383432885; Tue, 06 Mar 2018 16:43:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.84.146 with HTTP; Tue, 6 Mar 2018 16:43:52 -0800 (PST) From: Suhas Nandakumar Date: Tue, 6 Mar 2018 16:43:52 -0800 Message-ID: To: perc@ietf.org Content-Type: multipart/alternative; boundary="001a1142f994708bbe0566c7da0d" Archived-At: Subject: [Perc] WGLC: draft-ietf-perc-srtp-ekt-diet-07 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 00:43:55 -0000 --001a1142f994708bbe0566c7da0d Content-Type: text/plain; charset="UTF-8" All, This is a working group last call announcement for draft-ietf-perc-srtp-ekt-diet-07 to run through March 18. Please send your reviews to the list as soon as possible so we can prepare for any discussion of open issues at IETF 101 in London. Thanks nils & suhas --001a1142f994708bbe0566c7da0d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
All,
This is a working group last call announcement for draft-i=
etf-perc-srtp-ekt-diet-07 to run through March 18.  Please send your r=
eviews to the list as soon as possible so we can prepare for any discussion=
 of open issues at IETF 101 in London.

Thanks
nils & suhas
--001a1142f994708bbe0566c7da0d-- From nobody Tue Mar 6 16:45:57 2018 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 5CE561200FC for ; Tue, 6 Mar 2018 16:45:56 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 9kMLitx5S7H5 for ; Tue, 6 Mar 2018 16:45:55 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::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 292DE1200C5 for ; Tue, 6 Mar 2018 16:45:55 -0800 (PST) Received: by mail-vk0-x22d.google.com with SMTP id y127so333834vky.9 for ; Tue, 06 Mar 2018 16:45:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=u+/3w/SSUYNGK3raPvVsqtXEgSS7PdYQRiQ2afw8uQc=; b=mOD930iT+yGebK0AfDXlO1lwwd5Z+t3dbQww8ecR7t4AHoTRCPbq4A1qJb09Vledzf 0/ZGOBQqfOyp8STO6FKNW0urKlfvcteCPcheI9zpNx1zeTKD5OaFlW4e876PsKUgutRg gxUUUu164V1hEfTdNN38ztVragO/Ws1RnrPGGeurB+ktKIhxeNIp/H/M6GcATuEhD532 oYJskv/Hqc2MouQ1VAkYigxs4BMwdYoaVwKgiUstRXzlIBuD/D3C5NmBao7kloNWFMmk ix+/t+9u3tqHCpIh7cQ4lxg0sdsJmok/v/GAHoeJiU4nCnQwR9D15TE+lsZVp1vi1Cfq FytA== 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=u+/3w/SSUYNGK3raPvVsqtXEgSS7PdYQRiQ2afw8uQc=; b=p2yjs5v+3LP2jIQ5kHfBBJsDW9DY+aFonryBRlpnzqVOjqpnPNTEiDyYkOp9hGPiMI QTiVpPnnGz5RrnqYQ0awxhK3mwKBtj5cPLJ8uZ8KotByry2VbMZmyQ3O7xrwHI3/ORm3 ynTH0PkDK6hjp3OjL66fFtyuhcTeXmH6znvAr0zJ61L8D1E/ognnaxp6yXzJws9s2aoD JDfatk+Eh1vWQ62LQjCd8Ur1vfqHIXvd5AlHFyXU/LpY6aPna5Hlvqm4yVkMAL9I+943 0JSBez034JqL+KvLY4LLi2x+quCTULTxNxoPHL4UdO/FEmQQJ32GAn4LKOzRI7D6a8ev eSfQ== X-Gm-Message-State: APf1xPAdV87hUlQo8tmgWewwxBY49wsDlaDu4yGRK0sN3RZQ7Afzbh3A cHOYDhvnSxFy/LWG5xGcqLgFu0TZpXjbfEWbVSu1Tw== X-Google-Smtp-Source: AG47ELvQLezmb0Zgxhjf0FtjaYNJa83Hpe6iikFChpB926s9aVWHyI70fhleVOfZu4IMgK5Jc+zNc8FMD32WZU+inVg= X-Received: by 10.31.59.139 with SMTP id i133mr14444398vka.4.1520383554004; Tue, 06 Mar 2018 16:45:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.84.146 with HTTP; Tue, 6 Mar 2018 16:45:53 -0800 (PST) From: Suhas Nandakumar Date: Tue, 6 Mar 2018 16:45:53 -0800 Message-ID: To: perc@ietf.org Content-Type: multipart/alternative; boundary="001a1142f994a8ad370566c7e153" Archived-At: Subject: [Perc] WGLC: draft-ietf-perc-double-08 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 00:45:56 -0000 --001a1142f994a8ad370566c7e153 Content-Type: text/plain; charset="UTF-8" All, This is a working group last call announcement for draft-ietf-perc-double-08 to run through March 18. Please send your reviews to the list as soon as possible so we can prepare for any discussion of open issues at IETF 101 in London. Thanks nils & suhas --001a1142f994a8ad370566c7e153 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
All,
This is a working group last call announcement for draft-i=
etf-perc-double-08 to run through March 18.  Please send your reviews to th=
e list as soon as possible so we can prepare for any discussion of open iss=
ues at IETF 101 in London.

Thanks
nils & suhas

--001a1142f994a8ad370566c7e153-- From nobody Tue Mar 6 16:47:28 2018 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 341CE1200FC for ; Tue, 6 Mar 2018 16:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-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 UCB96LUUqOY5 for ; Tue, 6 Mar 2018 16:47:25 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 BB6381200C5 for ; Tue, 6 Mar 2018 16:47:25 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id x4so336868uaj.11 for ; Tue, 06 Mar 2018 16:47:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=tFCEzXPVM/jIoaxzFX8Iu6I2ssTbonMLUNUuMb2/jDQ=; b=rKennykg6JvsxukpI/VHLXT5nTrfFZzjPIddcVGOyoo2tV55OZyMx+PhlNOEDy51w0 TlUW4CI51G7wdc5SkNgnjabLyPILb5LktJAnQFQAXhNmm/HihTXa49DoSl72YeSO/Y68 /heMzztIoTSO20aVsL0BUqdm1+gFMu+7MIo0p6Rals8yWpQD/BgBO5B2/gpxV2PMn7bK 4oIDEKpyBwT+JJn0qOW9XqsSq7CUyDetcexw3oK4KjaWDK41MXY0t1xywDzEm5k/f+17 6GDvmhKsuWNW5lJhgq7PY100cjyKcUkwDmklsk2eJFAbSlYFQHIsmc4PWMZHTGJiRz2q Kddw== 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=tFCEzXPVM/jIoaxzFX8Iu6I2ssTbonMLUNUuMb2/jDQ=; b=J/uRNC75FXLyvLBLvKut6T9X4BSCJlXwp0yF1nbApMnP5q55N1/HxRwHr5gydm0Dl7 XcOb+d5iScmGfOZMcfVvUwc27oqeS2sP7MowmoCaAazH8Hzia4xjC8HJDAIhtVIPpjC2 1nuE4U6aZ6JdVBxtMBczXB72xEZS+rhVy1b1pYfryo0e8/fHwnMQhpdXLpmNyCsCixWs Wk265fynNqI9W0ujHJDRGMi+ae/ANnKuCCDoRNDgA5D1faQ+bMtQFv99baq01SqOcd8W W1z5kVdduMVRPsM4WKktJpb88hkwynjx/4SdMgMgUi2YYnVxZ2RVEv/pSmHnh2hH2KDb OzDw== X-Gm-Message-State: APf1xPCnrq1V3P49n0YvNK+bpv7gaSHLOki86Z20NPqYQC/Fn5Wl7cdm FMI6wB30BMlgSxzqCleoz4AQpcbgYG20dymHRaAVlg== X-Google-Smtp-Source: AG47ELszvuA94ypdlkWLttrpJofyojoOJNb/UnJC4tH3TX4aGhnu6czIPwscVAl+D1ZMQm9/P5S/2nVpLFqxhqZjuRI= X-Received: by 10.176.95.158 with SMTP id b30mr15133984uaj.10.1520383644700; Tue, 06 Mar 2018 16:47:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.84.146 with HTTP; Tue, 6 Mar 2018 16:47:24 -0800 (PST) From: Suhas Nandakumar Date: Tue, 6 Mar 2018 16:47:24 -0800 Message-ID: To: perc@ietf.org Content-Type: multipart/alternative; boundary="f403043e9c9c10949d0566c7e72b" Archived-At: Subject: [Perc] WGLC: draft-ietf-perc-private-media-framework-06 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 00:47:27 -0000 --f403043e9c9c10949d0566c7e72b Content-Type: text/plain; charset="UTF-8" All, This is a working group last call announcement for draft-ietf-perc-private-media-framework-06 to run through March 18. Please send your reviews to the list as soon as possible so we can prepare for any discussion of open issues at IETF 101 in London. Thanks nils & suhas --f403043e9c9c10949d0566c7e72b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
All,
Th=
is is a working group last call announcement for draft-ietf-perc-private-me=
dia-framework-06 to run through March 18.  Please send your reviews to the =
list as soon as possible so we can prepare for any discussion of open issue=
s at IETF 101 in London.

Thanks
nils & suhas
--f403043e9c9c10949d0566c7e72b-- From nobody Fri Mar 16 04:59:31 2018 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 101A112E894 for ; Fri, 16 Mar 2018 04:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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=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 m9-LfOdNpxqR for ; Fri, 16 Mar 2018 04:59:25 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 574DD12E897 for ; Fri, 16 Mar 2018 04:59:22 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id g13-v6so3986202lfe.10 for ; Fri, 16 Mar 2018 04:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=g17baGRRNZym3X9YAzU7PzkVZDAJ+qyHOOsjvNm6QF4=; b=ZU7H1+qr9aBiRNtdGiFgkDDTAKPIY4T7q5hSN15FrqHUCI2G9E93ClvgPI2voHVnZ5 sbwxLCOXGZTryEr5jEhv53pKqb+rV0O1LrJfiNU4+nNNrFKiiFW2r1Ane3NoV/I18Kz7 Q3Rz27VO6dp5mDwkqVUF2w1mz1/BXfxsKZYTLBLQ1BVMhcSrzBrLoFhxPbOwIqHi+Nyy D50Fblt7yay/dzgtYzZW8Ks4iKeN5jQDfhcc4xaTASW4TFf9XSlZqklx4fspdJOVECum 7lrTPpDQq+TIJZcJCuzTxG2NzuLFBYRK3JWc7irNHZaEM3QP/QwNeq7e9+Z9rxfUA0nT Ke+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=g17baGRRNZym3X9YAzU7PzkVZDAJ+qyHOOsjvNm6QF4=; b=BFyc1xjNOONKTKVzvWuVQKy62EHJA1YPN9cUpztO3frXq+ALvBMKc3+sCqpjzUGLfe P1BP/0HiQo8ayARml3F8ji6Etk+sJjWi/9P/FbeQ1yESVC/W5dqm9SraW1FLRPNKi2eR 1nbPj1M3DXc96r1Wg2YtT1/OIZZWM+osxGtMz+3aSUwhIpgYVb2v1SXi8VNW4IlU8pYR 3lOebO3pVIuD43HrnBdK3ZIol7BFmJPXu7jzmBKTnbDX1TVl+dgnQBvm7X3lfeVAbbbu PzRQz6EKi71DUEVgKUY5uZFqfRGCV37fcl3Tt/7wCs8abR3ZOUnAEbgURnkXheWEiYDe sDjA== X-Gm-Message-State: AElRT7H5pG8IdSXt+MXrDsAiffgtYrHmDNE6KIokjW6f8YXRKsbIIBwq GZpnOlqBjc1TY5T68vhcxcDQtXrX X-Google-Smtp-Source: AG47ELtSG9YTLWpGmbDSj/mXnXGqckT+J0vRe+hOoV40Ak9KAzkG06wqR82t53dt6M5xhEtCklUcZw== X-Received: by 2002:a19:9d93:: with SMTP id g141-v6mr1141065lfe.142.1521201560256; Fri, 16 Mar 2018 04:59:20 -0700 (PDT) Received: from Alfreds-MacBook-Pro-2.local (cm-84.208.113.129.getinternet.no. [84.208.113.129]) by smtp.gmail.com with ESMTPSA id l5sm1568800lje.58.2018.03.16.04.59.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Mar 2018 04:59:19 -0700 (PDT) From: "Alfred E. Heggestad" To: perc@ietf.org Message-ID: <861e4bab-9058-bb0c-fa77-fb313f1f1ec5@gmail.com> Date: Fri, 16 Mar 2018 12:59:18 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Perc] Security hole in draft-ietf-perc-double-08? X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 11:59:29 -0000 Hi, I have some questions about this document: https://tools.ietf.org/html/draft-ietf-perc-double-08 I am currently implementing the Double SRTP encryption part of PERC. in my testcode I used by accident the same master key for both the inner and outer transform. Then I discovered that the doubly encrypted payload was EXACTLY THE SAME as the plaintext payload (!). is this how SRTP works, that encrypting it twice with the same key gives back the original result ? I have made a test program to demonstrate it: https://gist.github.com/alfredh/792759cccdd88d058bfd4a2a2d689922 running the program: $ ./test RTP packet: [20 bytes] 80080001000000a05c5c5c5c0102030405060708 1xSRTP packet: [36 bytes] 80080001000000a05c5c5c5c3b9c8bcd40a81c1f8946fd4b272f2aef98c50c18348ae92e 2xSRTP packet: [53 bytes] 80080001000000a05c5c5c5c010203040506070865caa1e8cd9386bbc0e5cf5b1a3c5271eef5f5d6e444f15ff6bc5cdb4cf68859f3 ^^^^^^^^^^^^^^^^ program terminated successfully. the first line shows the original plaintext RTP packet (payload is 8 bytes 01..08) the 3rd line prefixed with "2xSRTP" packet shows the SRTP packet that will be transmitted on the wire. It also shows the plaintext RTP packet (!) again, note that exactly the same SRTP key was used for inner and outer, this is not a normal usecase I assume. But I wanted to give this info as input to the Working Group so the experts can determine if it is a real problem or not. Thanks, Alfred From nobody Fri Mar 16 05:03:05 2018 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 DA0A512785F for ; Fri, 16 Mar 2018 05:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 3_Oz_faGgTiD for ; Fri, 16 Mar 2018 05:03:01 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7194F126BF7 for ; Fri, 16 Mar 2018 05:03:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 03AC47C37CC for ; Fri, 16 Mar 2018 13:03:00 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZ8A9QARX5Au for ; Fri, 16 Mar 2018 13:02:59 +0100 (CET) Received: from [IPv6:2a00:79e0:d:11:6e94:8c6e:5680:96db] (unknown [IPv6:2a00:79e0:d:11:6e94:8c6e:5680:96db]) by mork.alvestrand.no (Postfix) with ESMTPSA id F30297C36ED for ; Fri, 16 Mar 2018 13:02:58 +0100 (CET) To: perc@ietf.org References: <861e4bab-9058-bb0c-fa77-fb313f1f1ec5@gmail.com> From: Harald Alvestrand Message-ID: <19c686a9-e46c-bbca-9b2b-3b89a0311a06@alvestrand.no> Date: Fri, 16 Mar 2018 12:02:58 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <861e4bab-9058-bb0c-fa77-fb313f1f1ec5@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Perc] Security hole in draft-ietf-perc-double-08? X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 12:03:05 -0000 I think this is the definition of symmetric encryption: The encryption and decryption keys are the same. This also means that if you encrypt twice, you get back the plaintext, yes. On 03/16/2018 11:59 AM, Alfred E. Heggestad wrote: > Hi, > > I have some questions about this document: > >     https://tools.ietf.org/html/draft-ietf-perc-double-08 > > > I am currently implementing the Double SRTP encryption > part of PERC. > > > in my testcode I used by accident the same master key > for both the inner and outer transform. Then I discovered > that the doubly encrypted payload was EXACTLY THE SAME > as the plaintext payload (!). > > > is this how SRTP works, that encrypting it twice with the > same key gives back the original result ? > > > I have made a test program to demonstrate it: > >     https://gist.github.com/alfredh/792759cccdd88d058bfd4a2a2d689922 > > running the program: > > $ ./test > RTP packet:     [20 bytes]  80080001000000a05c5c5c5c0102030405060708 > 1xSRTP packet:  [36 bytes]  > 80080001000000a05c5c5c5c3b9c8bcd40a81c1f8946fd4b272f2aef98c50c18348ae92e > 2xSRTP packet:  [53 bytes]  > 80080001000000a05c5c5c5c010203040506070865caa1e8cd9386bbc0e5cf5b1a3c5271eef5f5d6e444f15ff6bc5cdb4cf68859f3 >                                                     ^^^^^^^^^^^^^^^^ > program terminated successfully. > > > the first line shows the original plaintext RTP packet > (payload is 8 bytes 01..08) > > the 3rd line prefixed with "2xSRTP" packet shows the SRTP packet > that will be transmitted on the wire. It also shows the > plaintext RTP packet (!) > > > again, note that exactly the same SRTP key was used for inner and outer, > this is not a normal usecase I assume. > > > But I wanted to give this info as input to the Working Group so > the experts can determine if it is a real problem or not. > > > > > Thanks, > > Alfred > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc -- Surveillance is pervasive. Go Dark. From nobody Fri Mar 16 05:14:22 2018 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 D510712E870 for ; Fri, 16 Mar 2018 05:14:18 -0700 (PDT) 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=ipv-sx.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 Ccdxz0xBKSRs for ; Fri, 16 Mar 2018 05:14:16 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 E615C127AD4 for ; Fri, 16 Mar 2018 05:14:11 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id z8so1778046wrh.7 for ; Fri, 16 Mar 2018 05:14:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NdNFKMo8LiCBIfcTDdX6X3+0Gj2gPbMsu2Wj/3N6NbI=; b=YLtejvJ+9/3euvTW1EtkHy2pIVR0f/BXTw8c2g7QeNUwDOncl7WScy3xid7971zgLk TasfR7qiwo277tmmYyjfmQeEpHXUjWd7dtn+XHbWEZ7bUoIrZbj0ehft4/hx+Nxu6Bva sJrSbalW1nhok4iex0TRiaqsEKT2uEfjvVUMDqYIsRvOyBSIf+40aASt2vcaVgCC51sX TL5he/g6WJzO8K0t4IiVINsaJiOWcP9XF2JRQY6HXLQfgNJsrbJluAxqmLgCvlNlrsGC fsOOu0Ty1J/iQMpJoT+T+9FItkCmCu94K0Yi7kGC80hXCe6MmFBPR89s5jFfpFzsmEv6 bVtQ== 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=NdNFKMo8LiCBIfcTDdX6X3+0Gj2gPbMsu2Wj/3N6NbI=; b=l6SGEbdnnsPYmPdiWJujh/xFAoJlXpMWVRvoLSqbjfSXj/9F/AXSYL1UMMIUGymlY6 kzqZI5nRhqGyC+E3u5jdfMIiUddawg9XGPLxcSx7EDH9y1/g+yifiTjc5ujMufXrblk0 vANeu4FadUS1Wc0qWU0b3jv6zZrSQosLszEFteL+RtnSFPdkdjp5prsBOTC9vgDlPB/v z9gvZwCMrJgC5vriJ3iyCeOM8VkW20MwmN1ywUK09w1o9vAPBcGRZ05z8biBA8OvgPdC O0Tl06eHsc7RzZEvdtZr9sMdDa7Gru+vViP//evr7WkurKHsYIArp8xaSA7Cqfe+48J6 KMkg== X-Gm-Message-State: AElRT7Fy2VRtAk3DXzcZKd2OliH0gIQJo2gT52EAn18KKfzEP6yiYM9J NzYikJh1GIFCNKi4l5MDjg9Sh8/IjFqv+d7DZagyhYm0 X-Google-Smtp-Source: AG47ELuYnX1Qg/qbssD9L1pDIjmxidOkuLb+OMua3dDoDESviec/y4hVhFn3Ja5hwbJJ+1hiAo+F5bQqI+UNnk1J7uQ= X-Received: by 10.223.187.147 with SMTP id q19mr1387934wrg.150.1521202450102; Fri, 16 Mar 2018 05:14:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.12.140 with HTTP; Fri, 16 Mar 2018 05:14:09 -0700 (PDT) In-Reply-To: <19c686a9-e46c-bbca-9b2b-3b89a0311a06@alvestrand.no> References: <861e4bab-9058-bb0c-fa77-fb313f1f1ec5@gmail.com> <19c686a9-e46c-bbca-9b2b-3b89a0311a06@alvestrand.no> From: Richard Barnes Date: Fri, 16 Mar 2018 08:14:09 -0400 Message-ID: To: Harald Alvestrand Cc: perc@ietf.org Content-Type: multipart/alternative; boundary="089e0820f2b8aba44a0567868bbc" Archived-At: Subject: Re: [Perc] Security hole in draft-ietf-perc-double-08? X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 12:14:21 -0000 --089e0820f2b8aba44a0567868bbc Content-Type: text/plain; charset="UTF-8" Not the definition of symmetric encryption, but the definition of CTR mode, on which GCM is based. Basically, you make a keystream that you XOR with the plaintext, so if you do that twice with the same nonce and key, you get the plaintext back. It would be good to explicitly prohibit this in the spec, though. Alfred, want to send a PR? On Fri, Mar 16, 2018 at 8:02 AM, Harald Alvestrand wrote: > I think this is the definition of symmetric encryption: The encryption > and decryption keys are the same. > This also means that if you encrypt twice, you get back the plaintext, yes. > > > On 03/16/2018 11:59 AM, Alfred E. Heggestad wrote: > > Hi, > > > > I have some questions about this document: > > > > https://tools.ietf.org/html/draft-ietf-perc-double-08 > > > > > > I am currently implementing the Double SRTP encryption > > part of PERC. > > > > > > in my testcode I used by accident the same master key > > for both the inner and outer transform. Then I discovered > > that the doubly encrypted payload was EXACTLY THE SAME > > as the plaintext payload (!). > > > > > > is this how SRTP works, that encrypting it twice with the > > same key gives back the original result ? > > > > > > I have made a test program to demonstrate it: > > > > https://gist.github.com/alfredh/792759cccdd88d058bfd4a2a2d689922 > > > > running the program: > > > > $ ./test > > RTP packet: [20 bytes] 80080001000000a05c5c5c5c0102030405060708 > > 1xSRTP packet: [36 bytes] > > 80080001000000a05c5c5c5c3b9c8bcd40a81c1f8946fd4b272f2aef98c50c18348ae92e > > 2xSRTP packet: [53 bytes] > > 80080001000000a05c5c5c5c010203040506070865caa1e8cd9386bbc0e5 > cf5b1a3c5271eef5f5d6e444f15ff6bc5cdb4cf68859f3 > > ^^^^^^^^^^^^^^^^ > > program terminated successfully. > > > > > > the first line shows the original plaintext RTP packet > > (payload is 8 bytes 01..08) > > > > the 3rd line prefixed with "2xSRTP" packet shows the SRTP packet > > that will be transmitted on the wire. It also shows the > > plaintext RTP packet (!) > > > > > > again, note that exactly the same SRTP key was used for inner and outer, > > this is not a normal usecase I assume. > > > > > > But I wanted to give this info as input to the Working Group so > > the experts can determine if it is a real problem or not. > > > > > > > > > > Thanks, > > > > Alfred > > > > _______________________________________________ > > Perc mailing list > > Perc@ietf.org > > https://www.ietf.org/mailman/listinfo/perc > > > -- > Surveillance is pervasive. Go Dark. > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --089e0820f2b8aba44a0567868bbc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Not the definition of symmetric encryption, but the d= efinition of CTR mode, on which GCM is based.=C2=A0 Basically, you make a k= eystream that you XOR with the plaintext, so if you do that twice with the = same nonce and key, you get the plaintext back.

It= would be good to explicitly prohibit this in the spec, though.=C2=A0 Alfre= d, want to send a PR?

On Fri, Mar 16, 2018 at 8:02 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
I think this is the definition of symmetric encryption: The encryption and decryption keys are the same.
This also means that if you encrypt twice, you get back the plaintext, yes.=


On 03/16/2018 11:59 AM, Alfred E. Heggestad wrote:
> Hi,
>
> I have some questions about this document:
>
> =C2=A0=C2=A0=C2=A0 https://tools.ietf.org/= html/draft-ietf-perc-double-08
>
>
> I am currently implementing the Double SRTP encryption
> part of PERC.
>
>
> in my testcode I used by accident the same master key
> for both the inner and outer transform. Then I discovered
> that the doubly encrypted payload was EXACTLY THE SAME
> as the plaintext payload (!).
>
>
> is this how SRTP works, that encrypting it twice with the
> same key gives back the original result ?
>
>
> I have made a test program to demonstrate it:
>
> =C2=A0=C2=A0=C2=A0 https://gist= .github.com/alfredh/792759cccdd88d058bfd4a2a2d689922
>
> running the program:
>
> $ ./test
> RTP packet:=C2=A0=C2=A0=C2=A0=C2=A0 [20 bytes]=C2=A0 80080001000000a05= c5c5c5c0102030405060708
> 1xSRTP packet:=C2=A0 [36 bytes]=C2=A0
> 80080001000000a05c5c5c5c3b9c8bcd40a81c1f8946fd4b272f2aef98c5= 0c18348ae92e
> 2xSRTP packet:=C2=A0 [53 bytes]=C2=A0
> 80080001000000a05c5c5c5c010203040506070865caa1e8cd9386bbc0e5= cf5b1a3c5271eef5f5d6e444f15ff6bc5cdb4cf68859f3
> =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=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=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 ^^^^^^^^^^^^^^^^
> program terminated successfully.
>
>
> the first line shows the original plaintext RTP packet
> (payload is 8 bytes 01..08)
>
> the 3rd line prefixed with "2xSRTP" packet shows the SRTP pa= cket
> that will be transmitted on the wire. It also shows the
> plaintext RTP packet (!)
>
>
> again, note that exactly the same SRTP key was used for inner and oute= r,
> this is not a normal usecase I assume.
>
>
> But I wanted to give this info as input to the Working Group so
> the experts can determine if it is a real problem or not.
>
>
>
>
> Thanks,
>
> Alfred
>
> _______________________________________________
> Perc mailing list
> Perc@ietf.org
> https://www.ietf.org/mailman/listinfo/perc

--
Surveillance is pervasive. Go Dark.

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

--089e0820f2b8aba44a0567868bbc-- From nobody Sat Mar 17 12:13:46 2018 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 8173412D7EA for ; Sat, 17 Mar 2018 12:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 udfNHC-QD_Aj for ; Sat, 17 Mar 2018 12:13:42 -0700 (PDT) Received: from smtp85.ord1d.emailsrvr.com (smtp85.ord1d.emailsrvr.com [184.106.54.85]) (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 D2F2A127876 for ; Sat, 17 Mar 2018 12:13:42 -0700 (PDT) Received: from smtp19.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp19.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id 40D136007D; Sat, 17 Mar 2018 15:13:42 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp19.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id BAC8860079; Sat, 17 Mar 2018 15:13:41 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.61.165.89] ([UNAVAILABLE]. [173.38.220.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:25 (trex/5.7.12); Sat, 17 Mar 2018 15:13:42 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <861e4bab-9058-bb0c-fa77-fb313f1f1ec5@gmail.com> Date: Sat, 17 Mar 2018 19:13:45 +0000 Cc: perc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <861e4bab-9058-bb0c-fa77-fb313f1f1ec5@gmail.com> To: "Alfred E. Heggestad" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Perc] Security hole in draft-ietf-perc-double-08? X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2018 19:13:44 -0000 I created a bug for this at https://github.com/ietf/perc-wg/issues/151 > On Mar 16, 2018, at 11:59 AM, Alfred E. Heggestad = wrote: >=20 > Hi, >=20 > I have some questions about this document: >=20 > https://tools.ietf.org/html/draft-ietf-perc-double-08 >=20 >=20 > I am currently implementing the Double SRTP encryption > part of PERC. >=20 >=20 > in my testcode I used by accident the same master key > for both the inner and outer transform. Then I discovered > that the doubly encrypted payload was EXACTLY THE SAME > as the plaintext payload (!). >=20 >=20 > is this how SRTP works, that encrypting it twice with the > same key gives back the original result ? >=20 >=20 > I have made a test program to demonstrate it: >=20 > https://gist.github.com/alfredh/792759cccdd88d058bfd4a2a2d689922 >=20 > running the program: >=20 > $ ./test > RTP packet: [20 bytes] 80080001000000a05c5c5c5c0102030405060708 > 1xSRTP packet: [36 bytes] = 80080001000000a05c5c5c5c3b9c8bcd40a81c1f8946fd4b272f2aef98c50c18348ae92e > 2xSRTP packet: [53 bytes] = 80080001000000a05c5c5c5c010203040506070865caa1e8cd9386bbc0e5cf5b1a3c5271ee= f5f5d6e444f15ff6bc5cdb4cf68859f3 > ^^^^^^^^^^^^^^^^ > program terminated successfully. >=20 >=20 > the first line shows the original plaintext RTP packet > (payload is 8 bytes 01..08) >=20 > the 3rd line prefixed with "2xSRTP" packet shows the SRTP packet > that will be transmitted on the wire. It also shows the > plaintext RTP packet (!) >=20 >=20 > again, note that exactly the same SRTP key was used for inner and = outer, > this is not a normal usecase I assume. >=20 >=20 > But I wanted to give this info as input to the Working Group so > the experts can determine if it is a real problem or not. >=20 >=20 >=20 >=20 > Thanks, >=20 > Alfred >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc From nobody Sun Mar 18 08:02:31 2018 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 3BF6612D952 for ; Sun, 18 Mar 2018 08:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-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 sjze2gAV1Nkj for ; Sun, 18 Mar 2018 08:02:28 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::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 1E44E12D7FC for ; Sun, 18 Mar 2018 08:02:24 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id r197so8227723vke.2 for ; Sun, 18 Mar 2018 08:02:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=2gSvezh7rDMV8Pf4HkHZNfOK5j2on2PTOIysqstQeWQ=; b=r1SOFLmSYHRqJ+1LXEfnJ4G2B4iDpqllFXyFroC4um8WqRgHbFuUTfng8nRA+UEgH9 cxwc3Mlg0OEHv6pdBfdXKsHqgiD90NvxALHoO9RzZl+9Vt0y9xX4trJig04WiHsmVlG3 sCZyWwKZzXyrSIUaQnLPc4Db8OEpGwRIb0H5wFeR/3k7OQRJArSpO9NZd0nEjGmd/HzQ sYWbPyqSwsNSwbVgiSU1QOU0lLDLivp51+KD+uFlU4Pje3nB0It7pMJciPh3XZ+4W3nH lsrj0R4q58mo5XRetZgvownYh5srGUtsv1PWgrqH6Pegd10Lgwtdj601DY+fP0WkxFw/ mFIA== 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=2gSvezh7rDMV8Pf4HkHZNfOK5j2on2PTOIysqstQeWQ=; b=T22A44gfx96Os2T7x7reJs5yhAp+XK/0vqE03OiiNFAqiG0IvG4EU8Me4Pe7Mq+f0E wEkof3ndbeQKhov83NpFiqzkFaow2vzIaN86buayk/J0/gNb+Y49jNdAGxOpgOtIZ0Ut UiCfoykf9ExVBKgRxOzZjg25/Pt6rrE68XzvSGy7SDLD6HLrFXfO/n2kmKRCaupuAzHa CrWB6WmZbAOX0fHWm632L97gjVr1gDa1PMNP1USvMFyXfUd69hpjxqFKPuW6I5vwB1Dr P64TRD5GSiqZRoeE4/xS7nNcRnXEhw8ddCMu819bFHmidqqcJxJFqvbyYPtc7TrdqOs/ FTfA== X-Gm-Message-State: AElRT7GTiZKvOk1rYE8otHPYv5kDSMntabJua76ADFHueU9qt3NENPpV LgWfM7BIr5bs6nxoRs/zPpMvrYSXZ8QesGiCzjtzqQ== X-Google-Smtp-Source: AG47ELtRupJAom7jBwN0NCZDAKHHqSVbNrjYhAsgmhyphDbKc2IlE8BOqT+CsuIu52dR7LzW1aY3L7RF7Gtwaou19e0= X-Received: by 10.31.59.139 with SMTP id i133mr5573110vka.4.1521385343058; Sun, 18 Mar 2018 08:02:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.32.67 with HTTP; Sun, 18 Mar 2018 08:02:22 -0700 (PDT) From: Suhas Nandakumar Date: Sun, 18 Mar 2018 15:02:22 +0000 Message-ID: To: perc@ietf.org Content-Type: multipart/alternative; boundary="001a1142f994f08f110567b120f4" Archived-At: Subject: [Perc] IETF 101 PERC WG meeting cancelled X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2018 15:02:29 -0000 --001a1142f994f08f110567b120f4 Content-Type: text/plain; charset="UTF-8" Since there were no significant new issues have been raised to have the discussion, the PERC session for IETF 101 is cancelled. We will continue the discussion for the current open issue regarding key reuse on the mailing list. Thanks Suhas/Nils --001a1142f994f08f110567b120f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Since there were no significant new issues hav= e been raised to have the discussion, the PERC session for IETF 101 is canc= elled.=C2=A0

We will continue the discussion for= the current open issue regarding key reuse on the mailing list.


Thanks
Suhas/Nils


--001a1142f994f08f110567b120f4-- From nobody Mon Mar 19 03:44:56 2018 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 8657C126DEE for ; Mon, 19 Mar 2018 03:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=vidyo-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 vMQ6ON5X8STP for ; Mon, 19 Mar 2018 03:44:53 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 99A75126E64 for ; Mon, 19 Mar 2018 03:44:53 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id z12so18093715wrg.4 for ; Mon, 19 Mar 2018 03:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vidyo-com.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=W3fRpk1R2NUUpkWpECtyMUAdFXId35sVY2zFmQxxQvo=; b=wFc9S25nJgF+yGvIV5k32kBrEuS0cq5dYBMG0EIp4qAud9b7sjfKZwl8RUa+g/2jC2 HqSrgGFaEqAHxLgBkg62inBJn/15GRLsk2K6q5lcGJ/sEDBq+G1q+cCXV2apkFz3Qryb pXbC8Z0syc5BoMaVuEUZRlDj6gMnN1yzTpIcUEEuxfMlbSWRw4S01vcQFCYqRmA9+mbW HfkMfq66DaY1hQHcysj43HbXn9cGiY+mbci/aJtSzeVtuokKSEKwdP3nABZzrYvQ9pCC TyKUH8I8uFWEZWAXfyHIZ/V/M6w9LYTexooq4OmSQjtoRFxlkhJRAItvXk8N8SJ/jFhu v4mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=W3fRpk1R2NUUpkWpECtyMUAdFXId35sVY2zFmQxxQvo=; b=SaVvtBo4A8PWDTQ3COzv6rzX3/CQWpUepeGSidtE0AgDGIzRuEA71SYsYgm6+2gTJJ J2hHDarbk5MkAP/obFoqBDAf4sljIrP2tffNbMui8nmtW1avijQH3dJ/2Y1mdIA/yZXX /7pvLAveX6sgVK2mwIZsJ5ODE1UfnjxA6r1aOgF4o8WZ6mB100PvQpvSJ4BDn+h7AZPT Lv1TzLTbrTD1ernfI9RiyFF3EXztv3Fl+Gv9c7A9S1tOmhu7BYZb6meGqmSxmMCKrFQn Mv6jHuvjAy2jpfvst5kROsIGni77D20fPj8Br3XOF+lhOp+Q/ckXcxPfqwZfKHKPSeD6 8Gdg== X-Gm-Message-State: AElRT7HNNCCbBMApmnpphjoBldWjY2hkrJ7H9niiwdXUR5hH91kAcA3H RSDXa6PvHi23A6FJgJI0r4QDx4Ye1Jg= X-Google-Smtp-Source: AG47ELvMl4ckwuHrfbFWaGdfcsVpiAQt3wL1LUUVXX4+J2yt7I0gM5Oqyo3hyFQcE02YoaNdK8AgLQ== X-Received: by 10.223.158.196 with SMTP id b4mr8779527wrf.112.1521456291699; Mon, 19 Mar 2018 03:44:51 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:c8da:977b:d1e4:c720? ([2001:67c:370:128:c8da:977b:d1e4:c720]) by smtp.gmail.com with ESMTPSA id m190sm71068wmb.6.2018.03.19.03.44.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 03:44:50 -0700 (PDT) From: Jonathan Lennox Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <85D13597-FFEC-41E4-BFEA-A7A58DA4198B@vidyo.com> Date: Mon, 19 Mar 2018 10:44:50 +0000 To: perc@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Perc] Review of draft-ietf-perc-srtp-ekt-diet-07 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 10:44:55 -0000 Hi - I reviewed ekt-diet. Sorry for this not coming in until the = meeting. Substantive: SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes. This depends on the cipher suite negotiated for SRTP using SDP Offer/ Answer [RFC3264] for the SRTP. This should say using DTLS/SRTP. There are other references to = Offer/Answer scattered around the descriptions as well. A receiver SHOULD discard the whole EKTField if it contains any message type value that is less than 64 and that is not understood. Message type values that are 64 or greater but not implemented or understood can simply be ignored. What is the difference between discarding and ignoring? Is there an = implication that a packet can carry more than one EKTField? How does = this affect the treatment of the rest of the SRTP packet? At any given time, each SRTP/SRTCP source has associated with it a single EKT parameter set In RFC 7656 terminology (which we=E2=80=99re trying to get all = RTP-related documents to use), this should be a stream, not a source. = Source is a higher-level concept. Generally, this document should be checked for RFC 7656 alignment, and = either brought into alignment or (if you must) have the differences = called out. There may be other EKT parameter sets that are used by other SRTP/SRTCP sources in the same session, including other SRTP/SRTCP sources on the same endpoint (e.g., one endpoint with voice and video might have two EKT parameter sets, or there might be multiple video sources on an endpoint each with their own EKT parameter set). Is it valid for multiple sources (streams) from the same endpoint to = share an EKT parameter set if the sender wishes? Or must every source = have a unique parameter set? I think the latter is the case (because the parameter set includes SSRC = and ROC) but it=E2=80=99s not clear. The ROC, SRTP Master Key, and SSRC used in EKT processing SHOULD be the same as the one used in the SRTP processing. Why is this only SHOULD? When would a sender want them to be different? = Especially since 4.2.2 Step 5 says the values MUST be discarded if the = SSRCs don=E2=80=99t match. * Note: the value of the EKTCiphertext field is identical in successive packets protected by the same EKTKey and SRTP master key. This value MAY be cached by an SRTP sender to minimize computational effort. This is true except when the RTP sequence number rolls over, causing the = ROC to increment. (This is explained later, but should be said here as = well.) If the SRTP Master Key recovered from the EKTPlaintext is shorter than needed by SRTP transform in use, then the bytes received replace the first bytes in the existing key but the other bytes after that remain the same as the old key. This allows for replacing just half the key for transforms such as [I-D.ietf-perc-double]. This feels unnecessarily, and dangerously, over-general to me. I=E2=80=99= d suggest that specific transforms MAY allow specific sets of key bytes = to be replaced, but the default is that all bytes MUST be replaced. Note that if the same FullEKTField is retransmitted 3 times, that only counts as 1 encryption. Is =E2=80=9C3=E2=80=9D a special value here, or do you mean = =E2=80=9Cmultiple=E2=80=9D? EKT SHOULD be used over SRTP, and other specification MAY define how to use it over SRTCP. SRTP is preferred because it shares fate with transmitted media, because SRTP rekeying can occur without concern for RTCP transmission limits, and to avoid SRTCP compound packets with RTP translators and mixers. Does this mean that SRTCP packets always carry just a short EKT field, = or do they not carry an EKT suffix at all? Editorial: 1. Real-time Transport Protocol (RTP) is designed=20 Should be *The* Real-time Transport Protocol 2. EKT does not control the manner in which the SSRC is generated; it is only concerned with their secure transport. Number agreement: =E2=80=9Cthe SSRC=E2=80=9D vs. =E2=80=9Ctheir=E2=80=9D. = Probably the former should be =E2=80=9Cthe manner in which SSRCs are = generated.=E2=80=9D 4.1 EKTMsgLength: All EKT message other that ShortEKTField =E2=80=9CAll EKT messages=E2=80=9D; =E2=80=9Cthan=E2=80=9D 4.2.1: When a packet is sent with the Short EKT Field, the ShortEKFField is simply appended to the packet. =E2=80=9CShortEKTField=E2=80=9D 4.2.2: 2. The Security Parameter Index (SPI) field is used to find which EKT parameter set to be used when processing the packet. =E2=80=9Cwhich EKT parameter set is to be used=E2=80=9D 4.3: At this point implementation need to either use the call signaling to renegotiation a new session or need to terminate the existing session. =E2=80=9CImplementations need=E2=80=9D; =E2=80=9Cto renegotiate=E2=80=9D.