From nobody Thu Dec 8 07:48:22 2016 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 F2928129F04 for ; Thu, 8 Dec 2016 07:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 ZgCYWNaND-Qd for ; Thu, 8 Dec 2016 07:48:18 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA259129F0A for ; Thu, 8 Dec 2016 07:48:11 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id n6so415587813qtd.1 for ; Thu, 08 Dec 2016 07:48:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=vexIW8Sp3PIqGggzVZUG3U/v5jEIlWQ6abm0JBBS9yw=; b=iOySKE6uLYaBhpjhN/3nKhR7Ht7sSgqZ2PIEIB3dQj7aAlHh2apELhguIMrxJtNJtg vHWDxP/o/xa15Jb+4j56lbcnYhSXJXvP2BJMDLb3XP9FmOiegxU9dMhg0QOd3Fh+JSlQ KsUdpZAhchTArZPPnZqaLU5s5YMgSRPxz6Lqs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=vexIW8Sp3PIqGggzVZUG3U/v5jEIlWQ6abm0JBBS9yw=; b=ATnQbsX55h2rjpa1iipXCf3GK7cnsFXyaVkNyHxK9ZYM5wrWRU+sBi9jAxeGMqHtN/ idyFNj1SmrMqMM9IjaVObtj/1n2jBzov6AyAMwyHebZ3so0Z+pPuNC9yZ98bLlDqZ4R1 BM9HSo9gTbQ1Hol/3rLnMx8u9M+FLtnj3mCpgRpJB0nUUrCFEHlKbG6KA9IHMnc0rJEY 4UH1PWiMV9cDbVMTSk8ncktW1mIy3W7SsVW/aI4z0Jie+6oPT02MWON1R27PchdZ0M1U Kh/bq1+HUPj/T7jEo7W76kOL2Xp3/1ZCwljRdtptLFGknNcuF2KYbVHdDCQKb48HyVMe K5Nw== X-Gm-Message-State: AKaTC03k6hrd6TeOyQGpHEh7KSCDfrPrQtO144nXaa5ccz0RUW1YEZBAEsuiYxiMqpGxpQ== X-Received: by 10.200.43.120 with SMTP id 53mr63219887qtv.253.1481212090878; Thu, 08 Dec 2016 07:48:10 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id 1sm17653393qte.46.2016.12.08.07.48.10 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 08 Dec 2016 07:48:10 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <85FD4558-D946-4A75-944E-D9B1A52F2A4A@sn3rd.com> Date: Thu, 8 Dec 2016 10:48:08 -0500 To: perc@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Perc] review of draft-ietf-perc-srtp-ekt-diet X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 15:48:21 -0000 I volunteered in Seoul to review the draft. Three bigger picture = questions, then a bunch of nits: 0) I suspect the answer to this question is "yeah we know but we don=E2=80= =99t want to wait=E2=80=9D: DTLS1.3 is going to include a =E2=80=9CKey = and IV update handshake message" so aren=E2=80=99t we kind of setting up = a situation where we=E2=80=99re burning a TLS content type code point = for a DTLS1.2-specific protocol? Put another way are you going to redo = this for TLS1.3? 1) Based on the DoS security consideration, it appears as if you=E2=80=99r= e okay with the EKT field not be protected by SRTP. (he asks without = having dug into SRTP in a while) There=E2=80=99s really no way to get at = integrity protection of the EKT field? 2) s2.2.2, #1: I gotta ask why the MessageType byte isn=E2=80=99t first? = Wouldn=E2=80=99t putting the MessageType first allow you avoid buffering = everything before proceeding? It seems like you=E2=80=99re counting on = nobody sending a string of zeros as the first byte of the EKT field to = mess with implementations. NITS: 0) s2, last paragraph What happens if an implementation does use SRTP's MKI or with SRTP's = ? Is an error thrown? 1) s2.1, EKTPlaintext Probably over thinking this, but is the concatentation like so: +--------------+--------+--------+ | SRTP MK | SSRC | ROC | +-------------+---------+--------+ I=E2=80=99d be afraid somebody would think it=E2=80=99s the other way = around without being more specific. Maybe it=E2=80=99s as easy as: = putting something like "SRTP MK || SSRC || ROC, where || denotes = concatenation=E2=80=9D somewhere in the paragraph. 2) s2.1, EKTMsgLength Should this be =E2=80=9CMUST=E2=80=9D: All EKT message other that = ShortEKTField must have ... 3) s2.1, MessageType Maybe it=E2=80=99s late but I=E2=80=99m having trouble parsing this = sentence: Values less than 64 are mandatory to understand and the whole EKTField SHOULD be discarded if it contains message type value that is less than 64 and is not implemented. Can =E2=80=9Cand is not implemented=E2=80=9D be dropped? 4) s2.2.1 r/needs to be sent/is sent r/is to be sent/is sent 5) s2.2.1, #4 =E2=80=9CEKTMEsgTypeFull=E2=80=9D doesn=E2=80=99t appear anywhere else = in the draft. I think it=E2=80=99s supposed to =E2=80=9C =E2=80=A6 = Message Type using the FullEKTField format." also: r/EKT Ciphertext/EKTCiphertext 6) s3.2 To ensure we tick all the coordination boxes, it=E2=80=99s probably = worth making sure that this draft also gets sent to the TLS WG during = WGLC because it=E2=80=99s defining an extension and a content type. 7) s3.2: struct { EKTCipherType ekt_ciphers<0..254>; } SupportedEKTCiphers; 0..254? Should it be 1..256? 8) s3.2: r/When the server responds in the "srtp_ekt_key_transport" in its ServerHello message, it must include /When the server responds in the "srtp_ekt_key_transport" in its ServerHello message, it MUST include 9) s5 Should the registries be part of the SDP or RTP parameters group? I.e., = collected together with the other SDP parameters? 10) s5.2 I=E2=80=99m assuming the AESKW256 value is 3 on purpose? Cheers, spt= From nobody Fri Dec 9 15:44:12 2016 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 2F40212953F for ; Fri, 9 Dec 2016 15:44:11 -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 hUfzT7TRGX_r for ; Fri, 9 Dec 2016 15:44:09 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85DD412952C for ; Fri, 9 Dec 2016 15:44:09 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id c47so30517153qtc.2 for ; Fri, 09 Dec 2016 15:44:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=5j5makS2r6ajj6ZBPavUEN/8adAWeS/kC8uWKguH+9Y=; b=ssT0O37ABAWtud3X98Dz8uoP6sZQ7qTYiG6LoeWOvelvG+otNi3x3+B6hMpZ/UnOFh igFe5aXlU1MEB8xvvNQj9FjVOkQHWGF3xOTfk6ecx79w2d1QfD/grvhTsOC+MssFYBOS DYIUDakgBuKjBaVa2DllfWaCgv/+l6m5Fn5HTfl0RK2Xtdo8HqUVOn5M55Ll6lMv2KBy 6FIE4xcEARSfnBqFlBuEVYyWcQKgMlAYbo3a155HuTDEaElldx2xcpB06+lO7RQdRoVY kFUws3KpAVFM8gbS+n5dZ1zSnSvyOPYq3NyRhWoJ2X6aPHtlJ0eizsKuJIkkZCN7LTnH ivgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5j5makS2r6ajj6ZBPavUEN/8adAWeS/kC8uWKguH+9Y=; b=CpByk7o4eveFNq5Wb8BSECheGLKGpruhB2mSKELmbCQ+FBDLGlLx45I+4wHVuH2heD MPscU4Nn3NXg50HxB+GW4JTldzruXJMUpm9z3je1Yhs40Glt0NyQwyCLwl1/9f18WGo3 W/od0i7R7JrS+f0Rgy0mmhfla8OF/IXA1P25rOxF5d+TRWZAQlZb1NMLfM0ng72mXzK3 faZOhRI/MbxQKHxj5oETAb9l0Dzix/Nob0uwgyIbso5baJ98/BAgPNKkPW8xSfHQTQ6r tP8dPHnNfKM1GN9jTS8+dXexi6fHeFNTFTdvv0mO+f/X+hugLc7WBQJP/uadHkwkQv9A M98w== X-Gm-Message-State: AKaTC02Rb74jxBEBo/TD0z0BzFFQ2ylkftfN6fyP7btb7nG/wed+o0QQ6u+BWTzy2uOndqNAhCwrBUiTkBnPWg== X-Received: by 10.237.59.97 with SMTP id q30mr73860166qte.77.1481327048608; Fri, 09 Dec 2016 15:44:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.50.36 with HTTP; Fri, 9 Dec 2016 15:44:08 -0800 (PST) From: Suhas Nandakumar Date: Fri, 9 Dec 2016 15:44:08 -0800 Message-ID: To: perc@ietf.org Content-Type: multipart/alternative; boundary=94eb2c19285e8756bc0543425467 Archived-At: Subject: [Perc] IETF 97 Minutes X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 23:44:11 -0000 --94eb2c19285e8756bc0543425467 Content-Type: text/plain; charset=UTF-8 Hello All, Here is the initial version of the PERC Minutes. Please let me/Richard know if you have any comments/edits by 9th January 2017. https://www.ietf.org/proceedings/97/minutes/minutes-97-perc-00.txt Cheers Suhas/Richard --94eb2c19285e8756bc0543425467 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All,


Here is the initial version of the PERC Minutes= .=C2=A0 Please let me/Richard know if you have any comments/edits by 9th Ja= nuary 2017.

https://www.ietf.org/procee= dings/97/minutes/minutes-97-perc-00.txt
<= /div>


Cheers
Suhas/Richard
--94eb2c19285e8756bc0543425467-- From nobody Fri Dec 16 11:24:41 2016 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 55D10129432 for ; Fri, 16 Dec 2016 11:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 ok8f0YI1kqNb for ; Fri, 16 Dec 2016 11:24:39 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA510120725 for ; Fri, 16 Dec 2016 11:24:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id ACE4430028C for ; Fri, 16 Dec 2016 14:14:21 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AKgXuJ3kWLds for ; Fri, 16 Dec 2016 14:14:20 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 389273000FF for ; Fri, 16 Dec 2016 14:14:20 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <52690CC4-E67A-4E45-AEED-CE59F96E2EEF@vigilsec.com> Date: Fri, 16 Dec 2016 14:24:45 -0500 To: perc@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [Perc] Review of draft-ietf-perc-srtp-ekt-diet-02 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 19:24:40 -0000 In Seoul, I agreed to d a review of draft-ietf-perc-srtp-ekt-diet-02. = Here is my review. I have sent a more complete review to the authors. I have included = editorial comments in the review sent to the authors. I stick to = technical comments in this posting. Section 2 says: EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key Identifier) or with SRTP's [RFC3711], as those SRTP features duplicate some of the functions of EKT. >>> Do you expect implementations to check for this MUST NOT? >>> If so, what should the recipient do if the sender does use EKT >>> in conjunction with SRTP's MKI or with SRTP's ? Section 2.1 says: EKTMsgLength All EKT message other that ShortEKTField must have a length as second from the last element. This is the length in octets of either the FullEKTField/ExtensionEKTField including this length field and the following message type. >>> This "must" statement is really a requirement on the person that >>> will specify other EKT messages. Is there a better place to state >>> This requirement? Section 2.2.1, step 4 says: 4. Then the FullEKTField is formed using the EKTCiphertext and the SPI associated with the EKTKey used above. Also appended are the Length and EKTMEsgTypeFull elements. >>> s/EKTMEsgTypeFull/EKTMsgTypeFull/ Note: the value of the EKT Ciphertext field is identical in >>> To match text in step 4: s/EKT Ciphertext/EKTCiphertext/ successive packets protected by the same EKTKey and SRTP master key. This value MAY be cached by an SRTP sender to minimize computational effort. Section 2.2.2 says: When receiving a packet on a RTP stream where EKT was negotiated, the following steps are applied for each received packet. >>> Will an implementation ever be doing SRTP with EKT with some >>> sessions and SRTP without EKT for other sessions at the same time? >>> If so, how does the inbound processing determine whether an EKT >>> is present or not? Is an additional step needed to perform >>> "normal SRTP or SRTCP processing" on packets without EKT? Section 2.3 says: EKT uses an authenticated cipher to encrypt and authenticate the EKTPlaintext. We first specify the interface to the cipher, in order to abstract the interface away from the details of that function. We then define the cipher that is used in EKT by default. The default cipher described in Section 2.3.1 MUST be implemented, but another cipher that conforms to this interface MAY be used, in which case its use MUST be coordinated by external means (e.g., key management). >>> The SPI tells which cipher is being used, so I do not understand the >>> second MUST in the sentence. Key management needs to put the key in >>> place regardless of the algorithm in play. And, later it says: The decryption function returns a plaintext value P that is at least M bytes long, or returns an indication that the decryption operation failed because the ciphertext was invalid (i.e. it was not generated by the encryption of plaintext with the key K). >>> It seems that E can pad P. That is fine. Why not have D strip >>> any padding that was put on by E? And, then it says: These functions have the property that D(K, E(K, P)) =3D ( P concatenated with optional padding) for all values of K and P. Each cipher also has a limit T on the number of times that it can be used with any fixed key value. The EKTKey MUST NOT be used more that T times. >>> Where is the counter kept to enforce T? It does not seem to be >>> one of the parameters associated with the SPI for outbound >>> processing. Also, what does an implementation do if it reaches >>> the limit imposed by T? Section 3.2 says: struct { EKTCipherType ekt_ciphers<0..254>; } SupportedEKTCiphers; >>> There must be at least one, right? Otherwise, just don't include >>> the extension. >>> s/<0..254>/<1..254>/ And, later it says: If a DTLS client includes "srtp_ekt_key_transport" in its ClientHello, then a DTLS server that supports this extensions will includes "srtp_ekt_key_transport" in its ServerHello message. If a DTLS client includes "srtp_ekt_key_transport" in its ClientHello, but does not receive "srtp_ekt_key_transport" in the ServerHello, the DTLS client MUST NOT send DTLS EKTMessage messages. >>> Also, the "srtp_ekt_key_transport" in the ServerHello MUST select >>> one and only one EKTCipherType from the list provided by the client >>> in the "srtp_ekt_key_transport" in the ClientHello. And, then it says: ekt_ttl: The maximum amount of time, in seconds, that this ekt_key_value can be used. The ekt_key_value in this message MUST NOT be used for encrypting or decrypting information after the TTL expires. >>> There is a mismatch between TTL and T. TTL says that the key >>> cannot be used after a number of seconds, but T says that the key >>> cannot be used after a number of encrypt operations. The data >>> to enforce these is very different. This should be discussed in >>> implementation guidance. Section 4 says: The presence of the SSRC in the EKTPlaintext ensures that an attacker cannot substitute an EKTCiphertext from one SRTP stream into another SRTP stream. >>> I do not see a step in Section 2.2.2 that performs this check. I >>> expected to see a comparison of the decrypted SSRC to the one that >>> is in the packet. Without such a check, we cannot expect every >>> implementation to prevent this substitution attack. And, later it says: Each EKT cipher specifies a value T that is the maximum number of times a given key can be used. An endpoint MUST NOT send more than T Full EKT Field using the same EKTKey. In addition, the EKTKey MUST NOT be used beyond the lifetime provided by the TTL described in Section 3.2. >>> This document tells the sender to put the same EKT into 3 SRTP >>> packets. This does not count as 3 encryptions. This is 1 >>> encryption, even though the ciphertext is transmitted multiple >>> times. Russ From nobody Sun Dec 18 00:33:55 2016 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 EF3EB1293E3 for ; Sun, 18 Dec 2016 00:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 Yv931-SPMFLQ for ; Sun, 18 Dec 2016 00:33:52 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92D9B128824 for ; Sun, 18 Dec 2016 00:33:51 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id a197so69680496wmd.0 for ; Sun, 18 Dec 2016 00:33:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version:thread-index :content-language; bh=+a9BZQbtnzx5RwscX+EyYeIz/OXIf4tWktMsxbaDLbw=; b=X7ujbObMSch902FtIysGmjrU3a+5O4UadPg2kFsdL4zmVDF+iO4xzPC4v4jG+bPYLi 2gC0/2y3uXxsZon6XPGEiVeDK/3DjLXO6AGmPjUQymmG2V2cwfIx7OhOCDKfqOyRJ7Ot zVN4yAcmRw6QSJIJHFxdZqJVchPvaDoOkNt+EDrvjh5w/bj8bzC6E+kjNLNjNsPNWSjU 0BhKDD2/0v7b/ykawKxLK4D0ilTGLgbJLgXUdrRh10NCRGFN1F1ncKn0h2P0hdrhn1XW DSG5rTpTP/X1JOoJfCEfNocbVqZrFpp00UOhzsb9e3kKMT2DN5EhMcvnqfcHQKUPhE2O GtZw== 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:date:message-id:mime-version :thread-index:content-language; bh=+a9BZQbtnzx5RwscX+EyYeIz/OXIf4tWktMsxbaDLbw=; b=hpetFMyFmuvDmbNslgqag7JtKPSTky7AU9c0pLCzZfE6BXRVbZcrlLwH/l1VwqDJfE Wd0lcxqU3caxvHO96x1zopzeS9lE1ucdDAw479tCCSj2mbR0HCIMGdVJVWtzjpnbUOpf ALyw1eQKH5iaZWyEx/GL9TQx/IF00RXmHIRebV29UZ6vuG56wr+uPoGTBpS5UFE94NFs twDwQDYD9M3MJI574rhL5jHvyq/1O6gmKb+efi/dwc4tCS6HwUltY1yoBM1zkB4ODCw1 f/6DAKlfChwLrgwiaABCKOnJ2by0WZMVehXoTsf9dy6rCZW2QLRf4T7TJkDLltvvMocK y1Rg== X-Gm-Message-State: AIkVDXJjXTAOpX9YU+PBQJCXfos8cTLF4jVPYFGj3iKDoIGP/Ybwj6clCize4gr6qcG/BA== X-Received: by 10.28.9.131 with SMTP id 125mr9053167wmj.22.1482050029676; Sun, 18 Dec 2016 00:33:49 -0800 (PST) Received: from RoniPC (bzq-79-177-109-28.red.bezeqint.net. [79.177.109.28]) by smtp.gmail.com with ESMTPSA id jm6sm14928419wjb.27.2016.12.18.00.33.47 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 18 Dec 2016 00:33:48 -0800 (PST) From: "Roni Even" To: Date: Sun, 18 Dec 2016 10:33:45 +0200 Message-ID: <033b01d25909$72b72a70$58257f50$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_033C_01D2591A.364132F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdJZCTSHNFZ6pi5WRVa4F/9UaNbdvA== Content-Language: he Archived-At: Subject: [Perc] Review of draft-ietf-perc-private-media-framework-02 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2016 08:33:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_033C_01D2591A.364132F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I reviewed draft-ietf-perc-private-media-framework-02 (volunteered to do it in Seoul" I have some comments but in general the document is in good shape. 1. Section 2 - endpoint - maybe use PERC endpoint instead of endpoint since endpoint has many uses. 2. Section 2 - MD - typo "to to" 3. Section 2 - Key Distributer "which passes keying." is it passes or maybe allocates or creates? 4. Section 2 - Conference - here you use trusted endpoints, this relates to my comment on endpoint above, you added a qualifier to the endpoint. 5. Section 2 - Third party - what is a "call processing" entity, it is not defined. 6. Section 3.1.1 second paragraph - "as the media distributer does not have the ability .." I assume this will be specified in a signaling draft, so will we have a reference or just say it is out of scope? 7. Section 3.1.2 - I am not sure about the usage of "trusted" in this paragraph. From the first paragraph I think trusted means PERC trusted, yet the third paragraph is confusing, is it PERC trusted? 8. Section 3.2.1 use pre-PERC, I think you should say non-PERC (it is not a time definition) 9. Section 4.2 figure 2, what about the MD x to MD y confidentiality. 10. Section 4.5 last paragraph, is HBH key between MDs is left out of scope, if yes say it in this paragraph. 11. In section 5.2 what is the conference signaling model. Is there a central signaling entity here? Maybe it is time to add reference to RFC4353 and maybe say something about RFC4575. 12. Section 5.3 " the Key Distributor is responsible for knowing .". Is the KD responsible, I thnk the KD MUST know since the responsibility for allowing participants is on the "focus" or "conference manager". Roni Even ------=_NextPart_000_033C_01D2591A.364132F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I reviewed = draft-ietf-perc-private-media-framework-02 = (volunteered to do it in Seoul”

 

I have some comments but = in general the document is in good shape.

 

 

1.       = Section 2 – = endpoint - maybe use PERC endpoint instead of endpoint since endpoint = has many uses.

2.       = Section 2 – MD = – typo “to to”

3.       = Section 2 – Key = Distributer “which passes keying…” is it passes or = maybe allocates or creates?

4.       = Section 2 – = Conference – here you use trusted endpoints, this relates to my = comment on endpoint above, you added a qualifier to the = endpoint.

5.       = Section 2 – Third = party – what is a “call processing” entity, it is not = defined.

6.       = Section 3.1.1 second = paragraph – “as the media distributer does not have the = ability ..” I assume this will be specified in a signaling draft, = so will we have a reference or just say it is out of = scope?

7.       = Section 3.1.2 – I = am not sure about the usage of “trusted” in this paragraph. = >From the first paragraph  I think trusted means PERC trusted, yet = the third paragraph is confusing, is it PERC trusted?

8.       = Section 3.2.1 use = pre-PERC, I think you should say non-PERC (it is not a time = definition)

9.       = Section 4.2 figure 2, = what about the MD x to MD y confidentiality.

10.   = Section 4.5 last = paragraph, is HBH key between MDs is left out of scope, if yes say it in = this paragraph.

11.   = In section 5.2 what is = the conference signaling model. Is there a central signaling entity = here? Maybe it is time to add reference to RFC4353 and maybe say = something about RFC4575.

12.   = Section 5.3 “ the = Key Distributor is responsible for knowing …”. Is the KD = responsible, I thnk the KD MUST know since the responsibility for = allowing participants is on the “focus” or “conference = manager”.

 

 

Roni = Even

 

 

 

------=_NextPart_000_033C_01D2591A.364132F0-- From nobody Mon Dec 19 09:32:33 2016 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 A1DFD129472; Mon, 19 Dec 2016 09:32:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148216875163.12781.5552096503867468014.idtracker@ietfa.amsl.com> Date: Mon, 19 Dec 2016 09:32:31 -0800 Archived-At: Cc: perc-chairs@ietf.org, ben@nostrum.com, snandaku@cisco.com, perc@ietf.org Subject: [Perc] perc - New Meeting Session Request for IETF 98 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 17:32:31 -0000 A new meeting session request has just been submitted by Suhas Nandakumar, a Chair of the perc working group. --------------------------------------------------------- Working Group Name: Privacy Enhanced RTP Conferencing Area Name: Applications and Real-Time Area Session Requester: Suhas Nandakumar Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 45 Conflicts to Avoid: First Priority: acme netvc siprec clue avtext avtcore tls rtcweb sipbrandy Second Priority: tcpinc oauth straw sipcore stir payload xrblock uta mmusic modern saag Third Priority: stox codec dispatch insipid p2psip kitten Special Requests: ---------------------------------------------------------