From nobody Thu Oct 3 04:26:39 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C90712003F for ; Thu, 3 Oct 2019 04:26:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.104.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <157010199824.16247.5838098908159584825.idtracker@ietfa.amsl.com> Date: Thu, 03 Oct 2019 04:26:38 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2019 11:26:38 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-10-03 Reviewer LC end Draft Catherine Meadows 2019-09-25 draft-ietf-payload-tsvcis-03 Kathleen Moriarty 2019-09-23 draft-ietf-isis-yang-isis-cfg-40 Tim Polk 2019-08-01 draft-ietf-acme-star-09 For telechat 2019-10-17 Reviewer LC end Draft Christian Huitema R2019-06-04 draft-ietf-anima-bootstrapping-keyinfra-28 Last calls: Reviewer LC end Draft Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Daniel Gillmor 2018-03-19 draft-gutmann-scep-14 Leif Johansson 2019-09-02 draft-ietf-tls-sni-encryption-07 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Sandra Murphy 2019-07-08 draft-ietf-i2nsf-applicability-18 Yoav Nir 2019-10-09 draft-ietf-ace-cwt-proof-of-possession-08 Magnus Nystrom 2019-10-07 draft-ietf-ipsecme-implicit-iv-07 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Hilarie Orman 2019-10-04 draft-ietf-6tisch-minimal-security-12 Vincent Roca 2019-10-14 draft-ietf-dmm-pmipv6-dlif-04 Kyle Rose 2019-10-14 draft-ietf-mboned-ieee802-mcast-problems-09 Joseph Salowey 2019-10-14 draft-ietf-dmm-distributed-mobility-anchoring-13 Rich Salz 2019-10-11 draft-ietf-httpbis-http2-tls13-02 Stefan Santesson 2019-10-10 draft-ietf-payload-rtp-ttml-02 David Waltermire 2019-08-07 draft-ietf-oauth-jwt-introspection-response-08 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Derrell Piper 2019-10-23 draft-ietf-nfsv4-rpc-tls-03 Tim Polk 2019-10-04 draft-ietf-lwig-curve-representations-08 Next in the reviewer rotation: Yaron Sheffer Rifaat Shekh-Yusef Melinda Shore Valery Smyslov Robert Sparks Takeshi Takahashi Tina Tsou Sean Turner Carl Wallace David Waltermire From nobody Sun Oct 6 11:51:33 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D85561200DF; Sun, 6 Oct 2019 11:51:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir via Datatracker To: Cc: draft-ietf-ace-cwt-proof-of-possession.all@ietf.org, ietf@ietf.org, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.104.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Yoav Nir Message-ID: <157038789080.6563.18028321376777169887@ietfa.amsl.com> Date: Sun, 06 Oct 2019 11:51:30 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-ace-cwt-proof-of-possession-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2019 18:51:31 -0000 Reviewer: Yoav Nir Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I think the document shows that security aspects have been considered and handled well. However, the document has issues with clarity and readability: For starters, the Abstract and Introduction are nearly identical. The Introduction could instead be used to explain the domain, who the "players" are and what they are trying to accomplish. Instead, section 2 introduces the terms Issuer, Presenter and Recipient with definitions that sound like the CA, the End Entity and the Relying Party from PKI, with a little OAuth terminology mixed in. There is no explanation about who this issuer is, and what the trust model is. The Security Considerations section also has some problems. Quoting the second paragraph: Applications utilizing proof of possession SHOULD also utilize audience restriction, as described in Section 3.1.3 of [CWT], as it provides additional protections. Audience restriction can be used by recipients to reject messages intended for different recipients. Why? Why is the aud claim needed with a cnf claim (but not in other cases)? Neither this document nor RFC 8392 provides insight as to when aud is appropriate. That they allow recipients to reject messages not intended for them does not sound like a security feature. Paragraph 3 says: "A recipient might not understand the "cnf" claim." This re-affirms that we need an explanation of who the parties to this protocol are. We generally don't send messages to recipients that don't understand them. Is this a closed system with known entities, or is this a protocol where the parties contact random other parties on the Internet? I'd also lose some of the Introduction to Crypto in the second-to-last paragraph. From nobody Wed Oct 9 08:28:10 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6925712082B; Tue, 8 Oct 2019 09:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1570552042; bh=0RUME0/Y+XEu7WcdLOYsebDriYJkMJ0kUR6VsADaMHY=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=HKE4GmzmmjTtiZzgJk2ntSI9V4DLUWtA31VvbrXikeMDmjPVu6lJo+ciDhwuf2m+x 3f7AbFWvIPCz8gadQGSg1jbhoLaIgnfTktuZDoRU2BCloDhr7HpIeTFXvlSnqDRm0A TS5mdxw+qemsA6ukBZkkhQyFrkyf5FT2WpYxk8Z0= X-Mailbox-Line: From new-work-bounces@ietf.org Tue Oct 8 09:27:15 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 658EA12081E; Tue, 8 Oct 2019 09:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1570552035; bh=0RUME0/Y+XEu7WcdLOYsebDriYJkMJ0kUR6VsADaMHY=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=P9OtWnkKgg9Vwaj/yj0LAIKCaPiDf0OXzKw3u/YBpbQo6Q8X/yYBNwmUlxb1/qbUE pf+/VdHZR+/B4F/y57QwzLh16k9+N8RCJJaUMYt2iKtZLSs5ZJJ9qwjNCduJsrn7Uk hhhP6QcVzbiKHCQVTNtnt4/2Lfsq9iXxrbGnLNi0= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 882B4120178 for ; Tue, 8 Oct 2019 09:27:07 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply_to: MIME-Version: 1.0 Message-ID: <157055202755.30543.8978296541709401259.idtracker@ietfa.amsl.com> Date: Tue, 08 Oct 2019 09:27:07 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Wed, 09 Oct 2019 08:28:09 -0700 Subject: [secdir] [new-work] WG Review: Lightweight Authenticated Key Exchange (lake) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 16:27:28 -0000 QSBuZXcgSUVURiBXRyBoYXMgYmVlbiBwcm9wb3NlZCBpbiB0aGUgU2VjdXJpdHkgQXJlYS4gVGhl IElFU0cgaGFzIG5vdCBtYWRlCmFueSBkZXRlcm1pbmF0aW9uIHlldC4gVGhlIGZvbGxvd2luZyBk cmFmdCBjaGFydGVyIHdhcyBzdWJtaXR0ZWQsIGFuZCBpcwpwcm92aWRlZCBmb3IgaW5mb3JtYXRp b25hbCBwdXJwb3NlcyBvbmx5LiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZQpJRVNH IG1haWxpbmcgbGlzdCAoaWVzZ0BpZXRmLm9yZykgYnkgMjAxOS0xMC0xNS4KCkxpZ2h0d2VpZ2h0 IEF1dGhlbnRpY2F0ZWQgS2V5IEV4Y2hhbmdlIChsYWtlKQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpDdXJyZW50 IHN0YXR1czogUHJvcG9zZWQgV0cKCkNoYWlyczoKICBTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW4u ZmFycmVsbEBjcy50Y2QuaWU+CgpBc3NpZ25lZCBBcmVhIERpcmVjdG9yOgogIEJlbmphbWluIEth ZHVrIDxrYWR1a0BtaXQuZWR1PgoKU2VjdXJpdHkgQXJlYSBEaXJlY3RvcnM6CiAgQmVuamFtaW4g S2FkdWsgPGthZHVrQG1pdC5lZHU+CiAgUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPgoKTWFp bGluZyBsaXN0OgogIEFkZHJlc3M6IGxha2VAaWV0Zi5vcmcKICBUbyBzdWJzY3JpYmU6IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vTGFrZQogIEFyY2hpdmU6IGh0dHBzOi8v bWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9icm93c2UvbGFrZS8KCkdyb3VwIHBhZ2U6IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZ3JvdXAvbGFrZS8KCkNoYXJ0ZXI6IGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1sYWtlLwoKUHJvYmxlbQoKQ29uc3Ry YWluZWQgZW52aXJvbm1lbnRzIHVzaW5nIE9TQ09SRSBpbiBuZXR3b3JrIGVudmlyb25tZW50cyBz dWNoIGFzCk5CLUlvVCwgNlRpU0NILCBhbmQgTG9SYVdBTiBuZWVkIGEg4oCYbGlnaHR3ZWlnaHTi gJkgYXV0aGVudGljYXRlZCBrZXkKZXhjaGFuZ2UgKExBS0UpIHRoYXQgZW5hYmxlcyBmb3J3YXJk IHNlY3VyaXR5LiAgJ0xpZ2h0d2VpZ2h0JyByZWZlcnMgdG86CgogICogcmVzb3VyY2UgY29uc3Vt cHRpb24sIG1lYXN1cmVkIGJ5IG51bWJlciBvZiByb3VuZC10cmlwcyB0byBjb21wbGV0ZSwKICAg IGJ5dGVzIG9uIHRoZSB3aXJlLCB3YWxsLWNsb2NrIHRpbWUgdG8gY29tcGxldGUsIG9yIHBvd2Vy IGNvbnN1bXB0aW9uCiAgKiB0aGUgYW1vdW50IG9mIG5ldyBjb2RlIHJlcXVpcmVkIG9uIGVuZCBz eXN0ZW1zIHdoaWNoIGFscmVhZHkgaGF2ZSBhbgogICAgT1NDT1JFIHN0YWNrCgpidXQgdGhlIExB S0UgbXVzdCBzdGlsbCBwcm92aWRlIHRoZSBzZWN1cml0eSBwcm9wZXJ0aWVzIGV4cGVjdGVkIG9m IElFVEYKcHJvdG9jb2xzLCBlLmcuLCBwcm92aWRpbmcgY29uZmlkZW50aWFsaXR5IHByb3RlY3Rp b24sIGludGVncml0eSBwcm90ZWN0aW9uLAphbmQgYXV0aGVudGljYXRpb24gd2l0aCBzdHJvbmcg d29yayBmYWN0b3IuCgpHb2FscwoKVGhpcyB3b3JraW5nIGdyb3VwIGlzIGludGVuZGVkIHRvIGJl IGEgbmFycm93bHkgZm9jdXNlZCBhY3Rpdml0eQppbnRlbmRlZCB0byBwcm9kdWNlIGF0IG1vc3Qg b25lIExBS0UgZm9yIE9TQ09SRSB1c2FnZSBhbmQgY2xvc2UuCgpUaGUgd29ya2luZyBncm91cCB3 aWxsIGNvbGxhYm9yYXRlIGFuZCBjb29yZGluYXRlIHdpdGggb3RoZXIgSUVURiBXR3MKc3VjaCBh cyBBQ0UsIENPUkUsIDZUSVNDSCwgTFBXQU4sIGFuZCBMV0lHIHRvIHVuZGVyc3RhbmQgYW5kIHZh bGlkYXRlIHRoZQpyZXF1aXJlbWVudHMgYW5kIHNvbHV0aW9uLiAgZHJhZnQtc2VsYW5kZXItYWNl LWNvc2UtZWNkaGUgaXMgYSBjYW5kaWRhdGUKc3RhcnRpbmcgcG9pbnQgZm9yIHRoZSBMQUtFIHBy b2R1Y2VkIGJ5IHRoZSBXRy4gIEFueSB3b3JrIGF2YWlsYWJsZSBmcm9tClRMUyBvciBvdGhlciBX R3MgdGhhdCBzYXRpc2ZpZXMgdGhlIGRldGVybWluZWQgcmVxdWlyZW1lbnRzIHdpbGwgYWxzbyBi ZQpldmFsdWF0ZWQgZm9yIHN1aXRhYmlsaXR5LCBidXQgZG9lcyBub3QgcHJlY2x1ZGUgdGhlIFdH IGZyb20gZnJlZWx5CnNlbGVjdGluZyBpdHMgcHJlZmVycmVkIExBS0UgZm9yIE9TQ09SRS4KClBy b2dyYW0gb2YgV29yawoKVGhlIGRlbGl2ZXJhYmxlcyBvZiB0aGlzIFdHIGFyZToKCjEuIERlc2ln biByZXF1aXJlbWVudHMgb2YgdGhlIGxpZ2h0d2VpZ2h0IGF1dGhlbnRpY2F0ZWQga2V5IGV4Y2hh bmdlCnByb3RvY29sIGZvciBPU0NPUkUgKHRoaXMgZHJhZnQgd2lsbCBub3QgYmUgcHVibGlzaGVk IGFzIGFuIFJGQyBidXQgd2lsbCBiZQp1c2VkIHRvIGRyaXZlIFdHIGNvbnNlbnN1cyBvbiB0aGUg ZGVsaXZlcmFibGUgKDIpKQoKMi4gU3BlY2lmeSBhIGxpZ2h0d2VpZ2h0IGF1dGhlbnRpY2F0ZWQg a2V5IGV4Y2hhbmdlIHByb3RvY29sIHN1aXRhYmxlIGZvcgp1c2UgaW4gY29uc3RyYWluZWQgZW52 aXJvbm1lbnRzIHVzaW5nIE9TQ09SRQoKTWlsZXN0b25lczoKCiAgTWFyIDIwMjAgLSBXR0xDIG9u IHJlcXVpcmVtZW50cyBkb2N1bWVudAoKICBNYXkgMjAyMCAtIEFkb3B0IHNvbHV0aW9uIGRvY3Vt ZW50IG9yIGRlZmVyIHRvIGV4aXN0aW5nIGV4dGVybmFsIHNvbHV0aW9uCiAgZG9jdW1lbnQKCiAg U2VwIDIwMjAgLSBzb2x1dGlvbiBkb2N1bWVudCB0byBJRVNHIChpZiBuZWVkZWQpCgoKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV3LXdvcmsgbWFpbGlu ZyBsaXN0Cm5ldy13b3JrQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV3LXdvcmsK From nobody Wed Oct 9 08:28:17 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5A0120227; Wed, 9 Oct 2019 08:11:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1570633882; bh=xtR0xox8I4XCqHEuwLX7JFMnvSIsO+OUeI8OXf1TavE=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=HiYPtORbyy8XNOVzZH0bgtwUifzOpOQVcTrEjBgC7woe00AmSY3DP22FGwW5M7jw+ MJoaxjkOsaAcVNC2Iqpbo9sGpNc3vrBUuyvT9vASTKR2gc6CJqpvOX24dPeN6GuuOs mKram96Yao7f8lv1ak+stxCqGDIS8YrFAmnlVoww= X-Mailbox-Line: From new-work-bounces@ietf.org Wed Oct 9 08:11:21 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A835120110; Wed, 9 Oct 2019 08:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1570633881; bh=TONoONCBjQ4Gq35HY2RCsw+9JuGh86aFAi/Yk0gNCwM=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=J0cXVmXx1MrJqelX+UszTGQixKNE5WWz070Qj+xPUXrtT4RmPSD4LWmQfyg7Rda5M 2+dRF5lKJngTtQbH8daMFTpEsLoZDMU0pYPWtIsbCGuddfzkB0xQ+dfUYLSw3fUXD9 CUg+tU9LaN0LJKjInH23h3rmjk9J8XDh+ePc5WB0= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4588120121 for ; Wed, 9 Oct 2019 08:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, 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 Um2xZPg3_X4W for ; Wed, 9 Oct 2019 08:11:17 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 40A4B12010E for ; Wed, 9 Oct 2019 08:11:17 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id h126so2505957qke.10 for ; Wed, 09 Oct 2019 08:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version:thread-index :content-language; bh=U6tUyjrjK7ICddvaYNt6UsxhjfkGQgz/1PCh8wUyLls=; b=VsgorlOuJjZ3/Jvf5k9E4OjNz2f2OOwM8skJlhAa0uZR243A9lXhFk7Bzsu0VnSGls RnAtCkeriEyeZ63/jJgb/IgKQy7SR+GqoW10zGfL7CLIUmm7o7s8ykXrgqWIIEclt5Dr RX5mfPHRvJi8AfiiOBG1gDMfQduJ+SZbws8LElZ0v0zu/YZ3bpFV4pkYkqbCGwBD2YyP +htIMe2w+HX2u4KY6eGWPk7hRPwp6yrjQ00S/YvmuUkntLBNdTM7Fc2zg/LUXZFEPQTE uU14TUstkaam0RRh0RS/u0ONzG0qf38emDHcB66ic86Nec/I8azZi9w5GY0SymOeNjJy 694w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :thread-index:content-language; bh=U6tUyjrjK7ICddvaYNt6UsxhjfkGQgz/1PCh8wUyLls=; b=KeWCNG+NLHkA5OLkJc1O45nZ9YjXPCTYAlsvKh15le0FgDfbw3Zm7JXpGM1p8T0umh SyVRfijbNpxay5ZHuBgwcHGyzYsiW/IwfG7MuAFdEha1PywqFWPfP8vz8ygRmtnCYi0Q LdDiB4FnhFd2Lw4oqt2s+kGFkOCvkuN7sNonfuRM5FzKXwNfMDRzRtaWpzNykn/RAWbk FukLLG4WLiI4QHezRJjeqmIv3GAjgIwP3MlrfQwGJSvwUdXHlOh5K9r1cabTTxyoCpji Hhxs88Kq3IxTANf1nltDwbT2N4LjRTv/P1LAYjxe/FC35RXhwpdwMeebfJXbpeEqazql 1NhQ== X-Gm-Message-State: APjAAAXeCSxXjzQC/UW555u6AdeJMwPkIxu/CvDJ0BY/3e4q8vQXWjSK 4ubB5Lkkq97nEL7B7vbNqZg= X-Google-Smtp-Source: APXvYqyb3jv5vgQ+rdW3Ig5WzGLdXkY6AqhXke1AcqpBRWoNEv+o8vcY1NlLzwNwQyzvSjhmcLCF7g== X-Received: by 2002:ae9:f714:: with SMTP id s20mr3990849qkg.262.1570633876222; Wed, 09 Oct 2019 08:11:16 -0700 (PDT) Received: from DESKTOP6VF5FH7 ([152.208.106.92]) by smtp.gmail.com with ESMTPSA id t17sm1732501qtt.57.2019.10.09.08.11.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Oct 2019 08:11:15 -0700 (PDT) From: To: Date: Wed, 9 Oct 2019 11:11:14 -0400 Message-ID: <024d01d57eb3$cc5adbd0$65109370$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdV+s8qYJ7N18/YcQBm8cUAv3EHB1w== Content-Language: en-us Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Cc: "'Stanley, Dorothy'" , p.nikolich@ieee.org Content-Type: multipart/mixed; boundary="===============0102764183574553125==" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Wed, 09 Oct 2019 08:28:09 -0700 Subject: [secdir] [new-work] IEEE 802 Nov 2019 PARs Under Consideration X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2019 15:11:24 -0000 This is a multipart message in MIME format. --===============0102764183574553125== Content-Type: multipart/alternative; boundary="----=_NextPart_000_024E_01D57E92.4549D810" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_024E_01D57E92.4549D810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, The following Project Authorization Requests (PARs) will be considered at the IEEE 802 Nov 2019 Plenary: * 802.3ct -Amendment - 100 Gb/s Operation over DWDM systems , PAR modification and CSD modification * 802.3cw - Amendment - 400 Gb/s Operation over DWDM systems, PAR and CSD * 802.3cx - Amendment - Improved Precision Time Protocol (PTP) timestamping accuracy, PAR and CSD * 802.16t - Amendment - Fixed and Mobile Wireless Access in Channel Bandwidth up to 100 kHz, PAR and CSD The PARs and ICAID can be found at http://www.ieee802.org/PARs.shtml along with the supporting IEEE 802 Criteria for Standards Development, or CSD, (which includes the 5 criteria, i.e. the explanations of how they fit the IEEE 802 criteria for initiating new work). Any comments on a proposed PAR / ICAID should be sent to the Working Group chair identified on the respective document to be received by 6:30 PM HAST (Hawaii-Aleutian Time Zone), Tuesday, Nov 12. Regards, John D'Ambrosia Recording Secretary, IEEE 802 LMSC ------=_NextPart_000_024E_01D57E92.4549D810 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

The following = Project Authorization Requests (PARs) will be considered at the IEEE = 802 Nov 2019 = Plenary:

  • 802.3ct = -Amendment - 100 Gb/s Operation over DWDM systems ,  PAR modification and CSD modification
  • 802.3cw - = Amendment - 400 Gb/s Operation over DWDM systems, PAR and CSD
  • 802.3cx - = Amendment - Improved Precision Time Protocol (PTP) timestamping = accuracy, PAR and CSD
  • 802.16t - = Amendment - Fixed and Mobile Wireless Access in Channel Bandwidth up to = 100 kHz, PAR and CSD

The = PARs and ICAID can be found at http://www.ieee802.org/PARs.sh= tml along with the supporting IEEE 802 Criteria for Standards = Development, or CSD, (which includes the 5 criteria, i.e. the = explanations of how they fit the IEEE 802 criteria for initiating new = work).

Any = comments on a proposed PAR / ICAID should be sent to the Working Group = chair identified on the respective document to be received by 6:30 PM = HAST (Hawaii-Aleutian Time Zone), Tuesday, Nov 12.  =

Regards,

John = D’Ambrosia

Recording Secretary, IEEE 802 LMSC =

 

------=_NextPart_000_024E_01D57E92.4549D810-- --===============0102764183574553125== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============0102764183574553125==-- From nobody Thu Oct 10 04:56:07 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B87C120BD7 for ; Thu, 10 Oct 2019 04:56:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <157070856523.20381.18255851461714637440.idtracker@ietfa.amsl.com> Date: Thu, 10 Oct 2019 04:56:05 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 11:56:05 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-10-17 Reviewer LC end Draft Russ Housley R2019-03-15 draft-ietf-regext-bundling-registration-11 Christian Huitema R2019-06-04 draft-ietf-anima-bootstrapping-keyinfra-28 Magnus Nystrom 2019-10-07 draft-ietf-ipsecme-implicit-iv-07 Rich Salz 2019-10-11 draft-ietf-httpbis-http2-tls13-02 Stefan Santesson 2019-10-10 draft-ietf-payload-rtp-ttml-03 Last calls: Reviewer LC end Draft Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Daniel Gillmor 2018-03-19 draft-gutmann-scep-14 Leif Johansson 2019-09-02 draft-ietf-tls-sni-encryption-08 Catherine Meadows 2019-09-25 draft-ietf-payload-tsvcis-03 Kathleen Moriarty 2019-09-23 draft-ietf-isis-yang-isis-cfg-41 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Sandra Murphy 2019-07-08 draft-ietf-i2nsf-applicability-18 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Hilarie Orman 2019-10-04 draft-ietf-6tisch-minimal-security-12 Tim Polk 2019-08-01 draft-ietf-acme-star-09 Vincent Roca 2019-10-14 draft-ietf-dmm-pmipv6-dlif-04 Kyle Rose 2019-10-14 draft-ietf-mboned-ieee802-mcast-problems-09 Joseph Salowey 2019-10-14 draft-ietf-dmm-distributed-mobility-anchoring-13 Yaron Sheffer 2019-10-18 draft-ietf-ace-coap-est-15 Rifaat Shekh-Yusef 2019-10-18 draft-ietf-pce-association-diversity-10 David Waltermire 2019-08-07 draft-ietf-oauth-jwt-introspection-response-08 Paul Wouters R2019-10-18 draft-ietf-taps-transport-security-09 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Derrell Piper 2019-10-23 draft-ietf-nfsv4-rpc-tls-03 Tim Polk 2019-10-04 draft-ietf-lwig-curve-representations-08 Next in the reviewer rotation: Melinda Shore Valery Smyslov Robert Sparks Takeshi Takahashi Tina Tsou Sean Turner Carl Wallace David Waltermire Samuel Weiler Brian Weis From nobody Thu Oct 10 08:03:06 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FEC120129; Thu, 10 Oct 2019 08:02:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley via Datatracker To: Cc: draft-ietf-regext-bundling-registration.all@ietf.org, ietf@ietf.org, regext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Russ Housley Message-ID: <157071977760.20403.2267644082355726284@ietfa.amsl.com> Date: Thu, 10 Oct 2019 08:02:57 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-regext-bundling-registration-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 15:02:58 -0000 Reviewer: Russ Housley Review result: Has Issues I reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Document: draft-ietf-regext-bundling-registration-11 Reviewer: Russ Housley Review Date: 2019-10-10 IETF LC End Date: 2019-03-15 IESG Telechat date: 2019-10-17 Summary: Has Issues Major Concerns: The Abstract ans Section 1 say: "This is a non-standard proprietary extension." I understand that this is not a standards track document, so the "non-standard" part makes sense. However, what is the point of publishing a "proprietary" extension as an RFC. I would hope that interoperable implementations is the goal of publication. In Section 1, the use of "policy-wise" is unclear. Is this registration policy or something else? Minor Concerns: None. Nits: Section 1: s/label(LABEL)/label (LABEL)/ - s/(V-tld);/(V-tld)./ In addition, there are several places in the upper left corner of the title page: Internet Engineering Task Force From nobody Thu Oct 10 12:35:54 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF6612006E; Thu, 10 Oct 2019 12:35:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rich Salz via Datatracker To: Cc: draft-ietf-httpbis-http2-tls13.all@ietf.org, ietf@ietf.org, ietf-http-wg@w3.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Rich Salz Message-ID: <157073614766.20352.7386271093609618593@ietfa.amsl.com> Date: Thu, 10 Oct 2019 12:35:47 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-httpbis-http2-tls13-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 19:35:48 -0000 Reviewer: Rich Salz Review result: Ready This document is short and to the point; it's ready. Section 3 could be titled "How many ways do I have to tell you no?" but the draft is okay without that change. From nobody Thu Oct 10 12:46:48 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4500E1200F6; Thu, 10 Oct 2019 12:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.478 X-Spam-Level: X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sygIf7_YMZOb; Thu, 10 Oct 2019 12:46:39 -0700 (PDT) Received: from mail-io1-f45.google.com (mail-io1-f45.google.com [209.85.166.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40049120089; Thu, 10 Oct 2019 12:46:36 -0700 (PDT) Received: by mail-io1-f45.google.com with SMTP id c25so16347207iot.12; Thu, 10 Oct 2019 12:46:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/3596EEaYjdjvIcDHbrpvQIRQ+YoNJvCHRF223+lH0E=; b=U/PVRhwNeRlspMIS1SoA/ePXa+5lbx2ujXCg2ImGfrHyAczTMlMKAplzJusj6Bm+aZ OQF53as77v5df0maluhrNskJogcrLzHMdaBGWRVRiZ0t467JP2M7wcUsYZvFUgiFvHGG DMtv5bvwfJWFKrSuvkMW1FEf6cPZsHyTCQBBBK7O4+0gi4kE5Q2U0XXf8aGDW6Iyzkva QeLxla2X6NjBV4XFFz8Rb1xPWi2xVnGReZ3Iq4P50AbcoVUd7i2oGmaPan3Uxd54AfJh xNNPcs0e+Kqd9YH83CEPmIUzIzufziU6ypq3W/5bZlkcYRpn6ld60Q4r/Zk9YcVx4Yeq fSIQ== X-Gm-Message-State: APjAAAVp1mCp68Z4tEC/OKUAeG8sYykwHp0bS5bI/zwKZ3JcFyXrrOke eY/MXErNCsRRAyWpmbqRsX5dPr57rcGCZv/tIDs= X-Google-Smtp-Source: APXvYqzTHcDc/5eQMxoWl6amvXt8+U4Nzm+pzAu/1hW9mUL4iB/j63WUlVZY8iJQ1SCCnWItRwVrT7+bpekIRpnCexA= X-Received: by 2002:a02:a584:: with SMTP id b4mr12531441jam.16.1570736795093; Thu, 10 Oct 2019 12:46:35 -0700 (PDT) MIME-Version: 1.0 References: <157073614766.20352.7386271093609618593@ietfa.amsl.com> In-Reply-To: <157073614766.20352.7386271093609618593@ietfa.amsl.com> From: Barry Leiba Date: Thu, 10 Oct 2019 21:46:24 +0200 Message-ID: To: Rich Salz Cc: IETF SecDir , draft-ietf-httpbis-http2-tls13.all@ietf.org, IETF discussion list , HTTP Working Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-httpbis-http2-tls13-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 19:46:40 -0000 > Section 3 could be titled "How many ways do I have to tell you no?" but the > draft is okay without that change. :-) Thanks, Rich, for the review. Barry From nobody Thu Oct 10 15:02:00 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 300AA120115; Thu, 10 Oct 2019 15:01:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Catherine Meadows via Datatracker To: Cc: ietf@ietf.org, avt@ietf.org, draft-ietf-payload-tsvcis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Catherine Meadows Message-ID: <157074490209.20360.17786614202331955424@ietfa.amsl.com> Date: Thu, 10 Oct 2019 15:01:42 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-payload-tsvcis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 22:01:49 -0000 Reviewer: Catherine Meadows Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a payload format for the Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) speech coder data when it is sent over RTP. The security considerations section is very thorough. The authors point out the appropriate RTP RFC’s for relevant security considerations, and also discuss the likelihood of the TSVCIS data being used to launch a denial of service attack. There are two places where I think things should be further clarified. I believe these count more as nits than issues. 1. This RTP payload format and the TSVCIS decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing How do you conclude that they do not have any significant non-uniformity? I would recommend either providing a reference or some other evidence, or qualify it somehow, e.g. “To the best of our knowledge, …” or “in our experience ..” 2. The relevance of the last sentence, about VAD and its effect on bitrates, is not clear. I would recommend adding a sentence explaining that. You should also spell out VAD as well as give the acronym. From nobody Sat Oct 12 12:15:57 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4C91200B1; Fri, 11 Oct 2019 11:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1570817254; bh=jse7Csd5HluvWSD3CclCeBYDxqfvb2o3Q9bUlAQ5OS0=; h=From:To:References:In-Reply-To:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=jSO7xH+PZ28ByUs8haNFwlcutO36FmUr/+CWhXAV/tQypWb3tmcHRXKyFzTKv7Pa5 g/64oyGl7WhV4hOepnM95ctwUbvp6vyPWjamUM+uC/LDMS0bC7uuflbo59Yv0dT7pW OHu4iAVYoABQnW1y1ozAgi4qKh33GyneaeBwl0eo= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Oct 11 11:07:34 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF81112008D; Fri, 11 Oct 2019 11:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1570817253; bh=peNtLv1sj3tK458BPeI1AnN8v03UQvzXplsl2TJGrjg=; h=From:To:References:In-Reply-To:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=mkPOK/17cgDGam6iorGcbqvQmjD9hWUBv6SFxIYQVvLR8O62R7GswFzsJUF2JJD20 7ROuXwBBM0oIfHgWRhxFKWf4cIQLJ5xG134p2YrBpsmpYp38d4RgE4KwDU++Xjb4V+ 9D34kXX+kdknhsnwmkhUGwOdO5qb/8Ls6U4zcVJ0= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8198A120018 for ; Fri, 11 Oct 2019 11:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, 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 fPJQrHgHiBCk for ; Fri, 11 Oct 2019 11:07:28 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 81E8F12006A for ; Fri, 11 Oct 2019 11:07:28 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id u22so15078496qtq.13 for ; Fri, 11 Oct 2019 11:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=Gf/G0Kcb4bo8poKaIcJa4sal1lAuYhSWlRHMZ+PzviI=; b=mTpQcdcCqvmS147EbDFWctdjC9qnnsBjmDGML/rkLb/tWlF/X8cedL4akLeWOFZ0pd NOWd5Cr29M17Nd144nnk/wT6oDrFcCAf7c22BljVD5TAnE+HKlu7CzVB5Om4fYh0Ly+0 KHJmJgmvDehrGituEJho9yUbUrP20JV5U5WpStLoddFm4DdmxFeKGXUbN5fkP9MXVkqt vRqlqdxBWkHuqQt+391z0r/RidNx7FKOYcM1o1E7/RcFe10v032FqwbaWP2XVYstqt6D L/5g5Ns8xkryt9u7l17mhe90WQ05I3ClibkBjLKugtm1H3RrNrNSIwl8ei2VOCYgEz+8 pszQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=Gf/G0Kcb4bo8poKaIcJa4sal1lAuYhSWlRHMZ+PzviI=; b=phDyQa7GhjPQ5Gou6ZCKuT82PMo9DUFfvpvnmNqyj0W2JrPF7f/UN5VbD80OvNu+jB liocR6dKGDDFfQ+1KLbWlaQKxCKF+w6JQZML231Xyu0y6vU16xpwq/lB5nLnAxgP43wk 2inSfA2uiOYy232Jh0WX/f9Ay8T6lS3jr4S/s2gWQvc8YAeaAFgREW1NNdpCYm5zIni3 jiCqTOah0tv1ctQ23y0T6Yqakp46kKsXPR4R4KrUTjysVrdp5LiVz7zn7v8nxueJiM7U abKYJZQHPEpG5uQD+uGkBZhSYXYXJoSq12f8SKw486m7fb+NV6+63DLoKsXPdgqfCXIG +yrA== X-Gm-Message-State: APjAAAXXAqK+J70odCjYoiaOeNxYn7+l2yYp0vbBiXNPy9MAEnizYG/7 luYIgjo8E4pNFPEBaVQzKQLqeF/j X-Google-Smtp-Source: APXvYqwCXAKXGk+crMM8jcTj02/vRwhwNlC91/1kbxluwoJ/hPeWON26tsHiJ5+NX2ldyM9Vh42qvA== X-Received: by 2002:ac8:197d:: with SMTP id g58mr46311qtk.86.1570817247453; Fri, 11 Oct 2019 11:07:27 -0700 (PDT) Received: from DESKTOP6VF5FH7 ([152.208.106.92]) by smtp.gmail.com with ESMTPSA id c204sm5151630qkb.90.2019.10.11.11.07.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Oct 2019 11:07:26 -0700 (PDT) From: To: References: <024d01d57eb3$cc5adbd0$65109370$@gmail.com> In-Reply-To: <024d01d57eb3$cc5adbd0$65109370$@gmail.com> Date: Fri, 11 Oct 2019 14:07:24 -0400 Message-ID: <0e9001d5805e$bdecedc0$39c6c940$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGD+1cMHO6W1zYPbgQxkJ5P9flpqaf4xcAw Content-Language: en-us Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Cc: "'Stanley, Dorothy'" , p.nikolich@ieee.org Content-Type: multipart/mixed; boundary="===============7683536592850190518==" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Sat, 12 Oct 2019 12:15:53 -0700 Subject: Re: [secdir] [new-work] IEEE 802 Nov 2019 PARs Under Consideration X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2019 18:07:37 -0000 This is a multipart message in MIME format. --===============7683536592850190518== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E91_01D5803D.36DCD460" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0E91_01D5803D.36DCD460 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, The following Project Authorization Requests (PARs) will be considered at the IEEE 802 Nov 2019 Plenary: * 802f Amendment : YANG Data Model for EtherTypes, PAR and CSD * 802.1AEdk Amendment: MAC Privacy protection, PAR and CSD * 802.1CS Standard - Link-local Registration Protocol, PAR modification and CSD modification * 802.3ct -Amendment - 100 Gb/s Operation over DWDM systems, PAR modification and CSD modification * 802.3cw - Amendment - 400 Gb/s Operation over DWDM systems, PAR and CSD * 802.3cx - Amendment - Improved Precision Time Protocol (PTP) timestamping accuracy, PAR and CSD * 802.15.7a - Amendment - Defining High Data Rate Optical Camera Communications (OCC), PAR and CSD * 802.16t - Amendment - Fixed and Mobile Wireless Access in Channel Bandwidth up to 100 kHz, PAR and CSD The PARs and ICAID can be found at http://www.ieee802.org/PARs.shtml along with the supporting IEEE 802 Criteria for Standards Development, or CSD, (which includes the 5 criteria, i.e. the explanations of how they fit the IEEE 802 criteria for initiating new work). Any comments on a proposed PAR / ICAID should be sent to the Working Group chair identified on the respective document to be received by 6:30 PM HAST (Hawaii-Aleutian Time Zone), Tuesday, Nov 12. Regards, John D'Ambrosia Recording Secretary, IEEE 802 LMSC From: jdambrosia@gmail.com Sent: Wednesday, October 9, 2019 11:11 AM To: new-work@ietf.org Cc: p.nikolich@ieee.org; 'Stanley, Dorothy' Subject: IEEE 802 Nov 2019 PARs Under Consideration All, The following Project Authorization Requests (PARs) will be considered at the IEEE 802 Nov 2019 Plenary: * 802.3ct -Amendment - 100 Gb/s Operation over DWDM systems , PAR modification and CSD modification * 802.3cw - Amendment - 400 Gb/s Operation over DWDM systems, PAR and CSD * 802.3cx - Amendment - Improved Precision Time Protocol (PTP) timestamping accuracy, PAR and CSD * 802.16t - Amendment - Fixed and Mobile Wireless Access in Channel Bandwidth up to 100 kHz, PAR and CSD The PARs and ICAID can be found at http://www.ieee802.org/PARs.shtml along with the supporting IEEE 802 Criteria for Standards Development, or CSD, (which includes the 5 criteria, i.e. the explanations of how they fit the IEEE 802 criteria for initiating new work). Any comments on a proposed PAR / ICAID should be sent to the Working Group chair identified on the respective document to be received by 6:30 PM HAST (Hawaii-Aleutian Time Zone), Tuesday, Nov 12. Regards, John D'Ambrosia Recording Secretary, IEEE 802 LMSC ------=_NextPart_000_0E91_01D5803D.36DCD460 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

The following = Project Authorization Requests (PARs) will be considered at the IEEE = 802 Nov 2019 = Plenary:

  • 802f = Amendment : YANG Data Model for EtherTypes, PAR and CSD
  • 802.1AEdk = Amendment: MAC Privacy protection, PAR and CSD
  • 802.1CS = Standard - Link-local Registration Protocol, PAR modification and CSD modification
  • 802.3ct = -Amendment - 100 Gb/s Operation over DWDM systems,  PAR modification and CSD modification
  • 802.3cw - = Amendment - 400 Gb/s Operation over DWDM systems, PAR and CSD
  • 802.3cx - = Amendment - Improved Precision Time Protocol (PTP) timestamping = accuracy, PAR and CSD
  • 802.15.7a = - Amendment - Defining High Data Rate Optical Camera Communications = (OCC), PAR and CSD
  • 802.16t - = Amendment - Fixed and Mobile Wireless Access in Channel Bandwidth up to = 100 kHz, PAR and CSD

The = PARs and ICAID can be found at http://www.ieee802.org/PARs.sh= tml along with the supporting IEEE 802 Criteria for Standards = Development, or CSD, (which includes the 5 criteria, i.e. the = explanations of how they fit the IEEE 802 criteria for initiating new = work).

Any = comments on a proposed PAR / ICAID should be sent to the Working Group = chair identified on the respective document to be received by 6:30 PM = HAST (Hawaii-Aleutian Time Zone), Tuesday, Nov 12.  =

Regards,

John = D’Ambrosia

Recording Secretary, IEEE 802 LMSC =

 

 

From: jdambrosia@gmail.com = <jdambrosia@gmail.com>
Sent: Wednesday, October 9, 2019 = 11:11 AM
To: new-work@ietf.org
Cc: = p.nikolich@ieee.org; 'Stanley, Dorothy' = <dorothy.stanley@hpe.com>
Subject: IEEE 802 Nov 2019 = PARs Under Consideration

 

All,

The following = Project Authorization Requests (PARs) will be considered at the IEEE = 802 Nov 2019 = Plenary:

  • 802.3ct = -Amendment - 100 Gb/s Operation over DWDM systems ,  PAR modification and CSD modification
  • 802.3cw - = Amendment - 400 Gb/s Operation over DWDM systems, PAR and CSD
  • 802.3cx - = Amendment - Improved Precision Time Protocol (PTP) timestamping = accuracy, PAR and CSD
  • 802.16t - = Amendment - Fixed and Mobile Wireless Access in Channel Bandwidth up to = 100 kHz, PAR and CSD

The = PARs and ICAID can be found at http://www.ieee802.org/PARs.sh= tml along with the supporting IEEE 802 Criteria for Standards = Development, or CSD, (which includes the 5 criteria, i.e. the = explanations of how they fit the IEEE 802 criteria for initiating new = work).

Any = comments on a proposed PAR / ICAID should be sent to the Working Group = chair identified on the respective document to be received by 6:30 PM = HAST (Hawaii-Aleutian Time Zone), Tuesday, Nov 12.  =

Regards,

John = D’Ambrosia

Recording Secretary, IEEE 802 LMSC =

 

------=_NextPart_000_0E91_01D5803D.36DCD460-- --===============7683536592850190518== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============7683536592850190518==-- From nobody Sat Oct 12 21:53:51 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB9F120100; Sat, 12 Oct 2019 21:53:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Huitema via Datatracker To: Cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, ietf@ietf.org, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Christian Huitema Message-ID: <157094241575.1368.11692727174528463365@ietfa.amsl.com> Date: Sat, 12 Oct 2019 21:53:35 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-anima-bootstrapping-keyinfra-28 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2019 04:53:36 -0000 Reviewer: Christian Huitema Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is ready with nits. The draft-28 is much improved from the version that I originally reviewed, or even from the intermediate version 20. The issues flagged in the original review are now addressed. The draft now develops options for "nonceless vouchers", which allows for offline onboarding scenario and addresses one of the concerns expressed in my initial review. It also develops a TOFU option for MASA servers, which has different security properties than the initial design. That may be a useful mode of operation, and the related security issues are discussed in subsection 11.4 of the security consideration sections. Draft 28 addresses scenarios like "death of a manufacturer" that were flagged in the first reviews. Generally, I find the revised security consideration section much more developed and comprehensive than in the original drafts. Draft 28 adds an extended privacy consideration section, which is welcome. On the other hand, the authors may consider toning down the commentary text in section 10.3, "The so-called "call-home" mechanism that occurs as part of the BRSKI-MASA connection standardizes what has been deemed by some as a sinister mechanism for corporate oversight of individuals." That text was already in draft-20, but feels a bit too petulant for standard track RFC. I flagged a couple of technical nits: I have a minor concern with the text on TLS usage in section 5.1 and 5.2. In section 5.1, BRSKI-EST TLS establishment details, I read "Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is REQUIRED." Does that mean that BRSKI-EST TLS servers MAY reject connection attempts using a TLS version lower than 1.2, or maybe that pledges SHOULD refuse connections if the server tries to negotiate a TLS version lower than 1.2? We have experience in other deployments that even "low end" vendors will not cheap lower security solutions if that leads to interop failures, and that having at least some implementations being strict in what they accept is a good way to raise the bar for everybody. Same issue in section 5.2, regarding BRSKI MASA connections. In section 5.4.1, "This document does not make a specific recommendation" (regarding whether to use public PKI, DANE, or pinned certificates for MASA authentication. That's probably fine from a security point of view, but the absence of at least one recommended solution ay well end up causing interesting interoperability issues. Editorial Nits: In section 1.4, the text says "The major intended beneficiary is that it possible to use the credentials deployed by this protocol to secure the Autonomic Control Plane (ACP) ([I-D.ietf-anima-autonomic-control-plane])." I think you mean "benefit" instead of "beneficiary". In section 2.3.1, the text says "The serialNumber fields is defined in [RFC5280], and is a SHOULD field in [IDevID]." I understand that you mean that according to [IDevId] the field SHOULD be present, but calling that a "SHOULD field" is jargon. In section 7.4.1, I read that "A MASA has the option of not including a nonce is in the voucher, and/or not requiring one to be present in the voucher-request." The "is in" looks like some kind of typo. In section 10.2, typo, "arbtirary" for "arbitrary". From nobody Sun Oct 13 04:53:50 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1705212008C; Sun, 13 Oct 2019 04:53:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rifaat Shekh-Yusef via Datatracker To: Cc: pce@ietf.org, ietf@ietf.org, draft-ietf-pce-association-diversity.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Rifaat Shekh-Yusef Message-ID: <157096761403.20776.1628036131569931986@ietfa.amsl.com> Date: Sun, 13 Oct 2019 04:53:34 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-pce-association-diversity-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2019 11:53:34 -0000 Reviewer: Rifaat Shekh-Yusef Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready. This document adds new extension to the PCEP protocol to allow a PCC to request the PCE to make sure that an LSP belongs to a disjoint group. The PCEP is an existing protocol with well-defined security properties, and this document builds on that. The security section discusses the consequences if this new mechanism is abused and the attacker is able to inject a fake LSP into a disjoint group. The security section also discusses the potential leak of non-sensitive information and the fact that this new mechanism could make it easier on the attacker to obtain this information if the protocol is not secured properly. The document this recommends the use of TLS to secure the interface between the PCC and the PCE to address the above potential issues. From nobody Sun Oct 13 06:02:19 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F931120044; Sun, 13 Oct 2019 06:02:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer via Datatracker To: Cc: draft-ietf-ace-coap-est.all@ietf.org, ietf@ietf.org, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Yaron Sheffer Message-ID: <157097172245.20767.1326966836276837764@ietfa.amsl.com> Date: Sun, 13 Oct 2019 06:02:02 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-ace-coap-est-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2019 13:02:03 -0000 Reviewer: Yaron Sheffer Review result: Has Issues This document defines a new profile for EST (simple certificate enrollment) for restricted devices, to be run on top of CoAP and DTLS, instead of the usual HTTP and TLS. Overall, I tend to be suspicious of "restricted" profiles, and this is a case in point. An implementation of DTLS is no simpler than TLS and most would probably support both protocols. And basically anything supports HTTP. So why would it make sense to define a whole new profile just to avoid using TCP very rarely (say, for daily certificate enrollment), when this profile even needs to include its own fragmentation/buffering mechanisms because the ASN.1 payloads are too long? In other words, we are introducing new and additional complexity with little or no performance gain. - 2. Only certificate-based client authentication is supported. Hopefully some time soon we'll be able to use PAKE here, to bootstrap the PKI. - 4. "Crypto agility is important" - this statement is somewhat meaningless: do we require more than one cipher suite, which would ensure some level of agility? - Also, when we say "Sec. 4.4 of RFC 7925" do we mean *only* Sec. 4.4 or also the subsections: 4.4.1 etc. - "in DTLS 1.3 the Supported Elliptic Curves extension has been renamed to Supported Groups". This is probably true for an older version of the draft, I couldn't find anything to support it in -32. - "the Finished message must be computed" - this whole paragraph is unclear. Are we changing the Finished/MAC computation in DTLS (if so, this must be pointed out very clearly)? Or are we explaining a point about channel binding (if we are, this doesn't come across). - Similarly for the following paragraph: is this a performance optimization, or a change to DTLS? And by the way, why are standard session resumption mechanisms not used? - I don't see value in the short EST URI paths given that most of the "weight" is in ASN.1 data, and the paths are negligible in comparison. Moreover, if the paths are different, shouldn't this document formally UPDATE RFC 7030? I think it is no longer a profile. - Non-default server port: the examples include an IPv6 address in addition to the port number. Is there a way to use relative URIs (omitting the IP address) but include a port number? The server may not know its own IP address (IPv4 with NAT) or the address may be dynamic. - The server MUST support the default /.well-known/est root resource, but then in the next sentence we discuss non-default URIs. In the case of the server having multiple "identities" (the main purpose of the "arbitrary label", AFAIU), the root resource is confusing - which identity is it associated with? And then how is discovery managed for each identity, and is there a way to discover the identities? - There is nowhere in this document a full formal definition of content type TBD287 (a single cert). - Content type negotiation: I can see how it works for enrollment. But in the case of /cacerts, if the server has a list of certs in its explicit TA store (e.g. to support rollover), how can TBD287 (a single cert) make sense? - It is mighty confusing to denote "content format" by "ct" (presumably, this stands for "content type"). - "ASN.1 encoded in binary format" - I think this should be, "DER-encoded ASN.1, in its native binary form". - Please don't use "he" and "she" for the server and the client. Both are merely "it". - "The Registrar MUST authenticate and optionally authorize the client requests" - this statement is too weak. The Registrar must also ensure that clients only send CSRs that pertain to their authenticated identity (channel binding), even when POP-linking is not used. I think this is worthy of its own subsection, describing the validation required for each particular EST flow. - The following paragraph is not clear: is PoP-linking useful/recommended/mandated in this scenario? IMO there should be some 2119 word regarding server-side validation of the tls-unique. - "Table 1 contains the URI mappings between EST-coaps and EST that the Registrar MUST adhere to." But the immediately preceding paragraph describes a case where a server-side generation on the EST-coaps side is mapped to client-side generation on the EST-HTTPS side, which is not a Table 1 mapping! - "the encrypted CMS EnvelopedData blob MUST be converted at the Registrar" - can this be done without decrypting the blob, IOW must the Registrar be privy to the key wrapping key? - The Registrar must support resource discovery: does it mean that resource discovery messages are simply proxied upstream, or that the Registrar presents a simpler resource structure (maybe with no discovery) to its clients while performing discovery upstream? - Security Considerations: there's a long discussion about replacing the implicit TAs with explicit ones. If we (rightly) mandate that the client re-verify the server's cert after getting the /certs response, we are losing most of the minor performance gain that keeping the DTLS connection open might have given us. So why not unambiguously mandate the simpler "MUST close the connection after /certs" instead? Besides, /cacerts is a very rare operation. Why optimise it at all? - "Improper CSR requests" - what are they? What's the server supposed to do? Please give a reference. - A.3, response: I may be missing something, but the binary blob "3081...9fd9" does not parse as PKCS#8 to me. From nobody Sun Oct 13 06:59:06 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9F6120033; Sun, 13 Oct 2019 06:58:50 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKFAnzuYM6Bs; Sun, 13 Oct 2019 06:58:48 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7EE12000F; Sun, 13 Oct 2019 06:58:45 -0700 (PDT) Received: by ajax-webmail-ocmail02.zx.nicx.cn (Coremail) ; Sun, 13 Oct 2019 21:58:40 +0800 (GMT+08:00) X-Originating-IP: [159.226.7.2] Date: Sun, 13 Oct 2019 21:58:40 +0800 (GMT+08:00) X-CM-HeaderCharset: UTF-8 From: "Jiankang Yao" To: "Russ Housley" Cc: secdir@ietf.org, draft-ietf-regext-bundling-registration.all@ietf.org, ietf@ietf.org, regext@ietf.org X-Priority: 3 X-Mailer: Coremail Webmail Server Version XT3.0.8 dev build 20190610(cb3344cf) Copyright (c) 2002-2019 www.mailtech.cn cnnic In-Reply-To: <157071977760.20403.2267644082355726284@ietfa.amsl.com> References: <157071977760.20403.2267644082355726284@ietfa.amsl.com> X-SendMailWithSms: false Content-Transfer-Encoding: base64 Content-Type: text/plain; charset=UTF-8 MIME-Version: 1.0 Message-ID: <25e400f9.1403.16dc569fbf8.Coremail.yaojk@cnnic.cn> X-Coremail-Locale: zh_CN X-CM-TRANSID: AQAAf0BpGL2QLaNdGIqXBA--.6368W X-CM-SenderInfo: x1dryyw6fq0xffof0/1tbiAQACDSVCN6BTwgABsu X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWxJw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU= Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-regext-bundling-registration-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2019 13:58:51 -0000 DQoNCg0KPiAtLS0tLeWOn+Wni+mCruS7ti0tLS0tDQo+IOWPkeS7tuS6ujogIlJ1c3MgSG91c2xl eSB2aWEgRGF0YXRyYWNrZXIiIDxub3JlcGx5QGlldGYub3JnPg0KPiDlj5HpgIHml7bpl7Q6IDIw MTktMTAtMTAgMjM6MDI6NTcgKOaYn+acn+WbmykNCj4g5pS25Lu25Lq6OiBzZWNkaXJAaWV0Zi5v cmcNCj4g5oqE6YCBOiBkcmFmdC1pZXRmLXJlZ2V4dC1idW5kbGluZy1yZWdpc3RyYXRpb24uYWxs QGlldGYub3JnLCBpZXRmQGlldGYub3JnLCByZWdleHRAaWV0Zi5vcmcNCj4g5Li76aKYOiBTZWNk aXIgdGVsZWNoYXQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcmVnZXh0LWJ1bmRsaW5nLXJlZ2lzdHJh dGlvbi0xMQ0KPiANCj4gUmV2aWV3ZXI6IFJ1c3MgSG91c2xleQ0KPiBSZXZpZXcgcmVzdWx0OiBI YXMgSXNzdWVzDQo+IA0KPiBJIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUg U2VjdXJpdHkgRGlyZWN0b3JhdGUncyBvbmdvaW5nDQo+IGVmZm9ydCB0byByZXZpZXcgYWxsIElF VEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlDQo+IGNvbW1l bnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBTZWN1cml0 eSBBcmVhDQo+IERpcmVjdG9ycy4gIERvY3VtZW50IGF1dGhvcnMsIGRvY3VtZW50IGVkaXRvcnMs IGFuZCBXRyBjaGFpcnMgc2hvdWxkDQo+IHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBh bnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMuDQo+IA0KPiBEb2N1bWVudDogZHJhZnQt aWV0Zi1yZWdleHQtYnVuZGxpbmctcmVnaXN0cmF0aW9uLTExDQo+IFJldmlld2VyOiBSdXNzIEhv dXNsZXkNCj4gUmV2aWV3IERhdGU6IDIwMTktMTAtMTANCj4gSUVURiBMQyBFbmQgRGF0ZTogMjAx OS0wMy0xNQ0KPiBJRVNHIFRlbGVjaGF0IGRhdGU6IDIwMTktMTAtMTcNCj4gDQoNCkRlYXIgUnVz cyBIb3VzbGV5Lg0KICBUaGFua3MgYSBsb3QgZm9yIHlvdXIga2luZCByZXZpZXcuDQoNCj4gU3Vt bWFyeTogSGFzIElzc3Vlcw0KPiANCj4gDQo+IE1ham9yIENvbmNlcm5zOg0KPiANCj4gVGhlIEFi c3RyYWN0IGFucyBTZWN0aW9uIDEgc2F5OiAiVGhpcyBpcyBhIG5vbi1zdGFuZGFyZCBwcm9wcmll dGFyeQ0KPiBleHRlbnNpb24uIiBJIHVuZGVyc3RhbmQgdGhhdCB0aGlzIGlzIG5vdCBhIHN0YW5k YXJkcyB0cmFjayBkb2N1bWVudCwgc28NCj4gdGhlICJub24tc3RhbmRhcmQiIHBhcnQgbWFrZXMg c2Vuc2UuIA0KDQp5ZXMsIHRoZSBXRyBkZWNpZGVkIHRoYXQgdGhpcyBkb2N1bWVudCBpcyBpbmZv cm1hdGlvbmFsLg0KDQo+IEhvd2V2ZXIsIHdoYXQgaXMgdGhlIHBvaW50IG9mDQo+IHB1Ymxpc2hp bmcgYSAicHJvcHJpZXRhcnkiIGV4dGVuc2lvbiBhcyBhbiBSRkMuICBJIHdvdWxkIGhvcGUgdGhh dA0KPiBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucyBpcyB0aGUgZ29hbCBvZiBwdWJsaWNh dGlvbi4NCj4gDQoNCklmIHRoZSByZWdpc3RyeSBmb2xsb3dzIHRoaXMgZG9jdW1lbnQsIGJvdGgg cmVnaXN0cnkgYW5kIGl0cyBhbGwgcmVnaXN0cmFycyBzaG91bGQgZm9sbG93IHRoaXMgZG9jdW1l bnQuDQpZZXMsIGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb24gaXMgdmVyeSBpbXBvcnRhbnQu DQoNCg0KPiBJbiBTZWN0aW9uIDEsIHRoZSB1c2Ugb2YgInBvbGljeS13aXNlIiBpcyB1bmNsZWFy LiAgSXMgdGhpcyByZWdpc3RyYXRpb24NCj4gcG9saWN5IG9yIHNvbWV0aGluZyBlbHNlPw0KPiAN Cg0KSG93IGFib3V0IA0KIFBvbGljeS13aXNlIGJ1bmRsaW5nIC0tLT4NCiBCdW5kbGluZyBiYXNl ZCBvbiBwb2xpY3kNCg0KDQo+IA0KPiBNaW5vciBDb25jZXJuczoNCj4gDQo+IE5vbmUuDQo+IA0K PiANCj4gTml0czoNCj4gDQo+IFNlY3Rpb24gMTogcy9sYWJlbChMQUJFTCkvbGFiZWwgKExBQkVM KS8NCj4gLSBzLyhWLXRsZCk7LyhWLXRsZCkuLw0KPiANCg0Kd2lsbCB1cGRhdGUgaXQuDQoNCg0K VGhhbmtzIGEgbG90Lg0KDQpKaWFua2FuZyBZYW8NCg0KPiBJbiBhZGRpdGlvbiwgdGhlcmUgYXJl IHNldmVyYWwgcGxhY2VzIGluIHRoZSB1cHBlciBsZWZ0IGNvcm5lciBvZiB0aGUNCj4gdGl0bGUg cGFnZToNCj4gICAgSW50ZXJuZXQgICAgICAgIEVuZ2luZWVyaW5nICAgICBUYXNrIEZvcmNlDQo+ IA0KPiANCg== From nobody Sun Oct 13 07:26:03 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7009F120033; Sun, 13 Oct 2019 07:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3S6tWOHoTkIx; Sun, 13 Oct 2019 07:25:46 -0700 (PDT) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C77312000F; Sun, 13 Oct 2019 07:25:46 -0700 (PDT) Received: by mail-io1-f54.google.com with SMTP id b136so31762999iof.3; Sun, 13 Oct 2019 07:25:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i2KXgDxEAXyAhNmdgSTYjJoNW74aEcFDFvGgZzJPbmI=; b=qHrqil+eLKD8znIm8ZA9G+Y6PgyWqVrkkHhgWF2wpDSyyAS71SZbOjluyJ/Nyi4PcT IDGL9hbQR3RNv2jtQMPg/sN+Af035FSHlsc9YjAiW5yW9eXuI4NbyaN0cjLLKUiHdNAR oVL1byHQ0h41C/bPkqto8v0vwSI//GImda0FVDgit/aKxUHKYVDg2evDpJSCb4JbRjdg u3ow+JCA68FCxcWUOab8BhsAycdE1KtTEYYVYoDNy6oQ/l6uHQ0WN9vFLuF8MZFzc2nN 0ytZvRH/CfQRTSnXpg+EpGgNOwREJdCLv+lM/NGyZovnzTMKjYaBK77gw1ffy3p2JcNa nZUQ== X-Gm-Message-State: APjAAAV70IYesr1+boeJa4AostWuyRHQVF9z6/CrwnihCxqONIgAqtGP P411Fpf2pqz3nRAns6plmd882fv2Jwd6CLI3CvBzXA== X-Google-Smtp-Source: APXvYqzV/SQNsAItg/rPTXUMWTyovCTHh2OQTsnAQxXY1OpSaeIJ2IBHEpJe74plyXpFwz9fU/EuBMfPiezSro1d604= X-Received: by 2002:a5e:d90c:: with SMTP id n12mr19414081iop.140.1570976745615; Sun, 13 Oct 2019 07:25:45 -0700 (PDT) MIME-Version: 1.0 References: <157071977760.20403.2267644082355726284@ietfa.amsl.com> In-Reply-To: <157071977760.20403.2267644082355726284@ietfa.amsl.com> From: Barry Leiba Date: Sun, 13 Oct 2019 16:25:33 +0200 Message-ID: To: Russ Housley Cc: draft-ietf-regext-bundling-registration.all@ietf.org, ietf@ietf.org, regext@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary="000000000000df7a290594cb8664" Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-regext-bundling-registration-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2019 14:25:48 -0000 --000000000000df7a290594cb8664 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > The Abstract ans Section 1 say: "This is a non-standard proprietary > extension." I understand that this is not a standards track document, so > the "non-standard" part makes sense. However, what is the point of > publishing a "proprietary" extension as an RFC. I would hope that > interoperable implementations is the goal of publication. I=E2=80=99m afraid this addition is my fault. Perhaps =E2=80=9Cproprietary= =E2=80=9D is the wrong word here: The point is that this is documenting an extension developed by one registry and not in use by others, with the idea that if others want to use it they can follow this to interoperable. It=E2=80=99s rather like whe= n we documented Apple Bonjour as Informational. Better word? Barry --000000000000df7a290594cb8664 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0The Abstract ans Section 1 say: "This is a non-standard propriet= ary
> extension." I understand that this is not a standards= track document, so
> the "non-standard" part makes se= nse.=C2=A0 However, what is the point of
> publishing a "pr= oprietary" extension as an RFC.=C2=A0 I would hope that
> i= nteroperable implementations is the goal of publication.

I=E2=80=99m afraid this addition is= my fault.=C2=A0 Perhaps =E2=80=9Cproprietary=E2=80=9D is the wrong word he= re: The point is that this is documenting an extension developed by one reg= istry and not in use by others, with the idea that if others want to use it= they can follow this to interoperable.=C2=A0 It=E2=80=99s rather like when= we documented Apple Bonjour as Informational.

<= /div>
Better word?

Barry

--000000000000df7a290594cb8664-- From nobody Sun Oct 13 10:29:44 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE2612004A; Sun, 13 Oct 2019 10:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suluGJpixMWh; Sun, 13 Oct 2019 10:29:41 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 2684D120024; Sun, 13 Oct 2019 10:29:41 -0700 (PDT) Received: from [10.32.60.60] (50-1-98-250.dsl.dynamic.fusionbroadband.com [50.1.98.250]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id x9DHSl5l086555 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 13 Oct 2019 10:28:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-250.dsl.dynamic.fusionbroadband.com [50.1.98.250] claimed to be [10.32.60.60] From: "Paul Hoffman" To: ietf@ietf.org Cc: draft-ietf-regext-bundling-registration.all@ietf.org, regext@ietf.org, secdir@ietf.org Date: Sun, 13 Oct 2019 10:30:20 -0700 X-Mailer: MailMate (1.13r5655) Message-ID: <4F9A6DFB-AF74-4578-924C-CB2E5D620331@vpnc.org> In-Reply-To: References: <157071977760.20403.2267644082355726284@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-regext-bundling-registration-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2019 17:29:43 -0000 On 13 Oct 2019, at 7:25, Barry Leiba wrote: >> The Abstract ans Section 1 say: "This is a non-standard proprietary >> extension." I understand that this is not a standards track document, >> so >> the "non-standard" part makes sense. However, what is the point of >> publishing a "proprietary" extension as an RFC. I would hope that >> interoperable implementations is the goal of publication. > > I’m afraid this addition is my fault. Perhaps “proprietary” is > the wrong > word here: The point is that this is documenting an extension > developed by > one registry and not in use by others, with the idea that if others > want to > use it they can follow this to interoperable. It’s rather like when > we > documented Apple Bonjour as Informational. > > Better word? Why have any word other than "non-standard"? It is *not* proprietary in that multiple vendors implement it and there appears to be no licensing requirement from the authors. --Paul Hoffman From nobody Sun Oct 13 11:11:33 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A617312003F; Sun, 13 Oct 2019 11:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5GnYIlQfvEU; Sun, 13 Oct 2019 11:11:17 -0700 (PDT) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) (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 2792D120024; Sun, 13 Oct 2019 11:11:17 -0700 (PDT) Received: by mail-io1-f52.google.com with SMTP id b136so32721254iof.3; Sun, 13 Oct 2019 11:11:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/bgtgR5X8HdgFIeiLm1KguLQzKtLOAqdaIESitfgatU=; b=LTIIN3Og4o3pEj39eyz1OHShHEGT4a+QwyX7OLZaGabdoeOV3TX5nFXk5MK+LlV8ft zA3RWiRGvAN8Gw63b3jbtkNqMpZYi07ZmxnyrOFSpJEqBk/eJVwnpfMYb0zBAayduLaA xcv0/yawLC6h4jlJ43t8NTln4FEiU5jW5OK7xFTjIb/9r0+95CW3gP2ciFRQlwmi1LrR hbNqhi2mEhgj/DetyOIuSh58lKqx+IJ1cn28StK/JDhs0KuJYdwUFpoRpt5v2rwAFdWO chzl6yl2UxZC/z4lOB9UFLbb5jQ7pfU3FRQMgK2AY4sgvpIOpTP5SKHZ7vCiesQRfH1f 1e2Q== X-Gm-Message-State: APjAAAUJ4hHogaXVlzKMNdkk1o5JXKgMxiq0ED/Cb8ljxX6pUdaxPFMC 1jgzb4fClzE1qVPGqYA6YCzSKD5fvHxbigHQ9PJ24SvN X-Google-Smtp-Source: APXvYqy4Rb78dUEZYJffTWUZyo9I6qwM5Y55bhCuRkNpxygGCbo040DEcF4kK8lO6yz4KXl4mWFIU6RR4rfvMUOvlOg= X-Received: by 2002:a6b:7f01:: with SMTP id l1mr15087694ioq.90.1570990276026; Sun, 13 Oct 2019 11:11:16 -0700 (PDT) MIME-Version: 1.0 References: <157071977760.20403.2267644082355726284@ietfa.amsl.com> <4F9A6DFB-AF74-4578-924C-CB2E5D620331@vpnc.org> In-Reply-To: <4F9A6DFB-AF74-4578-924C-CB2E5D620331@vpnc.org> From: Barry Leiba Date: Sun, 13 Oct 2019 20:11:03 +0200 Message-ID: To: Paul Hoffman Cc: draft-ietf-regext-bundling-registration.all@ietf.org, ietf@ietf.org, regext@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary="0000000000005925c00594ceadc4" Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-regext-bundling-registration-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2019 18:11:20 -0000 --0000000000005925c00594ceadc4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Works for me: I had suggested =E2=80=9Cproprietary=E2=80=9D, so I will now = unsuggest it. Authors, sorry about that: please remove that word in both places the next time you make a revision. Thanks. Barry On Sun, Oct 13, 2019 at 1:29 PM Paul Hoffman wrote: > On 13 Oct 2019, at 7:25, Barry Leiba wrote: > > >> The Abstract ans Section 1 say: "This is a non-standard proprietary > >> extension." I understand that this is not a standards track document, > >> so > >> the "non-standard" part makes sense. However, what is the point of > >> publishing a "proprietary" extension as an RFC. I would hope that > >> interoperable implementations is the goal of publication. > > > > I=E2=80=99m afraid this addition is my fault. Perhaps =E2=80=9Cproprie= tary=E2=80=9D is > > the wrong > > word here: The point is that this is documenting an extension > > developed by > > one registry and not in use by others, with the idea that if others > > want to > > use it they can follow this to interoperable. It=E2=80=99s rather like= when > > we > > documented Apple Bonjour as Informational. > > > > Better word? > > Why have any word other than "non-standard"? It is *not* proprietary in > that multiple vendors implement it and there appears to be no licensing > requirement from the authors. > > --Paul Hoffman > --0000000000005925c00594ceadc4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Works for me: I had suggested =E2=80=9Cproprietary= =E2=80=9D, so I will now unsuggest it.=C2=A0 Authors, sorry=C2=A0about that= : please remove that word in both places the next time you make a revision.= =C2=A0 Thanks.

Bar= ry

On Sun, Oct 13, 2019 at 1:29 PM Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On 13 Oct 2019, at 7:25, Barry Leiba wrote:

>> The Abstract ans Section 1 say: "This is a non-standard propr= ietary
>> extension." I understand that this is not a standards track d= ocument,
>> so
>> the "non-standard" part makes sense.=C2=A0 However, what= is the point of
>> publishing a "proprietary" extension as an RFC.=C2=A0 I = would hope that
>> interoperable implementations is the goal of publication.
>
> I=E2=80=99m afraid this addition is my fault.=C2=A0 Perhaps =E2=80=9Cp= roprietary=E2=80=9D is
> the wrong
> word here: The point is that this is documenting an extension
> developed by
> one registry and not in use by others, with the idea that if others > want to
> use it they can follow this to interoperable.=C2=A0 It=E2=80=99s rathe= r like when
> we
> documented Apple Bonjour as Informational.
>
> Better word?

Why have any word other than "non-standard"? It is *not* propriet= ary in
that multiple vendors implement it and there appears to be no licensing requirement from the authors.

--Paul Hoffman
--0000000000005925c00594ceadc4-- From nobody Sun Oct 13 11:40:24 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF26112003F; Sun, 13 Oct 2019 11:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 XAIhLnOSbwMm; Sun, 13 Oct 2019 11:40:07 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 596DC120024; Sun, 13 Oct 2019 11:40:07 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1iJimi-0007O3-Ni; Sun, 13 Oct 2019 14:40:04 -0400 Date: Sun, 13 Oct 2019 14:39:59 -0400 From: John C Klensin To: Barry Leiba , Russ Housley cc: draft-ietf-regext-bundling-registration.all@ietf.org, ietf@ietf.org, regext@ietf.org, secdir@ietf.org Message-ID: In-Reply-To: References: <157071977760.20403.2267644082355726284@ietfa.amsl.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-regext-bundling-registration-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2019 18:40:11 -0000 --On Sunday, October 13, 2019 16:25 +0200 Barry Leiba wrote: >> The Abstract ans Section 1 say: "This is a non-standard >> proprietary extension." I understand that this is not a >> standards track document, so the "non-standard" part makes >> sense. However, what is the point of publishing a >> "proprietary" extension as an RFC. I would hope that >> interoperable implementations is the goal of publication. > > I'm afraid this addition is my fault. Perhaps > "proprietary" is the wrong word here: The point is that > this is documenting an extension developed by one registry and > not in use by others, with the idea that if others want to use > it they can follow this to interoperable. It's rather like > when we documented Apple Bonjour as Informational. > > Better word? Barry, Our traditional way of handling this sort of thing is to have the title say "FooCompany's method of doing X" (presumably, in this case, "CDNC Method for Domain Name Mapping Extension for Strict Bundling Registration" (with or without the EPP identification) and then identifying the companies or registries that have implemented it in the Introduction. Some of the latter information is included in Section 12 on Implementation Status but not only is that section not referenced from the Introduction, but there is a note requesting that the RFC Editor remove it. Most such documents have been handled as Independent Submissions, rather than by the IESG and the IESG has generally insisted on such titles and introductory material as well as the usual "this is not a standard..." boilerplate. That list specifically includes RFC 4290, an opinion piece on registration procedures for IDNs that is referenced by this document, and RFCs 3743 and 4713, which are the core JET and CDNC documents respectively and which, while not referenced from this document, appear to define and explain concepts essential to it. If the Bonjour spec you are referring to is RFC 6886, while the title does not reflect that status, the Abstract does indicate its status and it was also handled as an Independent Submission. Noting that there is a presumption of IESG Consensus for anything published in the IETF Stream (even Informational pieces), I suggest that if this is a non-standard, but compatible, extension that is expected to be published in the IETF Stream, the title should be adjusted to show the status as above, the implementation status should be retained, and, although it is unusual, an explicit statement should be included that others are free to implement and use this extension without any special arrangements with the authors or their organizations. Or toss it over the wall to the ISE with an explicit note indicating that there has been BOF, WG, and mailing list discussions (possibly by including the Shepherd's report), that the WG is in favor of this being published, waiving further RFC 5742, and urging expedited handling. That would allow a quick review through the ISE and associated processes, which are much more familiar with this type of document than the IETF Stream his historically been. Technical comment: While this protocol extension appears to be applicable only to "strict bundling" and calls that term out in the title, the term is, AFAICT, not ever defined in a rigorous way. The Introduction says "...strict bundling, which requires all bundled names to share many same attributes". Ignoring the inconvenient English, "many same" is not a definition without either a list of attributes or quantification like "at least five of the following list". When we get to Section 5, the specification isn't talking about "strict bundling" any more, but, even then, says "should share some parameter or attributes associated with domain names", an even weaker and m0re vague requirement. So readers of this document who are considering implementing the extension is not able to determine whether it is applicable to their needs (at least in the absence of discussions with the designers). If "strict bundling" is really whatever a particular registry says it is, that should be explicit in the text. best, john p.s. While I appreciate the acknowledgment which is possibly due to my contributions to related work, I generally do not follow EPP work (for reasons of which several of those copied on this note are aware) and do not remember looking at this document, at least in its present form, before it was called to my attention by this correspondence. On the other hand, perhaps the authors could anticipate the future and proactively acknowledged my comments above :-) From nobody Sun Oct 13 12:25:10 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D68E120024; Sun, 13 Oct 2019 12:24:55 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace: References: ...55726284@ietfa.amsl.com>\n \n ) id 1iJjU2-0007TZ-Si; Sun, 13 Oct 2019 15:24:50 -0400 Date: Sun, 13 Oct 2019 15:24:45 -0400 From: John C Klensin To: Barry Leiba , Russ Housley cc: draft-ietf-regext-bundling-registration.all@ietf.org, ietf@ietf.org, regext@ietf.org, secdir@ietf.org Message-ID: In-Reply-To: References: <157071977760.20403.2267644082355726284@ietfa.amsl.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-regext-bundling-registration-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2019 19:24:56 -0000 Sorry... Addendum to the technical comment quoted below: The document uses the term "variant" extensively, but does not define it either. That term seems essential to what is going on in this document. It des not appear in RFC 8499 (which is not cited in any event). The term was introduced into the IETF and DNS vocabulary by the JET Guidelines (RFC 3743) but the term there, as called out in both the text and the IESG Note, is used for language-based preferences and relationships. In most of the DNS registry and registrar communities, and in the ICANN Variant Information Project that spawned the efforts that, in turn, led to RFCs 7940 and 8228, the term is primarily used to describe the potential for visual confusion among characters or strings. The document should be clear about whether one definition, the other, or both are intended. Again, if it is not, it is not possible for readers to objectively determine whether the specification is applicable to their needs. thanks, john --On Sunday, October 13, 2019 14:39 -0400 John C Klensin wrote: >... > Technical comment: While this protocol extension appears to be > applicable only to "strict bundling" and calls that term out in > the title, the term is, AFAICT, not ever defined in a rigorous > way. The Introduction says "...strict bundling, which requires > all bundled names to share many same attributes". Ignoring the > inconvenient English, "many same" is not a definition without > either a list of attributes or quantification like "at least > five of the following list". When we get to Section 5, the > specification isn't talking about "strict bundling" any more, > but, even then, says "should share some parameter or attributes > associated with domain names", an even weaker and m0re vague > requirement. So readers of this document who are considering > implementing the extension is not able to determine whether it > is applicable to their needs (at least in the absence of > discussions with the designers). If "strict bundling" is > really whatever a particular registry says it is, that should > be explicit in the text. >... From nobody Sun Oct 13 15:26:12 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F0112006D; Sun, 13 Oct 2019 15:25:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey via Datatracker To: Cc: draft-ietf-dmm-distributed-mobility-anchoring.all@ietf.org, iesg@ietf.org, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Joseph Salowey Message-ID: <157100555733.20750.5488529297693995498@ietfa.amsl.com> Date: Sun, 13 Oct 2019 15:25:57 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dmm-distributed-mobility-anchoring-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2019 22:25:58 -0000 Reviewer: Joseph Salowey Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is the document has issues with the security considerations section. The security consideration section is extremely light. It mainly contains text from RFC 7333. It seems that there should be more discussion of security as it relates to the different configurations and different cases. Do each of these cases have the same security properties and require the same types of security controls? Are the IPSEC recommendations mentioned in the security considerations of draft-ietf-dmm-deployment-models-04 applicable for all the cases? Should these be pointed out in the security considerations section? From nobody Sun Oct 13 20:33:02 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9D6120018; Sun, 13 Oct 2019 20:32:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kyle Rose via Datatracker To: Cc: mboned@ietf.org, ietf@ietf.org, draft-ietf-mboned-ieee802-mcast-problems.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Kyle Rose Message-ID: <157102397341.20776.9338396539567675909@ietfa.amsl.com> Date: Sun, 13 Oct 2019 20:32:53 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-mboned-ieee802-mcast-problems-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 03:32:54 -0000 Reviewer: Kyle Rose Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I marked this "ready with nits" because I see no serious security or privacy considerations, but I'm confused by the wording in section 7, which begins: q( This section will provide some recommendations about the usage and combinations of the multicast enhancements described in Section 4 and Section 5. ) and then proceeds to provide little in the way of such recommendations. Maybe the phrasing here is just awkward? Nits: Reference dot11aa (https://standards.ieee.org/findstds/standard/802.11aa-2012.pdf) gives me a 404. Maybe I simply lack the appropriate decoder ring? The IETF meeting network is referenced three times in section 5.1. For example, q( The distribution of users on wireless networks / subnets changes from one IETF meeting to the next (e.g SSIDs are renamed, some SSIDs lose favor, etc). This makes utilization for particular SSIDs difficult to predict ahead of time, but usage can be monitored as attendees use the different networks. ) This feels like a non-sequitur. Maybe some introductory text about using the IETF meetings as an exemplar would make this read a little better, but it seems like the advice to operators here should be generic and not connected to particular goals for network connectivity at IETF meetings. From nobody Sun Oct 13 22:46:45 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBCCF1200CD; Sun, 13 Oct 2019 22:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, 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 8tTZROlI0Pup; Sun, 13 Oct 2019 22:46:42 -0700 (PDT) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 0D1D81200BA; Sun, 13 Oct 2019 22:46:42 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id u20so7516114plq.4; Sun, 13 Oct 2019 22:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=DZa2tzIlbWZxM5FlGqqIthFA9pXmte2I+RQSIFNxxMk=; b=Z7baatOuDnpO+MdKdDBr1rpuA2i0H6V4OQ0Mxaa51w+J9lZYN8MM6d51V3G33oE6k5 lBTt3GVkt7mgrcpZxIODDkIZMhp0tbxhkJCGS3A3VtZXT8qRqo7eZTYngY07IVsx9kPP GmjS938Dv5IV6wiio0ThhWDRxw0l3dg/OaL0vdnMAClIqYHccMF0cJ2QiWeVEO72NO0m x4y1q8gKsxNwyg+W/fd5J0dgEE5cW7wRq06tFCxp2JbSVQ0/0f+xYG9hhVgxkTjYLwn6 mczJe5kuBhZvsZ0gcVQFYluVhlKp/pzFulMOvOhjFI/jmLuGJAK/7qGY7HnuPMKXF8cT Uk1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=DZa2tzIlbWZxM5FlGqqIthFA9pXmte2I+RQSIFNxxMk=; b=SbxCxzWe4AQODObpyX6Tyb5/20SL1Qhx3ZfbckCQx6uU4Q6SeKPsSPXEGyFiRIEfyU NoUZSx7aTwEyePFH77vBjSp19CtE8DfnLOq6Dnqjis2ZgcChg718CZRaTEMIqMx2Y+vX RlLhGSpTjGmWPIktJvbbwXozv3uKjQ/LIfKajSsm40rolXCCOD24BDCrlwHhvcvLIds0 L7+NvKS8HAda48JeyfhWMyi/p6dOZvlZLvFs9ATAgeOERPS919if3KVLUtHSekUDv1AQ /vrqivJK3dg+voMmw/+iX95fqXg4KLa9lk+a+eIkhqnhqKSfSJi46raSUoJ2zWYWHD4j tzQg== X-Gm-Message-State: APjAAAWkZNT3utsZgba0dQgV+jNxbZPDQBpxraxv/G5EU433dLTTZvan 1q5u/nGazmoF1kFivpqqXufizGmvXGUShmNytT7EKSM5 X-Google-Smtp-Source: APXvYqyNMbxV5HC3ToRDvS6+aqqXYUz0dy1/OBldyJfNkjX10B1VZFHikD/mUQyYkN2NskIrdeK+lyoZS0dCHl6O6VE= X-Received: by 2002:a17:902:8bca:: with SMTP id r10mr28741494plo.43.1571032001380; Sun, 13 Oct 2019 22:46:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Date: Sun, 13 Oct 2019 22:46:30 -0700 Message-ID: To: secdir@ietf.org, draft-ietf-ipsecme-implicit-iv@ietf.org Content-Type: multipart/alternative; boundary="0000000000005f85f00594d8642a" Archived-At: Subject: [secdir] Secdir review of draft-ietf-ipsecme-implicit-iv-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 05:46:44 -0000 --0000000000005f85f00594d8642a Content-Type: text/plain; charset="UTF-8" I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a mechanism to save on bandwidth in ESP connections when certain ciphers have been negotiated by using implicit IVs. The savings are limited to 8 bytes for the current version of this document. - Section 2 mentions AES-CCM, AES-CTR, AES-GCM and ChaCha. For all of these ciphers, an 8-byte nonce is used. The mechanism to make the IV implicit is by coupling it to the sequence number. Yet, Section 4 gives two examples of sequence numbers, one of 4 bytes and one of 8 bytes. This is confusing, presumably only the extended sequence number is usable? - Also, while the Abstract says the memo offers a mechanism to save on the explicit IV also for AES-CTR, and Section 2 includes AES-CTR in its description, Section 4 explicitly states that only AES-CCM, AES-GCM and ChaCha are subject of the optimization in this memo. This is also confusing. Why including AES-CTR in the memo at all if it isn't covered? At the very least it seems the Abstract should be updated. - It would be very helpful and useful to include an example of a handshake with an IIV and the resulting IV in an Appendix; this could assist implementors to get things right. (Editorial: English grammar needs some updates/reviews) Thanks, -- Magnus --0000000000005f85f00594d8642a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security directorate's ong= oing effort to review all IETF documents being processed by the IESG. These= comments were written primarily for the benefit of the security area direc= tors.=C2=A0 Document editors and WG chairs should treat these comments just= like any other last call comments.

This document defines a mechanism to save on bandwidth = in ESP connections when certain ciphers have been negotiated by using impli= cit IVs. The savings are limited to 8 bytes for the current version of this= document.
    • Section 2 mentions AES-CCM, AES-C= TR, AES-GCM and ChaCha. For all of these ciphers, an 8-byte nonce is used. = The mechanism to make the IV implicit is by coupling it to the sequence num= ber. Yet, Section 4 gives two examples of sequence numbers, one=C2=A0 of 4 = bytes and one of 8 bytes. This is confusing, presumably only the extended s= equence number is usable?
    • Also, while the Abstract says the memo of= fers a mechanism to save on the explicit IV also for AES-CTR, and Section 2= includes AES-CTR in its description, Section 4 explicitly states that only= AES-CCM, AES-GCM and ChaCha are subject of the optimization in this memo. = This is also confusing. Why including AES-CTR in the memo at all if it isn&= #39;t covered? At the very least it seems the Abstract should be updated.
    • It would be very helpful and useful to include an example of a h= andshake with an IIV and the resulting IV in an Appendix; this could assist= implementors to get things right.

    (Editorial:= English grammar needs some updates/reviews)

    Thank= s,
    -- Magnus
    --0000000000005f85f00594d8642a-- From nobody Mon Oct 14 00:10:15 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3820612010C; Mon, 14 Oct 2019 00:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ljdXXCix; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=J4fih5z8 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 VD8H4U3RrWU8; Mon, 14 Oct 2019 00:10:10 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A782120106; Mon, 14 Oct 2019 00:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3260; q=dns/txt; s=iport; t=1571037010; x=1572246610; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NoVfC7u4FU+7hvZkn4I9sS/NSMkn+xXLjID4AaTjJcI=; b=ljdXXCixUZgwglIPZhX1QMBvIrKDphCKS9fnDOHuOko+ARPWFCgoykGr OP9uDMXan2aCfBxE+77b61A0p8Cvw0LG5qP37CZLX0ENLjbJf69pA2l+B VawkalG90oK0wwvehD6FTtHOrtggjxTVZsJZ8Gd5YXs6yeKbQuD+pacXI I=; IronPort-PHdr: =?us-ascii?q?9a23=3AWsSb1hGLsyIbtnKEwP0WC51GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1A3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+efP0fioxH8lqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DZAQCqHqRd/4QNJK1mDg0BAQEBAQE?= =?us-ascii?q?BBQEBAREBAQMDAQEBgXuBS1AFbFcgBAsqhCSDRwOKSppagUKBEANUCQEBAQw?= =?us-ascii?q?BASMKAgEBhEACF4JHJDgTAgMJAQEEAQEBAgEFBG2FLQyFTAIBAQISEREMAQE?= =?us-ascii?q?3AQ8CAQgODAImAgICMBUQAgQBDQUigwABgkYDLgECDKUPAoE4iGF1gTKCfQE?= =?us-ascii?q?BBYE0AYNNGIIXAwaBDCiMDhiBQD+BEScfgkw+gmEDgRkPBQESATaCdzKCLI0?= =?us-ascii?q?4gjecam4KgiKHCIoNhAQbgjqLeosMji2IIpEVAgQCBAUCDgEBBYFpImdxcBV?= =?us-ascii?q?lAYJBUBAUgU+Dc4UUhQQ7dAEBgSeNF4JFAQE?= X-IronPort-AV: E=Sophos;i="5.67,295,1566864000"; d="scan'208";a="633038404" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Oct 2019 07:10:09 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x9E7A9WE019987 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Oct 2019 07:10:09 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 14 Oct 2019 02:10:08 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 14 Oct 2019 02:10:08 -0500 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 14 Oct 2019 03:10:08 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SfEuyz/YxrZYETK5xFVG0hxoKfB56gg3kBpEtroJc+tmQChgPh9y+B6RMfuoZs74+iZdYwYgMkFuwzuhyHqBCDfKgcxqfSX1h+7+QNrFPP2rOONjRNIqH284QzTFt25YOktkHJLIOOCJD5Ol3ytQwqNxisq76jkEKH1w6XZv8rGmSGa9mfcU5alvLsocK1rNN5dBKovlQFraQ+ZUZj6BGsT7oOA8ZpKmYBPGzTmuj59UlE/eYTplbSvtlvWolH1N7jTxWzBn0XnAEBE4aHjjqSLmBc+8zVKtsE4R1PMvmxwDP1oefLx6zSEwPC1rg5jHz9FEGRyoY9NalOqcEd71Hg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NoVfC7u4FU+7hvZkn4I9sS/NSMkn+xXLjID4AaTjJcI=; b=jwj6hDVWjGTEXGtlceA65V3S4UeXTI/c6zIg+WGllomueFA8gcvfzm2toD1FJi58s0tpr3TecCjYsw6bqaSLUsyR/fTj9cUjQ8HpXVG9d9nQQ/t9foqKMPXJqPNoqLAm+E06Dt20bJs7OoQa9qGXLiSs09ijTj2xa6qbN39W9f3OZTdHgFjHP2vUl5izo1TUXVOEJj4yCl9eP7ZWCQZMXnnQSw/EVT6p2v0cfA5iRKmcSwa+5BqZkBiUrUELKm+6yaoZipjWJk+NSUseNm3s3H5LF3Pho1ZNNnhXDthca5yzHg3tqgBPXQLp6pn3xHVup5AlJiPW17eSxkgzViuGnA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NoVfC7u4FU+7hvZkn4I9sS/NSMkn+xXLjID4AaTjJcI=; b=J4fih5z8GBZriTItOL5+pBM/k0dlWx7hllYnS5dtTjOtaFjrjTXeJDcSIXNsvhbB8nYwDZwCqPCf+Xy8QFxsy782Nl0Pvj4KtOdD9vQQL5qjTOyTw7vkYxD78MMLXFtkqFwFoVBx9pux3SPgJo4XcwLdR5+G82XLzK91c4fTZYA= Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB3920.namprd11.prod.outlook.com (10.255.181.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.21; Mon, 14 Oct 2019 07:10:06 +0000 Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::e4f8:d335:c018:c62a]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::e4f8:d335:c018:c62a%7]) with mapi id 15.20.2347.021; Mon, 14 Oct 2019 07:10:06 +0000 From: "Eric Vyncke (evyncke)" To: Kyle Rose , "secdir@ietf.org" , "gorry@erg.abdn.ac.uk" CC: "mboned@ietf.org" , "draft-ietf-mboned-ieee802-mcast-problems.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-mboned-ieee802-mcast-problems-09 Thread-Index: AQHVgkAY0N6Z+kqf+kWm4acOtxmCt6dZ2dYA Date: Mon, 14 Oct 2019 07:10:06 +0000 Message-ID: References: <157102397341.20776.9338396539567675909@ietfa.amsl.com> In-Reply-To: <157102397341.20776.9338396539567675909@ietfa.amsl.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:e9f7:9043:77eb:a55c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d5e6e51e-4bc7-4a91-58c5-08d750758af0 x-ms-traffictypediagnostic: MN2PR11MB3920: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01901B3451 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(366004)(396003)(346002)(376002)(52544003)(189003)(199004)(504964003)(91956017)(58126008)(486006)(25786009)(33656002)(76116006)(229853002)(54906003)(14444005)(256004)(2201001)(86362001)(316002)(6486002)(110136005)(8936002)(478600001)(8676002)(14454004)(66446008)(64756008)(66556008)(476003)(66476007)(66946007)(71200400001)(71190400001)(81166006)(81156014)(6246003)(76176011)(6506007)(2616005)(7736002)(6116002)(4326008)(2501003)(305945005)(99286004)(46003)(2906002)(102836004)(186003)(11346002)(6306002)(5660300002)(6512007)(6436002)(446003)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3920; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: s/0KSNev3HBjLbFeWyAF3IXqbCpykvJNkXMKaVnzlvVmqaYy7eiYNkk/fr5/8d+myOdu5pqBpuCotAA6QzrM5MnEGla+NXEka3iz8s8jtdxm2w87C3kTjq1zikTx4djt3vwNYR3UHrBmG0nlVtce0NvZqL94mZ22SFv22hhtskOrPMfHiL1230HJRdK2NbTsxy8CG6MhqhjrrPi8OoWL9pfgKIS6nY383PeoHHd8T+rD++JoBRy9obcuss1Zf2YjmXyZxxS5eO64m3RnjF7Qc/sv37oRBIhFnkpxd+/GRRdr7VCGM6555W1LZxO8fnSSjTjdjUlhWL1/IXmu6+uzPogKTzCErOIjzVoSsze5GwN4Cuypuy7BJpBieAGqs3wrcy8KPZfTaP/3v5ptcrSrbvCBpi2EN4/0p2WybtF48OVMvW13Lmqp/oySmZdCeBzlYWI29aHdBbci8mImLQ4IBQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <6F4526FE45BC9E48B24DBC9717210E61@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d5e6e51e-4bc7-4a91-58c5-08d750758af0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2019 07:10:06.7198 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xV4GN4HntKdTHr+eCSzxjNemqQLN2g7VQnhpgpd6Mr2wLY8JwoL67WkO9YvNjsk4bpzrkrFBd8wkWyYwPtPPfA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3920 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-mboned-ieee802-mcast-problems-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 07:10:13 -0000 VGhhbmsgeW91IEt5bGUgZm9yIHRoZSByZXZpZXc6IG5pdHMgYXJlIG5pdHMgYnV0IGxldCdzIGZp eCB0aGVtIHdoZW4gdGhlIGxhc3QgY2FsbCBlbmRzIChsYXRlciB0b2RheSkuDQoNCkRlYXIgYXV0 aG9ycywgSSB3b3VsZCBhcHByZWNpYXRlIGl0IGlmIGEgbmV3IHJldmlzaW9uIHdhcyB1cGxvYWRl ZCBvbiBUdWVzZGF5IDE1dGggKGkuZS4gYWZ0ZXIgdGhlIGxhc3QgY2FsbCBleHBpcmF0aW9uKSBm aXhpbmcgYWxsIGlzc3VlcyBkZXRlY3RlZCBpbiB0aGUgbGFzdCBjYWxsIChzZWUgR29ycnkncyBl bWFpbCBkYXRlZCAybmQgT2N0b2JlcikgYW5kIEt5bGUncyBvbmUgYmVsb3cuDQoNCk9uY2UgZG9u ZSwgSSB3aWxsIHByb2NlZWQgd2l0aCB0aGUgcHVibGljYXRpb24gcHJvY2Vzcw0KDQpSZWdhcmRz IGFuZCB0aGFuayB5b3UgaW4gYWR2YW5jZQ0KDQotw6lyaWMgKHNoZXBoZXJkaW5nIEFEIGZvciB0 aGlzIGRvY3VtZW50KQ0KDQoNCu+7v09uIDE0LzEwLzIwMTksIDA1OjMzLCAiS3lsZSBSb3NlIHZp YSBEYXRhdHJhY2tlciIgPG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgUmV2aWV3ZXI6 IEt5bGUgUm9zZQ0KICAgIFJldmlldyByZXN1bHQ6IEhhcyBOaXRzDQogICAgDQogICAgSSBoYXZl IHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3Jh dGUncyBvbmdvaW5nDQogICAgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVp bmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiAgVGhlc2UNCiAgICBjb21tZW50cyB3ZXJlIHdyaXR0 ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3Rv cnMuDQogICAgIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhl c2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlcg0KICAgIGxhc3QgY2FsbCBjb21tZW50cy4N CiAgICANCiAgICBJIG1hcmtlZCB0aGlzICJyZWFkeSB3aXRoIG5pdHMiIGJlY2F1c2UgSSBzZWUg bm8gc2VyaW91cyBzZWN1cml0eSBvciBwcml2YWN5DQogICAgY29uc2lkZXJhdGlvbnMsIGJ1dCBJ J20gY29uZnVzZWQgYnkgdGhlIHdvcmRpbmcgaW4gc2VjdGlvbiA3LCB3aGljaCBiZWdpbnM6DQog ICAgDQogICAgcSggVGhpcyBzZWN0aW9uIHdpbGwgcHJvdmlkZSBzb21lIHJlY29tbWVuZGF0aW9u cyBhYm91dCB0aGUgdXNhZ2UgYW5kDQogICAgY29tYmluYXRpb25zIG9mIHRoZSBtdWx0aWNhc3Qg ZW5oYW5jZW1lbnRzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQgYW5kIFNlY3Rpb24NCiAgICA1LiAp DQogICAgDQogICAgYW5kIHRoZW4gcHJvY2VlZHMgdG8gcHJvdmlkZSBsaXR0bGUgaW4gdGhlIHdh eSBvZiBzdWNoIHJlY29tbWVuZGF0aW9ucy4gTWF5YmUNCiAgICB0aGUgcGhyYXNpbmcgaGVyZSBp cyBqdXN0IGF3a3dhcmQ/DQogICAgDQogICAgTml0czoNCiAgICANCiAgICBSZWZlcmVuY2UgZG90 MTFhYQ0KICAgIChodHRwczovL3N0YW5kYXJkcy5pZWVlLm9yZy9maW5kc3Rkcy9zdGFuZGFyZC84 MDIuMTFhYS0yMDEyLnBkZikgZ2l2ZXMgbWUgYQ0KICAgIDQwNC4gTWF5YmUgSSBzaW1wbHkgbGFj ayB0aGUgYXBwcm9wcmlhdGUgZGVjb2RlciByaW5nPw0KICAgIA0KICAgIFRoZSBJRVRGIG1lZXRp bmcgbmV0d29yayBpcyByZWZlcmVuY2VkIHRocmVlIHRpbWVzIGluIHNlY3Rpb24gNS4xLiBGb3Ig ZXhhbXBsZSwNCiAgICANCiAgICBxKCBUaGUgZGlzdHJpYnV0aW9uIG9mIHVzZXJzIG9uIHdpcmVs ZXNzIG5ldHdvcmtzIC8gc3VibmV0cyBjaGFuZ2VzIGZyb20gb25lDQogICAgSUVURiBtZWV0aW5n IHRvIHRoZSBuZXh0IChlLmcgU1NJRHMgYXJlIHJlbmFtZWQsIHNvbWUgU1NJRHMgbG9zZSBmYXZv ciwgZXRjKS4gDQogICAgVGhpcyBtYWtlcyB1dGlsaXphdGlvbiBmb3IgcGFydGljdWxhciBTU0lE cyBkaWZmaWN1bHQgdG8gcHJlZGljdCBhaGVhZCBvZiB0aW1lLA0KICAgIGJ1dCB1c2FnZSBjYW4g YmUgbW9uaXRvcmVkIGFzIGF0dGVuZGVlcyB1c2UgdGhlIGRpZmZlcmVudCBuZXR3b3Jrcy4gKQ0K ICAgIA0KICAgIFRoaXMgZmVlbHMgbGlrZSBhIG5vbi1zZXF1aXR1ci4gTWF5YmUgc29tZSBpbnRy b2R1Y3RvcnkgdGV4dCBhYm91dCB1c2luZyB0aGUNCiAgICBJRVRGIG1lZXRpbmdzIGFzIGFuIGV4 ZW1wbGFyIHdvdWxkIG1ha2UgdGhpcyByZWFkIGEgbGl0dGxlIGJldHRlciwgYnV0IGl0IHNlZW1z DQogICAgbGlrZSB0aGUgYWR2aWNlIHRvIG9wZXJhdG9ycyBoZXJlIHNob3VsZCBiZSBnZW5lcmlj IGFuZCBub3QgY29ubmVjdGVkIHRvDQogICAgcGFydGljdWxhciBnb2FscyBmb3IgbmV0d29yayBj b25uZWN0aXZpdHkgYXQgSUVURiBtZWV0aW5ncy4NCiAgICANCiAgICANCg0K From nobody Mon Oct 14 09:17:00 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BCD120116; Mon, 14 Oct 2019 09:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 CvgITaU_VvCX; Mon, 14 Oct 2019 09:16:57 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750099.outbound.protection.outlook.com [40.107.75.99]) (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 D8B461200CC; Mon, 14 Oct 2019 09:16:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WratZNnMgRPB+x5HHPZQSdFoC7zdx7w57SaUcAep3OTjkv8oTlNpirTI3dNgM+nu7XJ46lFVhgdyr6ORDjHBj1Aj3Vgz7UKcPfEGGM5ETaaBW2kSe7qrHpkWEmRvEyCv0SV1G7ek6PdNZm+WoqAZdC/jqAmgRRrqbcxPpy54qFxpjTTs0pZo5Mrc1RFpFopc2bW3296mJpiSXw4/hhSJWiazHDbqJOKMwMI4D28/fx+cc/7QxwpzcGY+ZksRPgC7Gh+nEktW0TGS+2WyyqOqh7Ujq3Z5/Bh5m53V95LKegfb5arcJBJVsO32XOoatgm/KcIbnlTu6kUxFbgiVEReJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O138rDUETJPCMk3A0+mHRm6+px6CxpEntKPcoGVTAr8=; b=NH2HU0e26cyzPv8pIlbd7n31R70viIJZpoKdDZqX22x0lztof8Kfor04GC2TIUoyfXyFP7bSKGM5rsFq0YEOvXmmYbjs/KPMeAD3wk0sUfZuyi7mHWrkxCzSzyCRquB94DkTdzPGSQ802oVkaO5TXb5RFZqEiB2QDJifCOitFMwf4fGWzR7ACmqDnnlSTsNE4MyYOW3Uy7zbT7qiZ2naI+7I6Jt3vaiVZujug0t5EOgA5KrQhvDlwPzUAUAYYYVnm+dpju36LduNu8gtzDfo9TXCnqJU2fDKlC80YEVrwAGzTzT+UiZ2oBikRkStoXUc4WElA/aPFn85fkHGTkNsVQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O138rDUETJPCMk3A0+mHRm6+px6CxpEntKPcoGVTAr8=; b=dUmifLIGFwZKMYvAdG/5GNezinPSKKp58zwWy9yu3NXgM5kxXgjoRb+sDiJJAf+JGwvUvyGcwFPBLU/QwCoYNcTiFko1rOFx26kWvILdNWtXJXoTf+S3g7F+DDbR1IzUvL/gNTTxG+qmHeKuO+Tb4FuvkklP6/e70/ZDqeXmnZA= Received: from BYAPR13MB2807.namprd13.prod.outlook.com (20.178.238.209) by BYASPR01MB0038.namprd13.prod.outlook.com (20.177.187.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.22; Mon, 14 Oct 2019 16:16:53 +0000 Received: from BYAPR13MB2807.namprd13.prod.outlook.com ([fe80::e407:1ca7:7ee9:e0f3]) by BYAPR13MB2807.namprd13.prod.outlook.com ([fe80::e407:1ca7:7ee9:e0f3%7]) with mapi id 15.20.2347.023; Mon, 14 Oct 2019 16:16:53 +0000 From: Michael McBride To: "Eric Vyncke (evyncke)" , Kyle Rose , "secdir@ietf.org" , "gorry@erg.abdn.ac.uk" CC: "mboned@ietf.org" , "draft-ietf-mboned-ieee802-mcast-problems.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-mboned-ieee802-mcast-problems-09 Thread-Index: AQHVgkAUaaRgATgiN0WUu+tThnkKZKdZuE8AgACUnnA= Date: Mon, 14 Oct 2019 16:16:52 +0000 Message-ID: References: <157102397341.20776.9338396539567675909@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.mcbride@futurewei.com; x-originating-ip: [108.197.145.62] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8c3f5e83-51cf-48cd-bec0-08d750c1ed34 x-ms-traffictypediagnostic: BYASPR01MB0038: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01901B3451 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39840400004)(366004)(396003)(376002)(346002)(136003)(13464003)(504964003)(52544003)(199004)(189003)(6246003)(4326008)(76176011)(45080400002)(102836004)(7696005)(25786009)(478600001)(7736002)(66066001)(74316002)(305945005)(14454004)(6506007)(53546011)(229853002)(26005)(99286004)(71190400001)(9686003)(186003)(55016002)(6436002)(76116006)(6306002)(2501003)(71200400001)(66476007)(33656002)(66946007)(66556008)(64756008)(66446008)(52536014)(486006)(86362001)(476003)(8936002)(81166006)(81156014)(8676002)(316002)(11346002)(2201001)(446003)(110136005)(54906003)(256004)(14444005)(5660300002)(3846002)(2906002)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYASPR01MB0038; H:BYAPR13MB2807.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9KabedXHrOkcNgPb48yD9/t6mGoaa+lJnh2+OX2LcIfSGcv8T9LtauQVullfIgiLnQWEWR+M0uCA0HdjlAYrDv76wDvmMYKCA9U4YpR7iG3fOHiOlh0pYfBAZIXjbiYyPgGMf09TRCqeUleQrqR9CLAaJar7VHgvv22i0MYnPZnUWMirGp6P0rBkMJneQDJmHguw+XAvWuA+gn/o4FKY9cT1kVp6Z4MrJTGI7F8FS9HgHuEGF6GLX2sooWH6FYgh9ChV25zM9ZwIJQf8BzyRhT/EwJyA8QvxsczsRVtJC4aI7tyr3MHL+XUYnE2EljOnXtctMFbS7r753qewf1y+sD0Yc9mSDCLcXB7/J4+RDSlLpUsTr57KSwxyzVWJVAs79psN+3iGUuDsFINsgK93IrEScc/PoKDMHsR9oZTxx7elx9ondHqXR6ORWBKdEojl40JnOXD5EX0p0OK9z6eZKg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8c3f5e83-51cf-48cd-bec0-08d750c1ed34 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2019 16:16:52.8875 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rsnFAmaHO5RVPESKjZVvlsbPKxF0cceUK8Wu0gcHRHFBDdKr60tp1YMo2+KDl5ePWAkzgd3c4GvQFkx1uVRrpg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYASPR01MB0038 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-mboned-ieee802-mcast-problems-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 16:17:00 -0000 SGkgRXJpYywNCg0KSSBzcGVudCBhIGZhaXIgYW1vdW50IG9mIHRpbWUgYWRkcmVzc2luZyB5b3Vy IGNvbW1lbnRzIGFuZCBmaWd1cmVkIHdlIHdlcmUgbmVhciB0aGUgZmluaXNoIGxpbmUuIFN1Y2gg aXMgbm90IHRoZSBjYXNlLiAgSSdsbCBub3QgYmUgYWJsZSBhZGRyZXNzIEdvcnJ5J3MgZXh0ZW5z aXZlIGNvbW1lbnRzIGJ5IHRvbW9ycm93IG9yIHRoaXMgd2Vlay4gSSBzaG91bGQgaGF2ZSBhbiB1 cGRhdGUgc29tZXRpbWUgbmV4dCB3ZWVrLg0KDQp0aGFua3MsDQptaWtlDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBFcmljIFZ5bmNrZSAoZXZ5bmNrZSkgPGV2eW5ja2VAY2lz Y28uY29tPiANClNlbnQ6IE1vbmRheSwgT2N0b2JlciAxNCwgMjAxOSAxMjoxMCBBTQ0KVG86IEt5 bGUgUm9zZSA8a3Jvc2VAa3Jvc2Uub3JnPjsgc2VjZGlyQGlldGYub3JnOyBnb3JyeUBlcmcuYWJk bi5hYy51aw0KQ2M6IG1ib25lZEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tYm9uZWQtaWVlZTgwMi1t Y2FzdC1wcm9ibGVtcy5hbGxAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBTZWNkaXIgbGFzdCBjYWxs IHJldmlldyBvZiBkcmFmdC1pZXRmLW1ib25lZC1pZWVlODAyLW1jYXN0LXByb2JsZW1zLTA5DQoN ClRoYW5rIHlvdSBLeWxlIGZvciB0aGUgcmV2aWV3OiBuaXRzIGFyZSBuaXRzIGJ1dCBsZXQncyBm aXggdGhlbSB3aGVuIHRoZSBsYXN0IGNhbGwgZW5kcyAobGF0ZXIgdG9kYXkpLg0KDQpEZWFyIGF1 dGhvcnMsIEkgd291bGQgYXBwcmVjaWF0ZSBpdCBpZiBhIG5ldyByZXZpc2lvbiB3YXMgdXBsb2Fk ZWQgb24gVHVlc2RheSAxNXRoIChpLmUuIGFmdGVyIHRoZSBsYXN0IGNhbGwgZXhwaXJhdGlvbikg Zml4aW5nIGFsbCBpc3N1ZXMgZGV0ZWN0ZWQgaW4gdGhlIGxhc3QgY2FsbCAoc2VlIEdvcnJ5J3Mg ZW1haWwgZGF0ZWQgMm5kIE9jdG9iZXIpIGFuZCBLeWxlJ3Mgb25lIGJlbG93Lg0KDQpPbmNlIGRv bmUsIEkgd2lsbCBwcm9jZWVkIHdpdGggdGhlIHB1YmxpY2F0aW9uIHByb2Nlc3MNCg0KUmVnYXJk cyBhbmQgdGhhbmsgeW91IGluIGFkdmFuY2UNCg0KLcOpcmljIChzaGVwaGVyZGluZyBBRCBmb3Ig dGhpcyBkb2N1bWVudCkNCg0KDQrvu79PbiAxNC8xMC8yMDE5LCAwNTozMywgIkt5bGUgUm9zZSB2 aWEgRGF0YXRyYWNrZXIiIDxub3JlcGx5QGlldGYub3JnPiB3cm90ZToNCg0KICAgIFJldmlld2Vy OiBLeWxlIFJvc2UNCiAgICBSZXZpZXcgcmVzdWx0OiBIYXMgTml0cw0KICAgIA0KICAgIEkgaGF2 ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9y YXRlJ3Mgb25nb2luZw0KICAgIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJl aW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlDQogICAgY29tbWVudHMgd2VyZSB3cml0 dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0 b3JzLg0KICAgICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRo ZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXINCiAgICBsYXN0IGNhbGwgY29tbWVudHMu DQogICAgDQogICAgSSBtYXJrZWQgdGhpcyAicmVhZHkgd2l0aCBuaXRzIiBiZWNhdXNlIEkgc2Vl IG5vIHNlcmlvdXMgc2VjdXJpdHkgb3IgcHJpdmFjeQ0KICAgIGNvbnNpZGVyYXRpb25zLCBidXQg SSdtIGNvbmZ1c2VkIGJ5IHRoZSB3b3JkaW5nIGluIHNlY3Rpb24gNywgd2hpY2ggYmVnaW5zOg0K ICAgIA0KICAgIHEoIFRoaXMgc2VjdGlvbiB3aWxsIHByb3ZpZGUgc29tZSByZWNvbW1lbmRhdGlv bnMgYWJvdXQgdGhlIHVzYWdlIGFuZA0KICAgIGNvbWJpbmF0aW9ucyBvZiB0aGUgbXVsdGljYXN0 IGVuaGFuY2VtZW50cyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0IGFuZCBTZWN0aW9uDQogICAgNS4g KQ0KICAgIA0KICAgIGFuZCB0aGVuIHByb2NlZWRzIHRvIHByb3ZpZGUgbGl0dGxlIGluIHRoZSB3 YXkgb2Ygc3VjaCByZWNvbW1lbmRhdGlvbnMuIE1heWJlDQogICAgdGhlIHBocmFzaW5nIGhlcmUg aXMganVzdCBhd2t3YXJkPw0KICAgIA0KICAgIE5pdHM6DQogICAgDQogICAgUmVmZXJlbmNlIGRv dDExYWENCiAgICAoaHR0cHM6Ly9uYW0wMy5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNBJTJGJTJGc3RhbmRhcmRzLmllZWUub3JnJTJGZmluZHN0ZHMlMkZzdGFu ZGFyZCUyRjgwMi4xMWFhLTIwMTIucGRmJmFtcDtkYXRhPTAyJTdDMDElN0NtaWNoYWVsLm1jYnJp ZGUlNDBmdXR1cmV3ZWkuY29tJTdDNzdlMWRmMTQ1NDI2NDdlZmZiZWUwOGQ3NTA3NThmNTAlN0Mw ZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MxJTdDNjM3MDY2MzM4MTYxNDE5 MzkzJmFtcDtzZGF0YT0lMkJUZ1RkWXRPRXF4JTJGYVZLNSUyRktEQVRPMzZaRTMlMkJhODFHTSUy QkM5SExmeFBybyUzRCZhbXA7cmVzZXJ2ZWQ9MCkgZ2l2ZXMgbWUgYQ0KICAgIDQwNC4gTWF5YmUg SSBzaW1wbHkgbGFjayB0aGUgYXBwcm9wcmlhdGUgZGVjb2RlciByaW5nPw0KICAgIA0KICAgIFRo ZSBJRVRGIG1lZXRpbmcgbmV0d29yayBpcyByZWZlcmVuY2VkIHRocmVlIHRpbWVzIGluIHNlY3Rp b24gNS4xLiBGb3IgZXhhbXBsZSwNCiAgICANCiAgICBxKCBUaGUgZGlzdHJpYnV0aW9uIG9mIHVz ZXJzIG9uIHdpcmVsZXNzIG5ldHdvcmtzIC8gc3VibmV0cyBjaGFuZ2VzIGZyb20gb25lDQogICAg SUVURiBtZWV0aW5nIHRvIHRoZSBuZXh0IChlLmcgU1NJRHMgYXJlIHJlbmFtZWQsIHNvbWUgU1NJ RHMgbG9zZSBmYXZvciwgZXRjKS4gDQogICAgVGhpcyBtYWtlcyB1dGlsaXphdGlvbiBmb3IgcGFy dGljdWxhciBTU0lEcyBkaWZmaWN1bHQgdG8gcHJlZGljdCBhaGVhZCBvZiB0aW1lLA0KICAgIGJ1 dCB1c2FnZSBjYW4gYmUgbW9uaXRvcmVkIGFzIGF0dGVuZGVlcyB1c2UgdGhlIGRpZmZlcmVudCBu ZXR3b3Jrcy4gKQ0KICAgIA0KICAgIFRoaXMgZmVlbHMgbGlrZSBhIG5vbi1zZXF1aXR1ci4gTWF5 YmUgc29tZSBpbnRyb2R1Y3RvcnkgdGV4dCBhYm91dCB1c2luZyB0aGUNCiAgICBJRVRGIG1lZXRp bmdzIGFzIGFuIGV4ZW1wbGFyIHdvdWxkIG1ha2UgdGhpcyByZWFkIGEgbGl0dGxlIGJldHRlciwg YnV0IGl0IHNlZW1zDQogICAgbGlrZSB0aGUgYWR2aWNlIHRvIG9wZXJhdG9ycyBoZXJlIHNob3Vs ZCBiZSBnZW5lcmljIGFuZCBub3QgY29ubmVjdGVkIHRvDQogICAgcGFydGljdWxhciBnb2FscyBm b3IgbmV0d29yayBjb25uZWN0aXZpdHkgYXQgSUVURiBtZWV0aW5ncy4NCiAgICANCiAgICANCg0K From nobody Mon Oct 14 09:27:37 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E8812081C; Mon, 14 Oct 2019 09:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=g0FcRM/O; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=C+p8sScQ 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 UCV9bp8zfMo9; Mon, 14 Oct 2019 09:27:33 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7405312018D; Mon, 14 Oct 2019 09:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5284; q=dns/txt; s=iport; t=1571070453; x=1572280053; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Z3OUKkoxpWi35Yqet9G9aieCgrQg1o03MxPI5qCideU=; b=g0FcRM/OMb/yKXIsMoM7BWEgDKuKZop8zMx2wh/E1BAu0fHaVmQ3pA8e ogE5r5+RlrF9j4AHp3AAr6Tp1EPmZ2ARXKNXZFVXLlE5HZ4xw+VpgTjuR hq+X0QhboDy+8JlGF18XZmuyJCTFXz9Wy0rJSTVIZTa98ZnyalN+gZYX0 s=; IronPort-PHdr: =?us-ascii?q?9a23=3A2hmP3xHa0WjE5UC6meNUT51GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1A3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+efP0fioxH8lqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DjAABvoaRd/4ENJK1mDgwBAQEBAQE?= =?us-ascii?q?BAQEDAQEBAREBAQECAgEBAQGBe4FLKScFbFcgBAsqhCSDRwOKSII3JZd+gUK?= =?us-ascii?q?BEANUCQEBAQwBAS0CAQGEQAIXgkckOBMCAwkBAQQBAQECAQUEbYUtDIVLAQE?= =?us-ascii?q?BBBIREQwBATcBCwQCAQgRBAEBAwImAgICMBUICAIEAQ0FIoMAAYJGAy4BAqR?= =?us-ascii?q?TAoE4iGF1gTKCfQEBBYUGGIIXAwaBDCiMDhiBQD+BEScME4JMPoN9DwUBEgE?= =?us-ascii?q?fF4J3MoIsjGUyIYI3nGpuCoIikRWEBBuCOot6iwyOLYE/l3gCBAIEBQIOAQE?= =?us-ascii?q?FgWkiDVpxcBVlAYJBUBAUgU+BJwELgkCKGDt0gSmNZoJFAQE?= X-IronPort-AV: E=Sophos;i="5.67,296,1566864000"; d="scan'208";a="643686857" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Oct 2019 16:27:32 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x9EGRWrs011181 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Oct 2019 16:27:32 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 14 Oct 2019 11:27:31 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 14 Oct 2019 11:27:31 -0500 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 14 Oct 2019 11:27:31 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A8U1KbQx2EC/imCdNsIThXRxTFi+VnpFpJFd6uz74YVdavdrPt9HS16ZyWt3DLJFRBfCoQqqTZTm2EmB3NDpxYlSrB0MmvfxN2pVlRkguhkQt7+EcXaulbCGpo6kodiRXLj7XmYQA6sEksZI+sSEWJCXCxa9aZU0/qjU/ovNivuZ+amQ4HtrtjhnZzpfjhIogq/vEEtiGXjx+G0skwOmdfib2W/hA4iA3yOxHxXti9NxKGjLP8OmpuLG6zhie1mdtNk7pnK8WmYkwxOTzfptZlIaAlMooJFGzR2oZSWS/ZTcKZ7TSmfZ5OSr5Zk2ZBYZTgLzK9zBAr+akqi6UzbAFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z3OUKkoxpWi35Yqet9G9aieCgrQg1o03MxPI5qCideU=; b=hk5QSS9FrtryydA1aw+hJijB6eEaf0Mquzsdi9WtRY4Rp8jHGXoZSYm9OVBAw1xzb8/cVtaWX/HYQ5gu4f9SeI45d8EPGVSJTcm4eLxwoT4z+N5NSy0F8wZSgdjOc2HUHO9aBXiqS5/i9zoD6QuCDg/JyLPlZNUI7mxDREZg9be4/MFSnah2y1RXHg6I6fYLsGKb3fMLwdRegjMi3iwFglcHlil4XuzTiPPFsuy4jDJqPWDW04u9AOoqV/jeGKXCNonD0diYxV1yko2eEA2Gw0u+1T5eP67yvsIedtLIihru3QbKL8daFgueHEbItAV5AmboubgVfVw8EeytdYU5pg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z3OUKkoxpWi35Yqet9G9aieCgrQg1o03MxPI5qCideU=; b=C+p8sScQiZtMDsWx1DwK4bDdx7wyJQQQSlgicWj/MaJgeARJVZciCjKrGopblCecAptBN9UXLH7knd0GiZQBJpFiIkvigLXb0jgTVpBpcO/k/A3mPMM6WkQ66br0c1gj5q7ZOZZZa49Hid9hbT8LjwjCQLkiFHpAQvgs0wFp6Sk= Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB3661.namprd11.prod.outlook.com (20.178.252.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.21; Mon, 14 Oct 2019 16:27:30 +0000 Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::e4f8:d335:c018:c62a]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::e4f8:d335:c018:c62a%7]) with mapi id 15.20.2347.021; Mon, 14 Oct 2019 16:27:29 +0000 From: "Eric Vyncke (evyncke)" To: Michael McBride , Kyle Rose , "secdir@ietf.org" , "gorry@erg.abdn.ac.uk" CC: "mboned@ietf.org" , "draft-ietf-mboned-ieee802-mcast-problems.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-mboned-ieee802-mcast-problems-09 Thread-Index: AQHVgkAY0N6Z+kqf+kWm4acOtxmCt6dZ2dYAgAB3PQCAACR9AA== Date: Mon, 14 Oct 2019 16:27:29 +0000 Message-ID: References: <157102397341.20776.9338396539567675909@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:e9f7:9043:77eb:a55c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: df6252d7-8ac6-4734-6c01-08d750c36878 x-ms-traffictypediagnostic: MN2PR11MB3661: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01901B3451 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(39860400002)(376002)(346002)(136003)(13464003)(504964003)(52544003)(199004)(189003)(6506007)(71190400001)(99286004)(2201001)(25786009)(8936002)(81166006)(81156014)(8676002)(186003)(76176011)(5660300002)(14454004)(45080400002)(71200400001)(58126008)(102836004)(2501003)(54906003)(53546011)(110136005)(33656002)(86362001)(316002)(478600001)(7736002)(6116002)(305945005)(476003)(2906002)(486006)(11346002)(256004)(14444005)(6306002)(2616005)(36756003)(4326008)(66446008)(64756008)(66556008)(66476007)(66946007)(76116006)(91956017)(6486002)(6436002)(6246003)(6512007)(46003)(229853002)(446003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3661; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: k8v9HYVT00tcPzfdFiJ78xROpOhNzVzeEVALWC7Xcf7M5nmifXJ2ns46O5e6KWjRzSWxpkg/z7ce9y8OYP/R8ti6GPEOhrLzitONTVXxwnHweT+0DXjVwoqogTWlbImbe4Z/dS6wyRW8B7jEP70lRCYEvqY20HpeeU05AqdZYT2MDlL4TsSDUd0ntVVaxjLit7rQ5s0/uS8Oc1X6228k0xbKqhfS5ksryhfArEKVqNl8F4TYgmntKi4xDRDKiVsyJsYA0XgQLDyoHJQ2eRrUGOhV6/pe8Cr20ZxALVZD2VzVWlQw0Lwfbq3M8SyknYLsVeTIeskxCRVw+AFs+9ROiHLwB2SZk5WniwoZD1XkZHz7AaTTZ6cmnOKg6GVlsA3iq6+n+Pz2cT1eOhF/L9ye7uvfl0NgRbnuZKFsUeXqOoFlVD1+x7o5+98DtoNZNV3X2Q3QFZmhSnCN1s/qnzpWXw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <3ACE6D75304F96488E375A1F435DB0B0@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: df6252d7-8ac6-4734-6c01-08d750c36878 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2019 16:27:29.6132 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vbzaxnVlIFh7FgH/QqJ3JpCXbEgBQCXs8saogGo/fmfsu9oTYOoMHnShHY2TAoUjalb14MEMpVzHNVuNPtdj8w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3661 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.21, xch-aln-011.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-mboned-ieee802-mcast-problems-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 16:27:36 -0000 TWlrZQ0KDQpOb3RoaW5nIHVyZ2VudCBvbiBteSBzaWRlIGJ1dCBJIHdpbGwgd2FpdCBmb3IgdGhp cyBuZXcgcmV2aXNpb24gYmVmb3JlIGdvaW5nIGZvcndhcmQgd2l0aCB0aGUgcHVibGljYXRpb24g cHJvY2VzcyB0byBhdm9pZCBkdXBsaWNhdGUgcmV2aWV3cy4NCg0KUmVnYXJkcyBhbmQgdGhhbmsg eW91IGluIGFkdmFuY2UNCg0KLcOpcmljDQoNCu+7v09uIDE0LzEwLzIwMTksIDE4OjE3LCAiTWlj aGFlbCBNY0JyaWRlIiA8bWljaGFlbC5tY2JyaWRlQGZ1dHVyZXdlaS5jb20+IHdyb3RlOg0KDQog ICAgSGkgRXJpYywNCiAgICANCiAgICBJIHNwZW50IGEgZmFpciBhbW91bnQgb2YgdGltZSBhZGRy ZXNzaW5nIHlvdXIgY29tbWVudHMgYW5kIGZpZ3VyZWQgd2Ugd2VyZSBuZWFyIHRoZSBmaW5pc2gg bGluZS4gU3VjaCBpcyBub3QgdGhlIGNhc2UuICBJJ2xsIG5vdCBiZSBhYmxlIGFkZHJlc3MgR29y cnkncyBleHRlbnNpdmUgY29tbWVudHMgYnkgdG9tb3Jyb3cgb3IgdGhpcyB3ZWVrLiBJIHNob3Vs ZCBoYXZlIGFuIHVwZGF0ZSBzb21ldGltZSBuZXh0IHdlZWsuDQogICAgDQogICAgdGhhbmtzLA0K ICAgIG1pa2UNCiAgICANCiAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgIEZyb206 IEVyaWMgVnluY2tlIChldnluY2tlKSA8ZXZ5bmNrZUBjaXNjby5jb20+IA0KICAgIFNlbnQ6IE1v bmRheSwgT2N0b2JlciAxNCwgMjAxOSAxMjoxMCBBTQ0KICAgIFRvOiBLeWxlIFJvc2UgPGtyb3Nl QGtyb3NlLm9yZz47IHNlY2RpckBpZXRmLm9yZzsgZ29ycnlAZXJnLmFiZG4uYWMudWsNCiAgICBD YzogbWJvbmVkQGlldGYub3JnOyBkcmFmdC1pZXRmLW1ib25lZC1pZWVlODAyLW1jYXN0LXByb2Js ZW1zLmFsbEBpZXRmLm9yZw0KICAgIFN1YmplY3Q6IFJlOiBTZWNkaXIgbGFzdCBjYWxsIHJldmll dyBvZiBkcmFmdC1pZXRmLW1ib25lZC1pZWVlODAyLW1jYXN0LXByb2JsZW1zLTA5DQogICAgDQog ICAgVGhhbmsgeW91IEt5bGUgZm9yIHRoZSByZXZpZXc6IG5pdHMgYXJlIG5pdHMgYnV0IGxldCdz IGZpeCB0aGVtIHdoZW4gdGhlIGxhc3QgY2FsbCBlbmRzIChsYXRlciB0b2RheSkuDQogICAgDQog ICAgRGVhciBhdXRob3JzLCBJIHdvdWxkIGFwcHJlY2lhdGUgaXQgaWYgYSBuZXcgcmV2aXNpb24g d2FzIHVwbG9hZGVkIG9uIFR1ZXNkYXkgMTV0aCAoaS5lLiBhZnRlciB0aGUgbGFzdCBjYWxsIGV4 cGlyYXRpb24pIGZpeGluZyBhbGwgaXNzdWVzIGRldGVjdGVkIGluIHRoZSBsYXN0IGNhbGwgKHNl ZSBHb3JyeSdzIGVtYWlsIGRhdGVkIDJuZCBPY3RvYmVyKSBhbmQgS3lsZSdzIG9uZSBiZWxvdy4N CiAgICANCiAgICBPbmNlIGRvbmUsIEkgd2lsbCBwcm9jZWVkIHdpdGggdGhlIHB1YmxpY2F0aW9u IHByb2Nlc3MNCiAgICANCiAgICBSZWdhcmRzIGFuZCB0aGFuayB5b3UgaW4gYWR2YW5jZQ0KICAg IA0KICAgIC3DqXJpYyAoc2hlcGhlcmRpbmcgQUQgZm9yIHRoaXMgZG9jdW1lbnQpDQogICAgDQog ICAgDQogICAgT24gMTQvMTAvMjAxOSwgMDU6MzMsICJLeWxlIFJvc2UgdmlhIERhdGF0cmFja2Vy IiA8bm9yZXBseUBpZXRmLm9yZz4gd3JvdGU6DQogICAgDQogICAgICAgIFJldmlld2VyOiBLeWxl IFJvc2UNCiAgICAgICAgUmV2aWV3IHJlc3VsdDogSGFzIE5pdHMNCiAgICAgICAgDQogICAgICAg IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRp cmVjdG9yYXRlJ3Mgb25nb2luZw0KICAgICAgICBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRv Y3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZQ0KICAgICAgICBjb21t ZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJp dHkgYXJlYSBkaXJlY3RvcnMuDQogICAgICAgICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFp cnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXINCiAgICAg ICAgbGFzdCBjYWxsIGNvbW1lbnRzLg0KICAgICAgICANCiAgICAgICAgSSBtYXJrZWQgdGhpcyAi cmVhZHkgd2l0aCBuaXRzIiBiZWNhdXNlIEkgc2VlIG5vIHNlcmlvdXMgc2VjdXJpdHkgb3IgcHJp dmFjeQ0KICAgICAgICBjb25zaWRlcmF0aW9ucywgYnV0IEknbSBjb25mdXNlZCBieSB0aGUgd29y ZGluZyBpbiBzZWN0aW9uIDcsIHdoaWNoIGJlZ2luczoNCiAgICAgICAgDQogICAgICAgIHEoIFRo aXMgc2VjdGlvbiB3aWxsIHByb3ZpZGUgc29tZSByZWNvbW1lbmRhdGlvbnMgYWJvdXQgdGhlIHVz YWdlIGFuZA0KICAgICAgICBjb21iaW5hdGlvbnMgb2YgdGhlIG11bHRpY2FzdCBlbmhhbmNlbWVu dHMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNCBhbmQgU2VjdGlvbg0KICAgICAgICA1LiApDQogICAg ICAgIA0KICAgICAgICBhbmQgdGhlbiBwcm9jZWVkcyB0byBwcm92aWRlIGxpdHRsZSBpbiB0aGUg d2F5IG9mIHN1Y2ggcmVjb21tZW5kYXRpb25zLiBNYXliZQ0KICAgICAgICB0aGUgcGhyYXNpbmcg aGVyZSBpcyBqdXN0IGF3a3dhcmQ/DQogICAgICAgIA0KICAgICAgICBOaXRzOg0KICAgICAgICAN CiAgICAgICAgUmVmZXJlbmNlIGRvdDExYWENCiAgICAgICAgKGh0dHBzOi8vbmFtMDMuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnN0YW5kYXJkcy5p ZWVlLm9yZyUyRmZpbmRzdGRzJTJGc3RhbmRhcmQlMkY4MDIuMTFhYS0yMDEyLnBkZiZhbXA7ZGF0 YT0wMiU3QzAxJTdDbWljaGFlbC5tY2JyaWRlJTQwZnV0dXJld2VpLmNvbSU3Qzc3ZTFkZjE0NTQy NjQ3ZWZmYmVlMDhkNzUwNzU4ZjUwJTdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMl N0MxJTdDMSU3QzYzNzA2NjMzODE2MTQxOTM5MyZhbXA7c2RhdGE9JTJCVGdUZFl0T0VxeCUyRmFW SzUlMkZLREFUTzM2WkUzJTJCYTgxR00lMkJDOUhMZnhQcm8lM0QmYW1wO3Jlc2VydmVkPTApIGdp dmVzIG1lIGENCiAgICAgICAgNDA0LiBNYXliZSBJIHNpbXBseSBsYWNrIHRoZSBhcHByb3ByaWF0 ZSBkZWNvZGVyIHJpbmc/DQogICAgICAgIA0KICAgICAgICBUaGUgSUVURiBtZWV0aW5nIG5ldHdv cmsgaXMgcmVmZXJlbmNlZCB0aHJlZSB0aW1lcyBpbiBzZWN0aW9uIDUuMS4gRm9yIGV4YW1wbGUs DQogICAgICAgIA0KICAgICAgICBxKCBUaGUgZGlzdHJpYnV0aW9uIG9mIHVzZXJzIG9uIHdpcmVs ZXNzIG5ldHdvcmtzIC8gc3VibmV0cyBjaGFuZ2VzIGZyb20gb25lDQogICAgICAgIElFVEYgbWVl dGluZyB0byB0aGUgbmV4dCAoZS5nIFNTSURzIGFyZSByZW5hbWVkLCBzb21lIFNTSURzIGxvc2Ug ZmF2b3IsIGV0YykuIA0KICAgICAgICBUaGlzIG1ha2VzIHV0aWxpemF0aW9uIGZvciBwYXJ0aWN1 bGFyIFNTSURzIGRpZmZpY3VsdCB0byBwcmVkaWN0IGFoZWFkIG9mIHRpbWUsDQogICAgICAgIGJ1 dCB1c2FnZSBjYW4gYmUgbW9uaXRvcmVkIGFzIGF0dGVuZGVlcyB1c2UgdGhlIGRpZmZlcmVudCBu ZXR3b3Jrcy4gKQ0KICAgICAgICANCiAgICAgICAgVGhpcyBmZWVscyBsaWtlIGEgbm9uLXNlcXVp dHVyLiBNYXliZSBzb21lIGludHJvZHVjdG9yeSB0ZXh0IGFib3V0IHVzaW5nIHRoZQ0KICAgICAg ICBJRVRGIG1lZXRpbmdzIGFzIGFuIGV4ZW1wbGFyIHdvdWxkIG1ha2UgdGhpcyByZWFkIGEgbGl0 dGxlIGJldHRlciwgYnV0IGl0IHNlZW1zDQogICAgICAgIGxpa2UgdGhlIGFkdmljZSB0byBvcGVy YXRvcnMgaGVyZSBzaG91bGQgYmUgZ2VuZXJpYyBhbmQgbm90IGNvbm5lY3RlZCB0bw0KICAgICAg ICBwYXJ0aWN1bGFyIGdvYWxzIGZvciBuZXR3b3JrIGNvbm5lY3Rpdml0eSBhdCBJRVRGIG1lZXRp bmdzLg0KICAgICAgICANCiAgICAgICAgDQogICAgDQogICAgDQoNCg== From nobody Mon Oct 14 09:31:05 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D4A12081C; Mon, 14 Oct 2019 09:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 wqv2O-f1m_QE; Mon, 14 Oct 2019 09:30:54 -0700 (PDT) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE2412007C; Mon, 14 Oct 2019 09:30:54 -0700 (PDT) Received: from in01.mta.xmission.com ([166.70.13.51]) by out02.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1iK3FF-0004Z1-Io; Mon, 14 Oct 2019 10:30:53 -0600 Received: from [166.70.232.207] (helo=rumpleteazer.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1iK3FE-0007Po-LL; Mon, 14 Oct 2019 10:30:53 -0600 Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id x9EGQmWq011554; Mon, 14 Oct 2019 10:26:48 -0600 Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id x9EGQlwi011553; Mon, 14 Oct 2019 10:26:47 -0600 Date: Mon, 14 Oct 2019 10:26:47 -0600 Message-Id: <201910141626.x9EGQlwi011553@rumpleteazer.rhmr.com> From: "Hilarie Orman" Reply-To: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org Cc: draft-ietf-6tisch-minimal-security.all@tools.ietf.org X-XM-SPF: eid=1iK3FE-0007Po-LL; ; ; mid=<201910141626.x9EGQlwi011553@rumpleteazer.rhmr.com>; ; ; hst=in01.mta.xmission.com; ; ; ip=166.70.232.207; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-AID: U2FsdGVkX19tqvC2vPS8AjFBMrb3G7RQ X-SA-Exim-Connect-IP: 166.70.232.207 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa08 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 389 ms - load_scoreonly_sql: 0.08 (0.0%), signal_user_changed: 3.5 (0.9%), b_tie_ro: 2.4 (0.6%), parse: 0.69 (0.2%), extract_message_metadata: 3.1 (0.8%), get_uri_detail_list: 0.88 (0.2%), tests_pri_-1000: 2.6 (0.7%), tests_pri_-950: 1.50 (0.4%), tests_pri_-900: 1.25 (0.3%), tests_pri_-90: 21 (5.3%), check_bayes: 19 (4.9%), b_tokenize: 4.3 (1.1%), b_tok_get_all: 6 (1.6%), b_comp_prob: 2.2 (0.6%), b_tok_touch_all: 2.9 (0.7%), b_finish: 0.89 (0.2%), tests_pri_0: 345 (88.8%), check_dkim_signature: 0.45 (0.1%), check_dkim_adsp: 6 (1.6%), poll_dns_idle: 0.71 (0.2%), tests_pri_10: 2.2 (0.6%), tests_pri_500: 6 (1.4%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Archived-At: Subject: [secdir] Security review of draft-ietf-6tisch-minimal-security-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 16:30:56 -0000 Security review of Minimal Security Framework for 6TiSCH draft-ietf-6tisch-minimal-security-12 Do not be alarmed. I generated this review of this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Nodes can join a 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4e) network) by issuing a request that is validated using pre-shared keys. The document defines the Constrained Join Protocol and its data structures. The security considerations section has been done well. The "short identifier" space consideration on page 34 might be problematic under extreme conditions. If almost all values have been used, a set of nodes might cause trouble by constantly sending join requests. The JRC(s) would have to time out their previous information, and there might be long delays before a short identifier could be freed up. Perhaps there should be a rate limit on join requests from any single node. (If there is such a limit I didn't see it). Page 20 and page 23 mention "the user", but it is unclear what "user" means in this framework. Page 34 says that "the loss of security properties is eminent". That intended word was probably "imminent". I suggest rephrasing. Page 37 asks the reader to recall a "well-known" Bluetooth problem, but there is no citation for it. Either document it or remove it. Hilarie Orman From nobody Mon Oct 14 16:35:20 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A6A1208A7 for ; Mon, 14 Oct 2019 16:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHjQtPByp-gF for ; Mon, 14 Oct 2019 16:35:16 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 C55B61200EB for ; Mon, 14 Oct 2019 16:35:15 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9ENZAv3013700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Oct 2019 19:35:13 -0400 Date: Mon, 14 Oct 2019 16:35:10 -0700 From: Benjamin Kaduk To: Magnus =?iso-8859-1?Q?Nystr=F6m?= Cc: secdir@ietf.org Message-ID: <20191014233510.GJ61805@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-ipsecme-implicit-iv-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 23:35:18 -0000 Hi Magnus, Thanks for this review -- I filed a Discuss point about the inconsistency between the text and the codepoints for whether AES-CTR is covered. -Ben On Sun, Oct 13, 2019 at 10:46:30PM -0700, Magnus Nystrm wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > > This document defines a mechanism to save on bandwidth in ESP connections > when certain ciphers have been negotiated by using implicit IVs. The > savings are limited to 8 bytes for the current version of this document. > > > > - Section 2 mentions AES-CCM, AES-CTR, AES-GCM and ChaCha. For all of > these ciphers, an 8-byte nonce is used. The mechanism to make the IV > implicit is by coupling it to the sequence number. Yet, Section 4 gives two > examples of sequence numbers, one of 4 bytes and one of 8 bytes. This is > confusing, presumably only the extended sequence number is usable? > - Also, while the Abstract says the memo offers a mechanism to save on > the explicit IV also for AES-CTR, and Section 2 includes AES-CTR in its > description, Section 4 explicitly states that only AES-CCM, AES-GCM and > ChaCha are subject of the optimization in this memo. This is also > confusing. Why including AES-CTR in the memo at all if it isn't covered? At > the very least it seems the Abstract should be updated. > - It would be very helpful and useful to include an example of a > handshake with an IIV and the resulting IV in an Appendix; this could > assist implementors to get things right. > > > (Editorial: English grammar needs some updates/reviews) > > Thanks, > -- Magnus > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Tue Oct 15 10:53:38 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540941208E4; Tue, 15 Oct 2019 10:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PN93PKNPH0uu; Tue, 15 Oct 2019 10:52:18 -0700 (PDT) Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com [209.85.217.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46624120886; Tue, 15 Oct 2019 10:52:17 -0700 (PDT) Received: by mail-vs1-f42.google.com with SMTP id b1so13749278vsr.10; Tue, 15 Oct 2019 10:52:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=GEXykJHc0Ug2DuiLdRIPW3fR4fd+uGsnQjWf2xG66Yw=; b=P9QOiScJC3rBpyg9366m+CG0EBYEyp2BRKKRCJcMlMgX50AWTni2GsJwmXMIadJhmj zdNhw3SYzQPp+X8OQV3taj8PAz9726Lw6tBy71lRr16jVBTQXKBJpsFRdyMBbJ/N1RZ4 l/EAJ8zyucU+4WYc8gRvY0RNp0HaNyelsYoYV5Y+/sUmcGJ6pMdcH1IoeuGGqAA9wrW8 DGrGIQDciBL8Z1R5DJ/vQY3/Z90/DXlqFETv4xjfqpR/S6ipsO0HnPuhh6DmIaM/sylS V5dD0rI1u4owcoEatlAIQ5bfhil6hC7pWPMbQrSBBTQiPw9bXk0HxfZqUvJOLCA+RJOy dkpg== X-Gm-Message-State: APjAAAW6uX8nTiM4A8AlV/uheBdfMpnuyLMnnNVvk2WrM8p890OdktnH 9MCW6bDvMiTNC2sKc4PyoE8q10LyH8viBOtZ5Wo= X-Google-Smtp-Source: APXvYqxBbtgXeYaMpgHUkaORM3k9QXx7Zjz+7XU2xiPkLLnu/jOJa8Cfcc35SnI+hCwUItYIeTUW6MfYByMWuz/DouM= X-Received: by 2002:a67:685:: with SMTP id 127mr1183759vsg.169.1571161936259; Tue, 15 Oct 2019 10:52:16 -0700 (PDT) MIME-Version: 1.0 References: <20191014233510.GJ61805@kduck.mit.edu> In-Reply-To: From: Daniel Migault Date: Tue, 15 Oct 2019 13:52:05 -0400 Message-ID: To: "mglt.ietf@gmail.com" , secdir@ietf.org, Benjamin Kaduk , "Roman D. Danyliw" , IPsecME WG , The IESG Content-Type: multipart/alternative; boundary="00000000000018706d0594f6a5f3" Archived-At: Subject: Re: [secdir] FW: Secdir review of draft-ietf-ipsecme-implicit-iv-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 17:52:26 -0000 --00000000000018706d0594f6a5f3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Magnus, Thank you for the review. Please find my response inline as well as the updated text: https://github.com/mglt/draft-mglt-ipsecme-implicit-iv/blob/master/draft-ie= tf-ipsecme-implicit-iv.txt We will probably publish the new version by tomorrow. Yours, Daniel On Tue, Oct 15, 2019 at 8:53 AM Daniel Migault wrote: > > > -----Original Message----- > From: secdir On Behalf Of Benjamin Kaduk > Sent: Monday, October 14, 2019 7:35 PM > To: Magnus Nystr=C3=B6m > Cc: secdir@ietf.org > Subject: Re: [secdir] Secdir review of draft-ietf-ipsecme-implicit-iv-07 > > Hi Magnus, > > Thanks for this review -- I filed a Discuss point about the inconsistency > between the text and the codepoints for whether AES-CTR is covered. > > -Ben > > On Sun, Oct 13, 2019 at 10:46:30PM -0700, Magnus Nystr=C3=B6m wrote: > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the IESG= . > > These comments were written primarily for the benefit of the security > > area directors. Document editors and WG chairs should treat these > > comments just like any other last call comments. > > > > This document defines a mechanism to save on bandwidth in ESP > > connections when certain ciphers have been negotiated by using > > implicit IVs. The savings are limited to 8 bytes for the current versio= n > of this document. > > > > > > > > - Section 2 mentions AES-CCM, AES-CTR, AES-GCM and ChaCha. For all o= f > > these ciphers, an 8-byte nonce is used. The mechanism to make the IV > > implicit is by coupling it to the sequence number. Yet, Section 4 > gives two > > examples of sequence numbers, one of 4 bytes and one of 8 bytes. > This is > > confusing, presumably only the extended sequence number is usable? > I think that is correct. AES-GCM, AES-CCM and Chach20-poly1305 defined for IPsec are taking a nonce as an input value and this nonce takes the ESP.IV field as input to be computed. In our case ESP.IV is 8 byte long. The document defines how ESP.IV value can be generated form the sequence number. As the sequence number can be extended or not we define two ways to generate the ESP.IV value. In both cases, the result is always a 8 byte value. We will update section 2 to make a clear distinction between IV and nonce. Some more explanations: IPsec/ESP: ESP RF4303 defines the IV field whose length is negotiated with the algorithm. AES-CCM: SP800-38c defines AES-CCM and RFC4309 defines the use of AES-CCM in IPsec. In both specifications, the 'none' is described as an input parameter. RFC4309 defines this nonce as a function of a salt and the ESP.IV field. RFC4309 defines ESP.IV field as 8 byte long. The current document defines how to generates the IV from the sequence numbers. The document defines two ways to generate the IV depending if extended sequence number is used or not and teh resulting IV is always 8 byte long. AES-GCM: SP800-38D defines AES-GCM and RFC4106 defines the use of AES-GCM in IPSec. In both specification GCM needs an input designated as IV. To distinguish that IV (GMC.IV) and the field defined by ESP, the IV used by GCM is designated in RFC4106 as nonce. That is GCM.IV =3D 'nonce' and ESP.IV =3D I= V. This brings us in the previous case of CCM where the nonce is an input parameter for GCM. Similarly to CCM the nonce is a function of a salt and ESP.IV which is 8 byte long. Chacha20-Poly1305: RFC7539 defines chacha20poly1305 and RFC7634 defines the use of Chacha20poly in IPsec/ESP. In both specifications the nonce is described as an input parameter. The nonce is described as a function of the ESP.IV and a salt with ESP.IV of 8 byte long. This brings us in the previous case of CCM where the nonce is an input parameter for GCM. Similarly to CCM the nonce is a function of a salt and ESP.IV which is 8 byte long. > > - Also, while the Abstract says the memo offers a mechanism to save = on > > the explicit IV also for AES-CTR, and Section 2 includes AES-CTR in > its > > description, Section 4 explicitly states that only AES-CCM, AES-GCM > and > > ChaCha are subject of the optimization in this memo. This is also > > confusing. Why including AES-CTR in the memo at all if it isn't > covered? At > > the very least it seems the Abstract should be updated. > The reason we did not assigned a code point for AES-CTR was that none was really asking for that code point. In addition and we did not want to assign a code point for an algorithm that is not recommended by RFC8221. (MAY be implemented status). AES-CTR is not AEAD and we would not like to encourage its use. On the other hand, the same mechanism applies. We will remove CTR from the document and that the same mechanism can be applied is caught by the following sentence: "" This document limits its scope to the algorithms mentioned above. Other algorithms with similar properties may later be defined to use similar mechanism. """ That said, re-reading the document, we provide some explanation on CBC, so the current version explains why we are excluding CTR. This could be also removed. > - It would be very helpful and useful to include an example of a > > handshake with an IIV and the resulting IV in an Appendix; this coul= d > > assist implementors to get things right. > > > I am unclear what would be represented in the exchange. The IKEv2 exchange does not really differ from a the regular negotiation of a specific encryption algorithm. The impact is mostly affecting how the encryption, decryption is performed. I believe that the clarification with IV/Nonce will address this concern. However, if there is anything specific you would like to see in the appendix, please feel free to let us know. > > > > (Editorial: English grammar needs some updates/reviews) > > > > Thanks, > > -- Magnus > > > _______________________________________________ > > secdir mailing list > > secdir@ietf.org > > https://www.ietf.org/mailman/listinfo/secdir > > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > --00000000000018706d0594f6a5f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Magnus,=C2=A0

    Thank you f= or the review.=C2=A0

    Please find my res= ponse inline as well as the updated=C2=A0text:

    Yours,=C2=A0
    Daniel
    =

    = On Tue, Oct 15, 2019 at 8:53 AM Daniel Migault <daniel.migault@ericsson.com>= ; wrote:


    -----Original Message-----
    From: secdir <secdir-bounces@ietf.org> On Behalf Of Benjamin Kaduk
    Sent: Monday, October 14, 2019 7:35 PM
    To: Magnus Nystr=C3=B6m <magnusn@gmail.com>
    Cc: secdir@ietf.org
    Subject: Re: [secdir] Secdir review of draft-ietf-ipsecme-implicit-iv-07
    Hi Magnus,

    Thanks for this review -- I filed a Discuss point about the inconsistency b= etween the text and the codepoints for whether AES-CTR is covered.

    -Ben

    On Sun, Oct 13, 2019 at 10:46:30PM -0700, Magnus Nystr=C3=B6m wrote:
    >=C2=A0 I have reviewed this document as part of the security directorat= e's
    > ongoing effort to review all IETF documents being processed by the IES= G.
    > These comments were written primarily for the benefit of the security =
    > area directors.=C2=A0 Document editors and WG chairs should treat thes= e
    > comments just like any other last call comments.
    >
    > This document defines a mechanism to save on bandwidth in ESP
    > connections when certain ciphers have been negotiated by using
    > implicit IVs. The savings are limited to 8 bytes for the current versi= on of this document.
    >
    >
    >
    >=C2=A0 =C2=A0 - Section 2 mentions AES-CCM, AES-CTR, AES-GCM and ChaCha= . For all of
    >=C2=A0 =C2=A0 these ciphers, an 8-byte nonce is used. The mechanism to = make the IV
    >=C2=A0 =C2=A0 implicit is by coupling it to the sequence number. Yet, S= ection 4 gives two
    >=C2=A0 =C2=A0 examples of sequence numbers, one=C2=A0 of 4 bytes and on= e of 8 bytes. This is
    >=C2=A0 =C2=A0 confusing, presumably only the extended sequence number i= s usable?



    IPsec/= ESP:
    ESP RF4303 defines the IV field whose length is negotiated with th= e algorithm.=C2=A0

    AES-CCM:
    SP800-38c defines AES-CCM and RFC4309= defines the use of AES-CCM in IPsec. In both specifications, the 'none= ' is described as an input parameter. RFC4309 defines this nonce as a f= unction of a salt and the ESP.IV field. RFC4309 defines ESP.IV field as 8 b= yte long. =C2=A0
    The current document defines how to generates the IV fr= om the sequence numbers. The document defines two ways to generate the IV d= epending if extended sequence number is used or not and teh resulting IV is= always 8 byte long.

    AES-GCM:
    SP800-38D defines AES-GCM and RFC4= 106 defines the use of AES-GCM in IPSec. In both specification GCM needs an= input designated as IV. To distinguish that IV (GMC.IV) and the field defi= ned by ESP, the IV used by GCM is designated in RFC4106 as nonce. That is G= CM.IV =3D 'nonce' and ESP.IV =3D IV. This brings us =C2=A0in the pr= evious case of CCM where the nonce is an input parameter for GCM. Similarly= to CCM the nonce is a function of a salt and ESP.IV which is 8 byte long. =

    Chacha20-Poly1305:
    RFC7539 defines chacha20poly1305 and RFC7634 = defines the use of Chacha20poly in IPsec/ESP. In both specifications the no= nce is described as an input parameter. The nonce is described as a functio= n of the ESP.IV and a salt with ESP.IV of 8 byte long. This brings us =C2= =A0in the previous case of CCM where the nonce is an input parameter for GC= M. Similarly to CCM the nonce is a function of a salt and ESP.IV which is 8= byte long.=C2=A0

    >=C2=A0 =C2=A0 - Also, while the Abstract says the memo offers a mechani= sm to save on
    >=C2=A0 =C2=A0 the explicit IV also for AES-CTR, and Section 2 includes = AES-CTR in its
    >=C2=A0 =C2=A0 description, Section 4 explicitly states that only AES-CC= M, AES-GCM and
    >=C2=A0 =C2=A0 ChaCha are subject of the optimization in this memo. This= is also
    >=C2=A0 =C2=A0 confusing. Why including AES-CTR in the memo at all if it= isn't covered? At
    >=C2=A0 =C2=A0 the very least it seems the Abstract should be updated.


    Other algorithms with sim= ilar properties may later be defined to use
    similar mechanism.
    """
    <= br>
    That said, re-reading the document, we = provide some explanation on CBC, so the current version explains why we are= excluding CTR. This could be also removed.=C2=A0

    >=C2=A0 =C2=A0 - It would be very helpful and useful to include an examp= le of a
    >=C2=A0 =C2=A0 handshake with an IIV and the resulting IV in an Appendix= ; this could
    >=C2=A0 =C2=A0 assist implementors to get things right.
    >
    I am unclear what would be represented in the ex= change. The IKEv2 exchange does not really differ from a the regular negoti= ation of a specific encryption algorithm. The impact is mostly affecting ho= w the encryption, decryption is performed. I believe that the clarification= with IV/Nonce will address this concern. However, if there is anything spe= cific you would like to see in the appendix, please feel free to let us kno= w.=C2=A0
    =C2=A0=C2=A0=C2=A0
    >
    > (Editorial: English grammar needs some updates/reviews)
    >
    > Thanks,
    > -- Magnus

    > _______________________________________________
    > secdir mailing list
    >     secdir@ietf.org
    >     https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/= wiki/SecDirReview

    _______________________________________________
    secdir mailing list
    secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir
    wiki: http://tools.ietf.org/area/sec/trac/wiki/= SecDirReview
    --00000000000018706d0594f6a5f3-- From nobody Wed Oct 16 04:12:15 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AFB1200EC; Wed, 16 Oct 2019 04:12:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Paul Wouters via Datatracker To: Cc: ietf@ietf.org, draft-ietf-taps-transport-security.all@ietf.org, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Paul Wouters Message-ID: <157122432277.7898.5381887084807383180@ietfa.amsl.com> Date: Wed, 16 Oct 2019 04:12:02 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-taps-transport-security-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 11:12:03 -0000 Reviewer: Paul Wouters Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is: Ready I had done an early review and checked the differences since, and it addressed my remaining nits. From nobody Wed Oct 16 04:34:06 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DFA120227 for ; Wed, 16 Oct 2019 04:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.184 X-Spam-Level: **** X-Spam-Status: No, score=4.184 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FROM_MISSP_SPF_FAIL=0.714, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001, SPF_HELO_NONE=0.001, TO_EQ_FM_DOM_HTML_ONLY=0.439, TO_EQ_FM_DOM_SPF_FAIL=0.001, TO_EQ_FM_HTML_ONLY=0.849, TO_EQ_FM_SPF_FAIL=1.276, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5kZPqLvEvAv for ; Wed, 16 Oct 2019 04:34:03 -0700 (PDT) Received: from mail.web-tamashin.jp (181.243.128.210.static.iijgio.jp [210.128.243.181]) by ietfa.amsl.com (Postfix) with ESMTP id 1E80312006A for ; Wed, 16 Oct 2019 04:34:03 -0700 (PDT) Received: from fixed-138-186-29-150.totalplay.net (unknown [192.168.0.2]) by mail.web-tamashin.jp (Postfix) with ESMTP id 960095DA99 for ; Wed, 16 Oct 2019 20:11:34 +0900 (JST) From: Mejores Ventas To: secdir@ietf.org Date: 16 Oct 2019 06:11:33 -0500 Message-ID: <20191016061133.5162BB616180227C@ietf.org> MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [secdir] Directorio Empresarial Mexico - Octubre 2019. X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 11:34:05 -0000 google

    = DIRECTORIO EMPRESARIAL MEXICANO 2019

      

    ! = SE INCLUYEN INCLUYE 2 DIRECTORIOS !

      = B) Directorio Empresarial de mas de 2= millones de empresas a nivel nacional en formato Excel con DATOS COMPLETOS= =2E

      (N= ombre Empresa, Contacto, E-mail, Telefono, Direccion, Pues= to, Giro, Pagina Web, Tamaño de Empresa, ETC.)

    B) = ; Directorio Empresarial de 18 millones de mails empresariales dividid= os por ESTADO.

    900,000 e= mpresas del D.F. y Edo. de Mexico

    6,000 Teq= uileras a Nivel nacional

    300,000 e= mpresas en Guadalajara

    500,000 e= mpresas a nivel nacional (grande, mediana y pequeña)

    140,000 e= mpresas en Monterrey

    130,000 P= ymes a nivel nacional

    40,000 em= presas de la industria turistica a nivel nacional

    57,000 em= presas de la industria manufacturera a nivel nacional=

    36,000 em= presas con organigrama a nivel nacional

    60,000 em= presas del sector de la construccion a nivel nacional

    3,000 emp= resas en sistemas

    2,000 Dat= os de universidades a nivel nacional

    15,000 em= presas medianas con numero de empleados

    11,000 em= presas importantes en Mexico (gobierno, instituciones bancarias, etc.)=

    20,000 ar= eas salud a nivel nacional

    10,000 em= presas del sector de agricultura en Mexico

    45,000 em= presas medianas en el Edo. De Mexico

    8,000 fra= nquicias en Mexico

    1.5 Millones de ejecu= tivos divididos en 3 sectores empresariales (UNICAMENTE CORREOS)<= /o:p>

    2 millones de mails d= e diferentes expos en Mexico (UNICAMENTE CORREOS)

    3.5 millones de mails= varias industrias en todo Mexico (UNICAMENTE CORREOS)

    50,000 Industria Farm= aceutica (UNICAMENTE CORREOS)

    175,000 Monterrey (UN= ICAMENTE CORREOS)

    35,000 Queretaro (UNI= CAMENTE CORREOS)

    55,000 Guadalajara &n= bsp;(UNICAMENTE CORREOS)

    15,000 Area Bancaria = (UNICAMENTE CORREOS)

    130,000 mails empresa= riales divididos por estado (UNICAMENTE CORREOS)

    12,000 mails Camaras = de Comercio (UNICAMENTE CORREOS)

    30,000 mails dividido= s por rubros (UNICAMENTE CORREOS)

    45,000 mails Industri= a Constructora (UNICAMENTE CORREOS)

    23,000 mails Industri= a Tecnologica (UNICAMENTE CORREOS)

    90,000 pymes D.F. y E= do. Mexico (UNICAMENTE CORREOS)

    25,000 Visitantes a E= xpos en Franquicias (UNICAMENTE CORREOS)

    Y MUCH= AS BASES MAS…

    =

    Solo Valido HASTA el Viernes 18 de Octubre 2019=

    Precio por promocion: $ 6,900.00 + IVA <= o:p>

    Precio normal: $ 19= ,500.00  + IVA<= /p>

    100% Di= rectorios Empresariales. Contamos con referencias comerciales. 

    No lo piense mas, solo por unos dias mas<= b>

    Para adquirirla

    Favor de responder al correo: bases.segmentadas.mexico@gmail.com

    NOTA IMPORTANTE: Solo se respetara el precio a las personas que envien sus d= atos y realicen el deposito  maximo el Viernes 18 de Octubre del 2019.

    PREGUNTAS FRECUENTE= S:

    =

    En que formato viene la base?

    R=3D Excel y Txt

    =

    Hasta que fecha estan actualizadas las bases?<= /span>

    R=3D A Octubre 2019

    =

    Envian bases muestra para su evaluacion?

    R=3D Si, solo es necesario nos indique a que= cuenta de correo se lo hacemos llegar.

    =

    Cuentan con referencias comerciales?

    R=3D Si, entre nuestros clientes se encuentr= an EMPRESAS IMPORTANTES en Mexico. <= /span>

    Cuentan con alguna garantia?

    R=3D Si, enviamos GARANTIA DE ENVIO Y EFECTI= VIDAD DEL DIRECTORIO.

    =

    Donde obtuvieron los datos?

    R=3D Somos una empresa que tambien imparte c= ursos y seminarios de cierre de ventas y servicio al cliente, continuamente= estamos presentes en eventos empresariales en donde ADQUIRIMOS NUEVAS BASE= S, asi como tambien intercambiamos bases con otras empresas.

    =

    En que tiempo me llega el Directorio una vez p= agado?

    R=3D Inmediatamente mediante un link de desc= arga para su PC.

     =

      

    FAVOR DE INDICAR EN ASUNTO SI DESEA SER REMOVIDO.=

     = ;

    Oferta valida para secdir@ietf.org.



    From nobody Wed Oct 16 08:06:21 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F63120074; Wed, 16 Oct 2019 08:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=XEZ5sZk8; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=pcgvqaj8 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 J2xkr2kZnveZ; Wed, 16 Oct 2019 08:06:14 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7785012002E; Wed, 16 Oct 2019 08:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6840; q=dns/txt; s=iport; t=1571238365; x=1572447965; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JzgZq/ItXyxQMIlmDR8vV8WdeKFR2R0nH1Sjt8ZAk6Y=; b=XEZ5sZk8Ef/WRrJ3aUD5UdnZRcHmwoPjLg8EZ+2re9Cg21Y8mihdS52O 9xhkZCyKvBRkk5xd1T06s7+VyyEunK3DNoDrY/GI+zd2xvCoF2QxYL5c3 MF+XYaGtEyh2jeXhvBiqpHRR/8alaezx9o2gA8fzsj62AEIfhGu/NaeUd U=; IronPort-PHdr: =?us-ascii?q?9a23=3ASzL0DhJygCABLyj3N9mcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFX4JfvyZiozNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B/AABnMadd/4QNJK1dCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAREBAQEBAQEBAQEBAYF7gUtQBWxXIAQLKgqHYgOKUIJcl36?= =?us-ascii?q?BQoEQA1QJAQEBDAEBGA0IAgEBhEACgnskOBMCAwkBAQQBAQECAQUEbYUtDIV?= =?us-ascii?q?LAQEBAQMBARAoBgEBKgIIAwELBAIBCBEEAQEfECcLHQgCBAENBQgagwGCRgM?= =?us-ascii?q?uAQIMoz0CgTiIYYIngn0BAQWBNAGDVhiCFwMGgTSKS4EmHRiBQD+BEUaCHi4?= =?us-ascii?q?+gmEBAYEuAQgKAQkEFIM+giyMaaBoCoIihwqOLII6h0+NWoFfjjCBP4ZlkRg?= =?us-ascii?q?CBAIEBQIOAQEFgWkiLDtxcBU7gmxQEBSBT4NzhRSFP3QKNWqNTw0XB4EEAYE?= =?us-ascii?q?iAQE?= X-IronPort-AV: E=Sophos;i="5.67,304,1566864000"; d="scan'208";a="351416068" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Oct 2019 15:06:04 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x9GF64Yi027823 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Oct 2019 15:06:04 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 16 Oct 2019 10:06:03 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 16 Oct 2019 10:06:02 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 16 Oct 2019 10:06:02 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AgqBhqTC6nQ9gpefnni4FxkxVZyJ1hkL5xtiJhBP048s67bBupGKwgpF2KOr8vY5lP6U7NnxcBrKJHHT7D7S4jqd2xJqqPqVW3gR4rU46Uk2Mbo5+0bPN7SR5FuiM6dpXZjV6VEercDNdHZpmhwIcc80rKOp7V7BZ68AZg2z2lItj3I3dCzRQtATAUzSRpfh/YlNpR32gD5lB4qYaUjFxPnYjh88BEuWAYM/0qk6hv2odUMgerUmX8OVJmC1nPimTUhiF/jCXK7MnUutON5h2qbPtqdgmk4Y1HXqF7SHKAKh3E2msB8hKDQzbofoeX+ftUPNi6cMSAB3C1bQmyJx8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OpSZITP6jvKb24mQXvrKbDZs3jL4A8+zp4q/Hlnj0us=; b=dmbyUws3eU7OVi0BkGvGhxeRN2SK+DlkezvbMN9ESwfVywglygT2c3jHqzC9IRyKGl2NsNavPDDPGKMBlv2ekIlwZPzooGPh0bIZxkNae/+nNig011BBzx752Zp6BG9Kc6+ATHPx6neTq1qjBMNX9V/t0zlzcWfWZLS4UTV834umndqLKWipYMz3QyuLHfhAlTqrKVRHJNJjRUlH2FibiYj5+EcYdjl3eUKcLNlWGcMjZjXpDmcMj7WVP/0wSqZN8t4FmR7TEOijTdF2mgW6V6TH7tWg6/uBlnj7JUrpWlznnp80bF/jY8gdjQXXCNNgO/XHxDGvheY0uw6cHSSiQA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OpSZITP6jvKb24mQXvrKbDZs3jL4A8+zp4q/Hlnj0us=; b=pcgvqaj8Ym6VE2hHYm+21y+k16SP0+z8eeXw1fPH+hcEj6NrjbJiAEbHxeDq0Es4SnxferUOZxjlMzAid9m0gUTw4hOnOyXiYViskPD3wlCOujSSj0hi7yclo9/GZKUdNdAzTEAi4Al5Ch4F3qr1vOYekwBNoNFUOwx75QTilAs= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2707.namprd11.prod.outlook.com (52.135.245.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.18; Wed, 16 Oct 2019 15:06:01 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5082:c814:2836:9e2a]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5082:c814:2836:9e2a%7]) with mapi id 15.20.2347.023; Wed, 16 Oct 2019 15:06:01 +0000 From: "Panos Kampanakis (pkampana)" To: Yaron Sheffer , "secdir@ietf.org" CC: "draft-ietf-ace-coap-est.all@ietf.org" , "ietf@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15 Thread-Index: AQHVgcaC5NivFu6vxkuLEqSa/tiqS6ddYSVA Date: Wed, 16 Oct 2019 15:06:01 +0000 Message-ID: References: <157097172245.20767.1326966836276837764@ietfa.amsl.com> In-Reply-To: <157097172245.20767.1326966836276837764@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [64.102.57.123] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 87a6c454-5671-4a52-f94e-08d7524a5bd5 x-ms-traffictypediagnostic: BN7PR11MB2707: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(4636009)(376002)(366004)(396003)(39860400002)(136003)(346002)(52084003)(13464003)(199004)(189003)(86362001)(76116006)(186003)(446003)(66446008)(66066001)(66946007)(11346002)(74316002)(71190400001)(71200400001)(66476007)(7736002)(8676002)(81166006)(8936002)(476003)(81156014)(486006)(102836004)(26005)(2906002)(33656002)(64756008)(66556008)(305945005)(54906003)(110136005)(99286004)(316002)(53546011)(76176011)(6116002)(3846002)(478600001)(14454004)(6506007)(256004)(7696005)(14444005)(5660300002)(2501003)(229853002)(9686003)(25786009)(6306002)(55016002)(52536014)(4326008)(6436002)(966005)(6246003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2707; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fQTyIKKry5j9v9V0ssNjC3iQxs8FT9/oIuwQXJbYLwQ9rHd8jmnAZq8E2K07mowzmuyj79A55ULRJSZrQjTJrS24rer6IqbpP/3c6EsKkq0j2kX0EC0SuB2H2nNb7Md6+X/9PiBZs/kccyqm0nTAef8Oin4Y3Y96c5r99USd2YAnN3y502nq9DyuVofgeV3Wfl4nkczk9oxHEKBOS7/rtKu/zl9vKe3plGFbk+IHhZ5hTX9PmPIHz5AWdTlPxzt026O57LzbvlaAZdIZyM61Evhtroj2jj3NR+d34WlrLhyMo2aK27d0RtrIu2SMKuMHSBpqZI4otB4pWmTKB0cDdFaydZebSRISMoTfXxVXxjYgKYBYETTSgFQmBCoLl5WaLz1qUORcFAogRMu9n6OfefSUKHp34XnRhEZs/ZzKk9AUMJ3M0swusUWNVqA3JgSJrX5De+lFXlEQEO3s/nSSuA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 87a6c454-5671-4a52-f94e-08d7524a5bd5 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2019 15:06:01.5832 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CaereYFx9fKola1c4biBt4CVHaZnvdhsNQM2b59WXAq8Peh5p+4KugvcJ4goh5pgpCIqdEi71wVMgIsVNXNQng== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2707 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [secdir] [Ace] Secdir last call review of draft-ietf-ace-coap-est-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 15:06:19 -0000 Hi Yaron, Thank you for the thorough review and feedback.=20 To make sure I don't miss any of your comments over an email thread, I trac= k all your feedback in git issue 152 https://github.com/SanKumar2015/EST-co= aps/issues/152 There I tried to address all your comments and question and = clarify some points.=20 I also pushed minor changes to fix a few of the issues you brought up. The = diff of the changes pushed is here https://github.com/SanKumar2015/EST-coap= s/commit/86d785f2122596f28674fe8e403d30467c98abfb=20 Please review the git issue and let us know if there are pending concerns. = Otherwise I am planning to reupload a new iteration next week.=20 Rgs,=20 Panos -----Original Message----- From: Ace On Behalf Of Yaron Sheffer via Datatracker Sent: Sunday, October 13, 2019 9:02 AM To: secdir@ietf.org Cc: draft-ietf-ace-coap-est.all@ietf.org; ietf@ietf.org; ace@ietf.org Subject: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15 Reviewer: Yaron Sheffer Review result: Has Issues This document defines a new profile for EST (simple certificate enrollment)= for restricted devices, to be run on top of CoAP and DTLS, instead of the = usual HTTP and TLS. Overall, I tend to be suspicious of "restricted" profiles, and this is a ca= se in point. An implementation of DTLS is no simpler than TLS and most woul= d probably support both protocols. And basically anything supports HTTP. So= why would it make sense to define a whole new profile just to avoid using = TCP very rarely (say, for daily certificate enrollment), when this profile = even needs to include its own fragmentation/buffering mechanisms because th= e ASN.1 payloads are too long? In other words, we are introducing new and a= dditional complexity with little or no performance gain. - 2. Only certificate-based client authentication is supported. Hopefully s= ome time soon we'll be able to use PAKE here, to bootstrap the PKI. - 4. "Crypto agility is important" - this statement is somewhat meaningless= : do we require more than one cipher suite, which would ensure some level o= f agility? - Also, when we say "Sec. 4.4 of RFC 7925" do we mean *only* Sec. 4.4 or al= so the subsections: 4.4.1 etc. - "in DTLS 1.3 the Supported Elliptic Curves extension has been renamed to = Supported Groups". This is probably true for an older version of the draft,= I couldn't find anything to support it in -32. - "the Finished message must be computed" - this whole paragraph is unclear= . Are we changing the Finished/MAC computation in DTLS (if so, this must be p= ointed out very clearly)? Or are we explaining a point about channel bindin= g (if we are, this doesn't come across). - Similarly for the following paragraph: is this a performance optimizatio= n, or a change to DTLS? And by the way, why are standard session resumption= mechanisms not used? - I don't see value in the short EST URI paths given that most of the "weig= ht" is in ASN.1 data, and the paths are negligible in comparison. Moreover, if = the paths are different, shouldn't this document formally UPDATE RFC 7030? = I think it is no longer a profile. - Non-default server port: the examples include an IPv6 address in addition= to the port number. Is there a way to use relative URIs (omitting the IP a= ddress) but include a port number? The server may not know its own IP addre= ss (IPv4 with NAT) or the address may be dynamic. - The server MUST support the default /.well-known/est root resource, but t= hen in the next sentence we discuss non-default URIs. In the case of the se= rver having multiple "identities" (the main purpose of the "arbitrary label", AF= AIU), the root resource is confusing - which identity is it associated with= ? And then how is discovery managed for each identity, and is there a way to = discover the identities? - There is nowhere in this document a full formal definition of content typ= e TBD287 (a single cert). - Content type negotiation: I can see how it works for enrollment. But in t= he case of /cacerts, if the server has a list of certs in its explicit TA s= tore (e.g. to support rollover), how can TBD287 (a single cert) make sense? - It is mighty confusing to denote "content format" by "ct" (presumably, th= is stands for "content type"). - "ASN.1 encoded in binary format" - I think this should be, "DER-encoded A= SN.1, in its native binary form". - Please don't use "he" and "she" for the server and the client. Both are m= erely "it". - "The Registrar MUST authenticate and optionally authorize the client requ= ests" - this statement is too weak. The Registrar must also ensure that cli= ents only send CSRs that pertain to their authenticated identity (channel b= inding), even when POP-linking is not used. I think this is worthy of its o= wn subsection, describing the validation required for each particular EST f= low. - The following paragraph is not clear: is PoP-linking useful/recommended/m= andated in this scenario? IMO there should be some 2119 word regarding serv= er-side validation of the tls-unique. - "Table 1 contains the URI mappings between EST-coaps and EST that the Reg= istrar MUST adhere to." But the immediately preceding paragraph describes a= case where a server-side generation on the EST-coaps side is mapped to cli= ent-side generation on the EST-HTTPS side, which is not a Table 1 mapping! - "the encrypted CMS EnvelopedData blob MUST be converted at the Registrar"= - can this be done without decrypting the blob, IOW must the Registrar be = privy to the key wrapping key? - The Registrar must support resource discovery: does it mean that resource= discovery messages are simply proxied upstream, or that the Registrar pres= ents a simpler resource structure (maybe with no discovery) to its clients = while performing discovery upstream? - Security Considerations: there's a long discussion about replacing the im= plicit TAs with explicit ones. If we (rightly) mandate that the client re-v= erify the server's cert after getting the /certs response, we are losing mo= st of the minor performance gain that keeping the DTLS connection open migh= t have given us. So why not unambiguously mandate the simpler "MUST close t= he connection after /certs" instead? Besides, /cacerts is a very rare opera= tion. Why optimise it at all? - "Improper CSR requests" - what are they? What's the server supposed to do= ? Please give a reference. - A.3, response: I may be missing something, but the binary blob "3081...9f= d9" does not parse as PKCS#8 to me. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Wed Oct 16 13:21:25 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA9A120122; Wed, 16 Oct 2019 13:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 Ht6VAtQPmpT3; Wed, 16 Oct 2019 13:21:05 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640130.outbound.protection.outlook.com [40.107.64.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 163DC12008B; Wed, 16 Oct 2019 13:21:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N/63RD9PCAwqUYdVNOptetaKpdwbuoxjGw/6W/JR6qsOFZboIo/++FcBIZXCZo4BmcTU5GgcIoysPdUUJjSE4ZWWeaU4kNfWDShgtXm1wNRicnGxLJaR8rTUGhP+QBDog9G+xV+UT5JL2NxGbaM44G6niW9a9053el9vQ4p0YNOqIeijhhE2pjL+IYTrtWHBHRKlOeloGnrQE4HsnxDGvEOMJgChuNY5nUSJmqOwqtalG9/VQZZ9Y1smJrt0LQz929QGxuwifPsT4HGfLviWCftM5r1xU5bRRodXkLoKmz4Q9YjIvV6ZLJ5qG3JHkafq+jIcAe6rt1T8AzJ0EuuN+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Fl1M/dG6eRogy5EUVDGHn2fro4NROIpc0VTWJ426QOg=; b=B8IjtI00GlyxxRpjI546sNVW2tjXw8UsWjWA0nXAB+H1B4T2gg5IpNNzyLs04rcfG4+4MInfJb+XnhDh+OM2rejjZZVkSL1NqGTzM6lml7SreuFySB4iNoRF/tFh/E/9UPVoSQDjduPW01vy1NUMJ3tWSDW7oYdlz2DSZylZfO6I67TcZGzJ9HVszJ3HNPFqn11FmTIM+reqaVHII7ogRo43m54+oIRROa+yQcpvGI/QXbZSklVgpwH60TEoUi51QQlXRT72rzhJDCli6c1g0Ob7YixuY3EYn1dA88yoUUJlshMoFUsc5CaT2l8raIkRKZxeysjhSi2vPnU+N5MCkQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Fl1M/dG6eRogy5EUVDGHn2fro4NROIpc0VTWJ426QOg=; b=gs8Sks0KFMfcD4OQeUsbuA9S1WdeEvU/u3kBnyovKeURIriFv/ccXnCuvtBtlMnZJ7uQ90PtfwJWhW6unv2nmlLiCYzc+w/eVEag9wbbiAYIJAqptQeN+QRpOp0oegMPY0PBLxitUI+lFXDaf5x295Y65s0lylvi+skcPUL6hVI= Received: from DM6PR00MB0569.namprd00.prod.outlook.com (20.179.51.12) by DM6PR00MB0459.namprd00.prod.outlook.com (20.178.29.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2403.0; Wed, 16 Oct 2019 20:21:03 +0000 Received: from DM6PR00MB0569.namprd00.prod.outlook.com ([fe80::9196:77fa:83c0:9418]) by DM6PR00MB0569.namprd00.prod.outlook.com ([fe80::9196:77fa:83c0:9418%7]) with mapi id 15.20.2405.000; Wed, 16 Oct 2019 20:21:03 +0000 From: Mike Jones To: Yoav Nir , "secdir@ietf.org" CC: "draft-ietf-ace-cwt-proof-of-possession.all@ietf.org" , "ietf@ietf.org" , "ace@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-ace-cwt-proof-of-possession-08 Thread-Index: AQHVfHcUHTxGfXrAZEKn6Qqm5R9W5adduhGQ Date: Wed, 16 Oct 2019 20:21:03 +0000 Message-ID: References: <157038789080.6563.18028321376777169887@ietfa.amsl.com> In-Reply-To: <157038789080.6563.18028321376777169887@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=5f10aac0-f5c3-403a-912c-000003962139; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-10-16T19:40:01Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:f:98d9:5a0a:3425:3ebe] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7276c913-113a-4919-4045-08d752765e02 x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: DM6PR00MB0459: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(396003)(376002)(366004)(346002)(39860400002)(189003)(199004)(13464003)(2501003)(14444005)(52536014)(76116006)(66574012)(54896002)(8990500004)(66946007)(66476007)(66556008)(64756008)(66446008)(4326008)(10090500001)(9686003)(71190400001)(6436002)(71200400001)(55016002)(6306002)(256004)(316002)(10290500003)(2906002)(33656002)(486006)(7736002)(186003)(478600001)(99286004)(110136005)(46003)(81166006)(76176011)(446003)(6506007)(74316002)(54906003)(53546011)(81156014)(790700001)(7696005)(25786009)(6246003)(8936002)(476003)(22452003)(6116002)(14454004)(102836004)(8676002)(229853002)(5660300002)(11346002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0459; H:DM6PR00MB0569.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ULlkuBz3t+fk0O9QfDrTA/BblOv+A3zrvDDn22nRo5k/XpKuLh0lY7aj7DTjCi2aQo22hsCrSCiR0bk3HQvx5z79JT0v5Av48P/5sTwcfUizdYFTQMuhqoUiOB9TrdNOI+mjEvphMLSXoBCHgD+0fkD8kUxdW4jzLm4QHKtOC91FCkk0kNrBBJvcuXs9m6qfayP96AbypIIfdAppXj3wHz1i6TUREuNyZgMuh0Hkvnaq5r8Px9vg3Nvm3RaWjLj03OUV94rj5OxqsUgo5uUUoK4NCX/NXnBJFgtaNOnP93k0SfSPpxqNH2FCP8fqoWITzgmMPG6pMjZBJWkmJI3qaj+sZbRozFYNGkiUmeKdMOgSOZ/34mOzVPSwjN4gRvNnGknP4JnIm0XPaISvjEO/tYKRDZTuiy01hzeOESJ/uEQ= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB05695230578007608306AFBCF5920DM6PR00MB0569namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7276c913-113a-4919-4045-08d752765e02 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2019 20:21:03.2119 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZpkapY9CfMi2RapJOpZZ71eRrxCrQu/yES9IutBz6cSZEnixdlqvqZVAPXGI0jGx/lFjnTFaA2P6GXGp5aJWLA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0459 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ace-cwt-proof-of-possession-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 20:21:09 -0000 --_000_DM6PR00MB05695230578007608306AFBCF5920DM6PR00MB0569namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGEgbG90IGZvciB5b3VyIHJldmlldywgWW9hdi4gIFJlcGxpZXMgYXJlIGlubGluZSwg cHJlZml4ZWQgYnkg4oCcTWlrZT7igJ3igKYNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBZb2F2IE5pciB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+DQpT ZW50OiBTdW5kYXksIE9jdG9iZXIgNiwgMjAxOSAxMTo1MiBBTQ0KVG86IHNlY2RpckBpZXRmLm9y Zw0KQ2M6IGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLmFsbEBpZXRmLm9y ZzsgaWV0ZkBpZXRmLm9yZzsgYWNlQGlldGYub3JnDQpTdWJqZWN0OiBTZWNkaXIgbGFzdCBjYWxs IHJldmlldyBvZiBkcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wOA0KDQoN Cg0KUmV2aWV3ZXI6IFlvYXYgTmlyDQoNClJldmlldyByZXN1bHQ6IEhhcyBOaXRzDQoNCg0KDQpJ IGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJl Y3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVp bmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiAgVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHBy aW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLg0K DQpEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1l bnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQoNCg0KSSB0aGlu ayB0aGUgZG9jdW1lbnQgc2hvd3MgdGhhdCBzZWN1cml0eSBhc3BlY3RzIGhhdmUgYmVlbiBjb25z aWRlcmVkIGFuZCBoYW5kbGVkIHdlbGwuIEhvd2V2ZXIsIHRoZSBkb2N1bWVudCBoYXMgaXNzdWVz IHdpdGggY2xhcml0eSBhbmQgcmVhZGFiaWxpdHk6DQoNCg0KDQpGb3Igc3RhcnRlcnMsIHRoZSBB YnN0cmFjdCBhbmQgSW50cm9kdWN0aW9uIGFyZSBuZWFybHkgaWRlbnRpY2FsLiBUaGUgSW50cm9k dWN0aW9uIGNvdWxkIGluc3RlYWQgYmUgdXNlZCB0byBleHBsYWluIHRoZSBkb21haW4sIHdobyB0 aGUgInBsYXllcnMiIGFyZSBhbmQgd2hhdCB0aGV5IGFyZSB0cnlpbmcgdG8gYWNjb21wbGlzaC4g SW5zdGVhZCwgc2VjdGlvbiAyIGludHJvZHVjZXMgdGhlIHRlcm1zIElzc3VlciwgUHJlc2VudGVy IGFuZCBSZWNpcGllbnQgd2l0aCBkZWZpbml0aW9ucyB0aGF0IHNvdW5kIGxpa2UgdGhlIENBLCB0 aGUgRW5kIEVudGl0eSBhbmQgdGhlIFJlbHlpbmcgUGFydHkgZnJvbSBQS0ksIHdpdGggYSBsaXR0 bGUgT0F1dGggdGVybWlub2xvZ3kgbWl4ZWQgaW4uIFRoZXJlIGlzIG5vIGV4cGxhbmF0aW9uIGFi b3V0IHdobyB0aGlzIGlzc3VlciBpcywgYW5kIHdoYXQgdGhlIHRydXN0IG1vZGVsIGlzLg0KDQoN Cg0KTWlrZT4gVGhpcyBkb2N1bWVudCBzdHJ1Y3R1cmUgaXMgaW50ZW50aW9uYWxseSBwYXJhbGxl bCB0byBSRkMgNzgwMC4gIEluIHBhcnRpY3VsYXIsIHRoZSBUZXJtaW5vbG9neSBzZWN0aW9uIGlz IHRoZXJlIHNwZWNpZmljYWxseSB0byBpbnRyb2R1Y2UgdGhlIHBsYXllcnMuICBZZXMsIGVkaXRv cmlhbGx5LCB0aGlzIGNvdWxkIGhhdmUgYmVlbiBkb25lIGluIHRoZSBJbnRyb2R1Y3Rpb24sIGJ1 dCB0aGlzIGlzIHRoZSBzdHlsZSB0eXBpY2FsbHkgdXNlZCBieSBPQXV0aCwgSk9TRSwgQ09TRSwg YW5kIEFDRSBzcGVjaWZpY2F0aW9ucy4gIEnigJltIHJlbHVjdGFudCB0byBkZXZpYXRlIGZyb20g aXQgaW4gdGhpcyBwYXJ0aWN1bGFyIHNwZWNpZmljYXRpb24gdW5sZXNzIHRoZXJl4oCZcyBhIGNv bXBlbGxpbmcgcmVhc29uIHRvIGRvIHNvLg0KDQoNCg0KTWlrZT4gV2hvIHRoZSBpc3N1ZXIgaXMg aXMgZGlzY3Vzc2VkIGluIHRoZSBsYXN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDMuICBUaGUgdHJ1 c3QgbW9kZWwgaXMgZGVzY3JpYmVkIGluIHRoZSBsYXN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDQg KFNlY3VyaXR5IENvbnNpZGVyYXRpb25zKS4NCg0KDQoNCk1pa2U+IFRoZXJlZm9yZSwgdW5sZXNz IHRoZXJlIGlzIGEgc3BlY2lmaWMgY2hhbmdlIHRoYXQgeW91IHdhbnQgdG8gc3VnZ2VzdCwgSSBw cm9wb3NlIHRvIGxlYXZlIHRoZSBJbnRyb2R1Y3Rpb24gYW5kIFRlcm1pbm9sb2d5IHNlY3Rpb25z IGFzIGlzLg0KDQoNCg0KVGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gYWxzbyBo YXMgc29tZSBwcm9ibGVtcy4gIFF1b3RpbmcgdGhlIHNlY29uZA0KDQpwYXJhZ3JhcGg6DQoNCiAg IEFwcGxpY2F0aW9ucyB1dGlsaXppbmcgcHJvb2Ygb2YgcG9zc2Vzc2lvbiBTSE9VTEQgYWxzbyB1 dGlsaXplDQoNCiAgIGF1ZGllbmNlIHJlc3RyaWN0aW9uLCBhcyBkZXNjcmliZWQgaW4gU2VjdGlv biAzLjEuMyBvZiBbQ1dUXSwgYXMgaXQNCg0KICAgcHJvdmlkZXMgYWRkaXRpb25hbCBwcm90ZWN0 aW9ucy4gIEF1ZGllbmNlIHJlc3RyaWN0aW9uIGNhbiBiZSB1c2VkIGJ5DQoNCiAgIHJlY2lwaWVu dHMgdG8gcmVqZWN0IG1lc3NhZ2VzIGludGVuZGVkIGZvciBkaWZmZXJlbnQgcmVjaXBpZW50cy4N Cg0KDQoNCldoeT8gV2h5IGlzIHRoZSBhdWQgY2xhaW0gbmVlZGVkIHdpdGggYSBjbmYgY2xhaW0g KGJ1dCBub3QgaW4gb3RoZXIgY2FzZXMpPw0KDQpOZWl0aGVyIHRoaXMgZG9jdW1lbnQgbm9yIFJG QyA4MzkyIHByb3ZpZGVzIGluc2lnaHQgYXMgdG8gd2hlbiBhdWQgaXMgYXBwcm9wcmlhdGUuIFRo YXQgdGhleSBhbGxvdyByZWNpcGllbnRzIHRvIHJlamVjdCBtZXNzYWdlcyBub3QgaW50ZW5kZWQg Zm9yIHRoZW0gZG9lcyBub3Qgc291bmQgbGlrZSBhIHNlY3VyaXR5IGZlYXR1cmUuDQoNCg0KDQpN aWtlPiBIYXZpbmcgYW4gYXVkaWVuY2UgaW4gYSB0b2tlbiBpcyBhIHNlY3VyaXR5IGZlYXR1cmUs IGFzIGl0IHByZXZlbnRzIGEgbGVnaXRpbWF0ZSB0b2tlbiBpbnRlbmRlZCBmb3Igb25lIHJlY2lw aWVudCBmcm9tIGJlaW5nIHJlcGxheWVkIHRvIGdhaW4gYWNjZXNzIGF0IGEgZGlmZmVyZW50IHJl Y2lwaWVudC4gIFlvdeKAmXJlIHJpZ2h0IHRoYXQgdGhpcyBpcyB1c2VmdWwvcmVxdWlyZWQgaW4g bWFueSBzaXR1YXRpb25zIGV2ZW4gd2hlbiDigJxjbmbigJ0gaXNu4oCZdCBiZWluZyB1c2VkLiAg SG93ZXZlciwgcmV2aWV3ZXJzIG9mIGRyYWZ0cyBvZiB3aGF0IGJlY2FtZSBSRkMgNzgwMCB3YW50 ZWQgdGhpcyB0ZXh0IGFkZGVkIHRvIHJlbWluZCBwZW9wbGUgdGhhdCBhdWRpZW5jZSByZXN0cmlj dGlvbiBpcyBvZnRlbiB1c2VmdWwgZXZlbiB3aGVuIHlvdSBoYXZlIHByb29mIG9mIHBvc3Nlc3Np b24sIGFzIGl0IGRlZmVuZHMgYWdhaW5zdCBkaWZmZXJlbnQgdGhyZWF0cy4NCg0KDQoNCk1pa2U+ IFRvIG1ha2UgdGhpcyBjbGVhcmVyLCBJIHByb3Bvc2UgdG8gYWRkIHRoaXMgcGFyZW50aGV0aWNh bCByZW1hcmsgYXQgdGhlIGVuZCBvZiB0aGlzIHBhcmFncmFwaDog4oCcKE9mIGNvdXJzZSwgYXBw bGljYXRpb25zIG5vdCB1c2luZyBwcm9vZiBvZiBwb3NzZXNzaW9uIGNhbiBhbHNvIGJlbmVmaXQg ZnJvbSB1c2luZyBhdWRpZW5jZSByZXN0cmljdGlvbiB0byByZWplY3QgbWVzc2FnZXMgaW50ZW5k ZWQgZm9yIGRpZmZlcmVudCByZWNpcGllbnRzLinigJ0gIElmIHlvdeKAmWQgcHJlZmVyIGRpZmZl cmVudCB3b3JkaW5nLCBwbGVhc2UgbGV0IG1lIGtub3cgd2hhdCBpdCBpcy4NCg0KDQoNClBhcmFn cmFwaCAzIHNheXM6ICJBIHJlY2lwaWVudCBtaWdodCBub3QgdW5kZXJzdGFuZCB0aGUgImNuZiIg Y2xhaW0uIiAgIFRoaXMNCg0KcmUtYWZmaXJtcyB0aGF0IHdlIG5lZWQgYW4gZXhwbGFuYXRpb24g b2Ygd2hvIHRoZSBwYXJ0aWVzIHRvIHRoaXMgcHJvdG9jb2wgYXJlLg0KDQpXZSBnZW5lcmFsbHkg ZG9uJ3Qgc2VuZCBtZXNzYWdlcyB0byByZWNpcGllbnRzIHRoYXQgZG9uJ3QgdW5kZXJzdGFuZCB0 aGVtLiBJcyB0aGlzIGEgY2xvc2VkIHN5c3RlbSB3aXRoIGtub3duIGVudGl0aWVzLCBvciBpcyB0 aGlzIGEgcHJvdG9jb2wgd2hlcmUgdGhlIHBhcnRpZXMgY29udGFjdCByYW5kb20gb3RoZXIgcGFy dGllcyBvbiB0aGUgSW50ZXJuZXQ/DQoNCg0KDQpNaWtlPiBQZXIgbXkgcmVzcG9uc2UgdG8gdGhl IEdlbmFydCByZXZpZXcsIHdl4oCZcmUgYWxyZWFkeSBwcm9wb3NpbmcgdG8gZGVsZXRlIHRoaXMg cGFyYWdyYXBoLCBhcyBpdOKAmXMgbm90IGFjdGlvbmFibGUuICBOb3RlIHRoYXQgdGhlIHJlcXVp cmVtZW50IHRvIGlnbm9yZSBub3QtdW5kZXJzdG9vZCBjbGFpbXMgY29tZXMgZnJvbSBTZWN0aW9u IDMgb2YgUkZDIDgzOTIgKHdoaWNoIGFsc28gd2FzIGluaGVyaXRlZCBmcm9tIFJGQyA3NTE5KSwg YW5kIHNvIGlzIG5vdCB1bmlxdWUgdG8gdGhpcyBzcGVjaWZpY2F0aW9uLg0KDQoNCg0KTWlrZT4g VGhlIGV4YWN0IHBhcnRpZXMgdG8gdGhlIHByb3RvY29sIGFyZSBkZXBlbmRlbnQgdXBvbiB0aGUg YXBwbGljYXRpb24sIGFzIGRpc2N1c3NlZCBpbiB0aGUgbGFzdCBwYXJhZ3JhcGggb2YgU2VjdGlv biA0LiAgVGhpcyBzcGVjaWZpY2F0aW9uIGlzIGRlZmluaW5nIFBvUCBrZXkgcmVwcmVzZW50YXRp b25zLiAgSXTigJlzIGludGVudGlvbmFsbHkgbGVhdmluZyB0aGUgbWVzc2FnZXMgY29udmV5aW5n IENXVHMgd2l0aCDigJxjbmbigJ0gY2xhaW1zIHVwIHRvIHRoZSBhcHBsaWNhdGlvbnMgdXNpbmcg dGhlbS4gIEFnYWluLCB0aGlzIGlzIGludGVudGlvbmFsbHkgZXhhY3RseSBwYXJhbGxlbCB0byBS RkMgNzgwMC4NCg0KDQoNCkknZCBhbHNvIGxvc2Ugc29tZSBvZiB0aGUgSW50cm9kdWN0aW9uIHRv IENyeXB0byBpbiB0aGUgc2Vjb25kLXRvLWxhc3QgcGFyYWdyYXBoLg0KDQoNCg0KTWlrZT4gSSBh Z3JlZSB0aGF0IHRoaXMgaXMgb3Zlcmx5IHBlZGFudGljLiAgSSBwcm9wb3NlIHRvIGRlbGV0ZSB0 aGUgcGFyZW50aGV0aWNhbCDigJxlLmcu4oCdIGNsYXVzZSBhdCB0aGUgZW5kLCB3aGljaCB3aWxs IG1ha2UgaXQgb25jZSBhZ2FpbiBleGFjdGx5IHBhcmFsbGVsIHRvIHRoZSBjb3JyZXNwb25kaW5n IHRleHQgaW4gUkZDIDc4MDAuICBMZXQgbWUga25vdyBpZiB5b3XigJlkIGEgc3BlY2lmaWMgZnVy dGhlciBjaGFuZ2UgdG8gdGhpcyBwYXJhZ3JhcGguDQoNCg0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhhbmtzLA0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgLS0gTWlrZQ0KDQoNCg== --_000_DM6PR00MB05695230578007608306AFBCF5920DM6PR00MB0569namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi UGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGFua3Mg YSBsb3QgZm9yIHlvdXIgcmV2aWV3LCBZb2F2LiZuYnNwOyBSZXBsaWVzIGFyZSBpbmxpbmUsIHBy ZWZpeGVkIGJ5IOKAnDxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5NaWtlJmd0Ozwvc3Bhbj7i gJ3igKY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08YnI+DQpGcm9tOiBZb2F2IE5pciB2aWEgRGF0YXRyYWNrZXIgJmx0O25vcmVwbHlAaWV0 Zi5vcmcmZ3Q7IDxicj4NClNlbnQ6IFN1bmRheSwgT2N0b2JlciA2LCAyMDE5IDExOjUyIEFNPGJy Pg0KVG86IHNlY2RpckBpZXRmLm9yZzxicj4NCkNjOiBkcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Yt b2YtcG9zc2Vzc2lvbi5hbGxAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7IGFjZUBpZXRmLm9yZzxi cj4NClN1YmplY3Q6IFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtYWNlLWN3 dC1wcm9vZi1vZi1wb3NzZXNzaW9uLTA4PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlJl dmlld2VyOiBZb2F2IE5pcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ UmV2aWV3IHJlc3VsdDogSGFzIE5pdHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSBo YXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0 b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5n IHByb2Nlc3NlZCBieSB0aGUgSUVTRy4mbmJzcDsgVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVu IHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3Jz LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RG9jdW1lbnQgZWRpdG9y cyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55 IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ SSB0aGluayB0aGUgZG9jdW1lbnQgc2hvd3MgdGhhdCBzZWN1cml0eSBhc3BlY3RzIGhhdmUgYmVl biBjb25zaWRlcmVkIGFuZCBoYW5kbGVkIHdlbGwuIEhvd2V2ZXIsIHRoZSBkb2N1bWVudCBoYXMg aXNzdWVzIHdpdGggY2xhcml0eSBhbmQgcmVhZGFiaWxpdHk6PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPkZvciBzdGFydGVycywgdGhlIEFic3RyYWN0IGFuZCBJbnRyb2R1Y3Rpb24gYXJl IG5lYXJseSBpZGVudGljYWwuIFRoZSBJbnRyb2R1Y3Rpb24gY291bGQgaW5zdGVhZCBiZSB1c2Vk IHRvIGV4cGxhaW4gdGhlIGRvbWFpbiwgd2hvIHRoZSAmcXVvdDtwbGF5ZXJzJnF1b3Q7IGFyZSBh bmQgd2hhdCB0aGV5IGFyZSB0cnlpbmcgdG8gYWNjb21wbGlzaC4gSW5zdGVhZCwgc2VjdGlvbiAy IGludHJvZHVjZXMgdGhlIHRlcm1zIElzc3VlciwNCiBQcmVzZW50ZXIgYW5kIFJlY2lwaWVudCB3 aXRoIGRlZmluaXRpb25zIHRoYXQgc291bmQgbGlrZSB0aGUgQ0EsIHRoZSBFbmQgRW50aXR5IGFu ZCB0aGUgUmVseWluZyBQYXJ0eSBmcm9tIFBLSSwgd2l0aCBhIGxpdHRsZSBPQXV0aCB0ZXJtaW5v bG9neSBtaXhlZCBpbi4gVGhlcmUgaXMgbm8gZXhwbGFuYXRpb24gYWJvdXQgd2hvIHRoaXMgaXNz dWVyIGlzLCBhbmQgd2hhdCB0aGUgdHJ1c3QgbW9kZWwgaXMuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5NaWtlJmd0OyBUaGlzIGRvY3Vt ZW50IHN0cnVjdHVyZSBpcyBpbnRlbnRpb25hbGx5IHBhcmFsbGVsIHRvIFJGQyA3ODAwLiZuYnNw OyBJbiBwYXJ0aWN1bGFyLCB0aGUgVGVybWlub2xvZ3kgc2VjdGlvbiBpcyB0aGVyZSBzcGVjaWZp Y2FsbHkgdG8gaW50cm9kdWNlIHRoZSBwbGF5ZXJzLiZuYnNwOyBZZXMsIGVkaXRvcmlhbGx5LCB0 aGlzIGNvdWxkIGhhdmUgYmVlbiBkb25lIGluDQogdGhlIEludHJvZHVjdGlvbiwgYnV0IHRoaXMg aXMgdGhlIHN0eWxlIHR5cGljYWxseSB1c2VkIGJ5IE9BdXRoLCBKT1NFLCBDT1NFLCBhbmQgQUNF IHNwZWNpZmljYXRpb25zLiZuYnNwOyBJ4oCZbSByZWx1Y3RhbnQgdG8gZGV2aWF0ZSBmcm9tIGl0 IGluIHRoaXMgcGFydGljdWxhciBzcGVjaWZpY2F0aW9uIHVubGVzcyB0aGVyZeKAmXMgYSBjb21w ZWxsaW5nIHJlYXNvbiB0byBkbyBzby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMEIwNTAiPk1pa2UmZ3Q7IFdobyB0aGUgaXNzdWVyIGlzIGlzIGRpc2N1c3NlZCBpbiB0aGUg bGFzdCBwYXJhZ3JhcGggb2YgU2VjdGlvbiAzLiZuYnNwOyBUaGUgdHJ1c3QgbW9kZWwgaXMgZGVz Y3JpYmVkIGluIHRoZSBsYXN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDQgKFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPk1p a2UmZ3Q7IFRoZXJlZm9yZSwgdW5sZXNzIHRoZXJlIGlzIGEgc3BlY2lmaWMgY2hhbmdlIHRoYXQg eW91IHdhbnQgdG8gc3VnZ2VzdCwgSSBwcm9wb3NlIHRvIGxlYXZlIHRoZSBJbnRyb2R1Y3Rpb24g YW5kIFRlcm1pbm9sb2d5IHNlY3Rpb25zIGFzIGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gYWxzbyBoYXMgc29tZSBwcm9ibGVtcy4mbmJzcDsgUXVv dGluZyB0aGUgc2Vjb25kPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5w YXJhZ3JhcGg6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsgQXBwbGljYXRpb25zIHV0aWxpemluZyBwcm9vZiBvZiBwb3NzZXNzaW9uIFNIT1VMRCBh bHNvIHV0aWxpemU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyBhdWRpZW5jZSByZXN0cmljdGlvbiwgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4x LjMgb2YgW0NXVF0sIGFzIGl0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsgcHJvdmlkZXMgYWRkaXRpb25hbCBwcm90ZWN0aW9ucy4mbmJzcDsgQXVk aWVuY2UgcmVzdHJpY3Rpb24gY2FuIGJlIHVzZWQgYnk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyAmbmJzcDtyZWNpcGllbnRzIHRvIHJlamVjdCBtZXNzYWdl cyBpbnRlbmRlZCBmb3IgZGlmZmVyZW50IHJlY2lwaWVudHMuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPldoeT8gV2h5IGlzIHRoZSBhdWQgY2xhaW0gbmVlZGVkIHdpdGggYSBjbmYgY2xh aW0gKGJ1dCBub3QgaW4gb3RoZXIgY2FzZXMpPw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5OZWl0aGVyIHRoaXMgZG9jdW1lbnQgbm9yIFJGQyA4MzkyIHByb3ZpZGVz IGluc2lnaHQgYXMgdG8gd2hlbiBhdWQgaXMgYXBwcm9wcmlhdGUuIFRoYXQgdGhleSBhbGxvdyBy ZWNpcGllbnRzIHRvIHJlamVjdCBtZXNzYWdlcyBub3QgaW50ZW5kZWQgZm9yIHRoZW0gZG9lcyBu b3Qgc291bmQgbGlrZSBhIHNlY3VyaXR5IGZlYXR1cmUuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5NaWtlJmd0OyBIYXZpbmcgYW4gYXVk aWVuY2UgaW4gYSB0b2tlbiBpcyBhIHNlY3VyaXR5IGZlYXR1cmUsIGFzIGl0IHByZXZlbnRzIGEg bGVnaXRpbWF0ZSB0b2tlbiBpbnRlbmRlZCBmb3Igb25lIHJlY2lwaWVudCBmcm9tIGJlaW5nIHJl cGxheWVkIHRvIGdhaW4gYWNjZXNzIGF0IGEgZGlmZmVyZW50IHJlY2lwaWVudC4mbmJzcDsgWW91 4oCZcmUgcmlnaHQgdGhhdCB0aGlzDQogaXMgdXNlZnVsL3JlcXVpcmVkIGluIG1hbnkgc2l0dWF0 aW9ucyBldmVuIHdoZW4g4oCcY25m4oCdIGlzbuKAmXQgYmVpbmcgdXNlZC4mbmJzcDsgSG93ZXZl ciwgcmV2aWV3ZXJzIG9mIGRyYWZ0cyBvZiB3aGF0IGJlY2FtZSBSRkMgNzgwMCB3YW50ZWQgdGhp cyB0ZXh0IGFkZGVkIHRvIHJlbWluZCBwZW9wbGUgdGhhdCBhdWRpZW5jZSByZXN0cmljdGlvbiBp cyBvZnRlbiB1c2VmdWwgZXZlbiB3aGVuIHlvdSBoYXZlIHByb29mIG9mIHBvc3Nlc3Npb24sIGFz IGl0IGRlZmVuZHMNCiBhZ2FpbnN0IGRpZmZlcmVudCB0aHJlYXRzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUw Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+TWlrZSZndDsgVG8gbWFrZSB0aGlzIGNsZWFyZXIs IEkgcHJvcG9zZSB0byBhZGQgdGhpcyBwYXJlbnRoZXRpY2FsIHJlbWFyayBhdCB0aGUgZW5kIG9m IHRoaXMgcGFyYWdyYXBoOiDigJwoT2YgY291cnNlLCBhcHBsaWNhdGlvbnMgbm90IHVzaW5nIHBy b29mIG9mIHBvc3Nlc3Npb24gY2FuIGFsc28gYmVuZWZpdCBmcm9tIHVzaW5nIGF1ZGllbmNlIHJl c3RyaWN0aW9uDQogdG8gcmVqZWN0IG1lc3NhZ2VzIGludGVuZGVkIGZvciBkaWZmZXJlbnQgcmVj aXBpZW50cy4p4oCdJm5ic3A7IElmIHlvdeKAmWQgcHJlZmVyIGRpZmZlcmVudCB3b3JkaW5nLCBw bGVhc2UgbGV0IG1lIGtub3cgd2hhdCBpdCBpcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPlBhcmFncmFwaCAzIHNheXM6ICZxdW90O0EgcmVjaXBpZW50IG1pZ2h0IG5vdCB1 bmRlcnN0YW5kIHRoZSAmcXVvdDtjbmYmcXVvdDsgY2xhaW0uJnF1b3Q7Jm5ic3A7Jm5ic3A7IFRo aXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnJlLWFmZmlybXMgdGhh dCB3ZSBuZWVkIGFuIGV4cGxhbmF0aW9uIG9mIHdobyB0aGUgcGFydGllcyB0byB0aGlzIHByb3Rv Y29sIGFyZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPldlIGdlbmVy YWxseSBkb24ndCBzZW5kIG1lc3NhZ2VzIHRvIHJlY2lwaWVudHMgdGhhdCBkb24ndCB1bmRlcnN0 YW5kIHRoZW0uIElzIHRoaXMgYSBjbG9zZWQgc3lzdGVtIHdpdGgga25vd24gZW50aXRpZXMsIG9y IGlzIHRoaXMgYSBwcm90b2NvbCB3aGVyZSB0aGUgcGFydGllcyBjb250YWN0IHJhbmRvbSBvdGhl ciBwYXJ0aWVzIG9uIHRoZSBJbnRlcm5ldD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAw QjA1MCI+TWlrZSZndDsgUGVyIG15IHJlc3BvbnNlIHRvIHRoZSBHZW5hcnQgcmV2aWV3LCB3ZeKA mXJlIGFscmVhZHkgcHJvcG9zaW5nIHRvIGRlbGV0ZSB0aGlzIHBhcmFncmFwaCwgYXMgaXTigJlz IG5vdCBhY3Rpb25hYmxlLiZuYnNwOyBOb3RlIHRoYXQgdGhlIHJlcXVpcmVtZW50IHRvIGlnbm9y ZSBub3QtdW5kZXJzdG9vZCBjbGFpbXMgY29tZXMgZnJvbSBTZWN0aW9uIDMgb2YgUkZDDQogODM5 MiAod2hpY2ggYWxzbyB3YXMgaW5oZXJpdGVkIGZyb20gUkZDIDc1MTkpLCBhbmQgc28gaXMgbm90 IHVuaXF1ZSB0byB0aGlzIHNwZWNpZmljYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDBCMDUwIj5NaWtlJmd0OyBUaGUgZXhhY3QgcGFydGllcyB0byB0aGUgcHJvdG9j b2wgYXJlIGRlcGVuZGVudCB1cG9uIHRoZSBhcHBsaWNhdGlvbiwgYXMgZGlzY3Vzc2VkIGluIHRo ZSBsYXN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDQuJm5ic3A7IFRoaXMgc3BlY2lmaWNhdGlvbiBp cyBkZWZpbmluZyBQb1Aga2V5IHJlcHJlc2VudGF0aW9ucy4mbmJzcDsgSXTigJlzIGludGVudGlv bmFsbHkgbGVhdmluZw0KIHRoZSBtZXNzYWdlcyBjb252ZXlpbmcgQ1dUcyB3aXRoIOKAnGNuZuKA nSBjbGFpbXMgdXAgdG8gdGhlIGFwcGxpY2F0aW9ucyB1c2luZyB0aGVtLiZuYnNwOyBBZ2Fpbiwg dGhpcyBpcyBpbnRlbnRpb25hbGx5IGV4YWN0bHkgcGFyYWxsZWwgdG8gUkZDIDc4MDAuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JJ2QgYWxzbyBsb3NlIHNvbWUgb2YgdGhl IEludHJvZHVjdGlvbiB0byBDcnlwdG8gaW4gdGhlIHNlY29uZC10by1sYXN0IHBhcmFncmFwaC48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAi Pk1pa2UmZ3Q7IEkgYWdyZWUgdGhhdCB0aGlzIGlzIG92ZXJseSBwZWRhbnRpYy4mbmJzcDsgSSBw cm9wb3NlIHRvIGRlbGV0ZSB0aGUgcGFyZW50aGV0aWNhbCDigJxlLmcu4oCdIGNsYXVzZSBhdCB0 aGUgZW5kLCB3aGljaCB3aWxsIG1ha2UgaXQgb25jZSBhZ2FpbiBleGFjdGx5IHBhcmFsbGVsIHRv IHRoZSBjb3JyZXNwb25kaW5nIHRleHQgaW4gUkZDIDc4MDAuJm5ic3A7IExldCBtZSBrbm93DQog aWYgeW914oCZZCBhIHNwZWNpZmljIGZ1cnRoZXIgY2hhbmdlIHRvIHRoaXMgcGFyYWdyYXBoLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDBCMDUwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM6PR00MB05695230578007608306AFBCF5920DM6PR00MB0569namp_-- From nobody Thu Oct 17 07:06:06 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637CC12000F; Thu, 17 Oct 2019 07:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdKUbGxpqP2N; Thu, 17 Oct 2019 07:05:49 -0700 (PDT) Received: from mail-vs1-f51.google.com (mail-vs1-f51.google.com [209.85.217.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E39912085D; Thu, 17 Oct 2019 07:05:49 -0700 (PDT) Received: by mail-vs1-f51.google.com with SMTP id s7so1687577vsl.2; Thu, 17 Oct 2019 07:05:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g11VaHSLtwameCqeh/OkrPNBrWXROSLu5JJQ1/Efp1M=; b=Vupo/LpBE6ptRxmpLDo0dENdUG8QXL4r+70h5kn9qeDJ4bWUd95m2ORjJhNOvGHUFB 0C56FKPUM3TxfxK1yRqH2AF7GFdZVGjVibSGjal9Zd7dDwzmll3CPOsvv3iwRVezQsrP 3s1xY9XdGgcD+nygK1WUKKwZEcK/WkJSVWFJ3amnWh0yN3wc45jI4orLkTrbn7eXH5/v yJlI41rsA3NKnkMaKWGlPz+BqRHAqdRReDiw4Ov1tkm3MpRqcSMYQ105um/J1uNS24K+ pQ/OfwIn9z56HwfCnzIZMV3k3/WiqV16OWVqobrtA5VNuJMxtnfreUTdnZKXSw3+mLjV Mfpg== X-Gm-Message-State: APjAAAVB/9WFG0DYgFmRPYq+YWttI07u52XRVFDVAwMUVVz3qbPnSqRO qoyT6gGVm/wF25CiuU/bftOpBP3w3ZkD7LZrMzs= X-Google-Smtp-Source: APXvYqxe0Mw0u6762rbw9RO2gsWKGw6isuMx/qdh2dFOMLIYfTYNQc30lk370W9RntHYzCt41vC7Ijw/MvhABhNbuoI= X-Received: by 2002:a05:6102:21ce:: with SMTP id r14mr2110030vsg.69.1571321148293; Thu, 17 Oct 2019 07:05:48 -0700 (PDT) MIME-Version: 1.0 References: <157119428147.28057.3364707659942003352.idtracker@ietfa.amsl.com> In-Reply-To: From: Daniel Migault Date: Thu, 17 Oct 2019 10:05:37 -0400 Message-ID: To: Adam Roach , secdir@ietf.org Cc: The IESG , IPsecME WG , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-implicit-iv@ietf.org, Tero Kivinen Content-Type: multipart/alternative; boundary="000000000000df45d005951bb602" Archived-At: Subject: Re: [secdir] [IPsec] Adam Roach's Yes on draft-ietf-ipsecme-implicit-iv-07: (with COMMENT) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 14:05:52 -0000 --000000000000df45d005951bb602 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Just to make everyone aware, we have issued a new version that we hope addresses all concerns. https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-08 Yours, Daniel On Tue, Oct 15, 2019 at 11:07 PM Daniel Migault wrote: > Hi Adam, > > Thanks for the feed back. All your comments have been fixed on the curren= t > local version available at: > > https://github.com/mglt/draft-mglt-ipsecme-implicit-iv/blob/master/draft-= ietf-ipsecme-implicit-iv.txt > > We expect to publish the version tomorrow. > > Yours, > Daniel > > > > On Tue, Oct 15, 2019 at 10:51 PM Adam Roach via Datatracker < > noreply@ietf.org> wrote: > >> Adam Roach has entered the following ballot position for >> draft-ietf-ipsecme-implicit-iv-07: Yes >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thanks for the work on this mechanism. I have no substantive comments >> beyond those that have already been shared, although I do have some >> minor editorial comments. >> >> >> ------------------------------------------------------------------------= --- >> >> =C2=A72: >> >> > In some context, such as IoT, it may be preferable to avoid carrying >> >> Nit: "...some contexts..." >> >> Fixed > >> >> ------------------------------------------------------------------------= --- >> >> =C2=A75: >> >> > An initiator supporting this feature SHOULD propose implicit IV >> > algorithms in the Transform Type 1 (Encryption Algorithm) >> > Substructure of the Proposal Substructure inside the SA Payload. >> >> Please expand "SA" on first use. >> >> Fixed > >> >> ------------------------------------------------------------------------= --- >> >> > 7. Security Consideration >> >> Nit: "Considerations" >> > Fixed > >> >> >> ------------------------------------------------------------------------= --- >> >> =C2=A77: >> >> > extensions ([RFC6311], [RFC7383]) do allow it to repeat, so there is >> > no an easy way to derive unique IV from IKEv2 header fields. >> >> Nit: "...not an easy way..." >> > Fixed > >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > --000000000000df45d005951bb602 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi,=C2=A0

    Just to make= everyone aware, we have issued a new version that we hope addresses all co= ncerns.=C2=A0
    Yours,=C2= =A0
    Daniel

    On Tue, Oct 15, 2019 at 11:07 PM Daniel Mig= ault <d= aniel.migault@ericsson.com> wrote:
    Hi Adam,=C2=A0<= div>
    Thanks for the feed back. All your comments have been fi= xed on the current local version available at:
    Yours,=C2=A0
    Daniel


    =

    = On Tue, Oct 15, 2019 at 10:51 PM Adam Roach via Datatracker <noreply@ietf.org> wrote:<= br>
    Adam Roach has e= ntered the following ballot position for
    draft-ietf-ipsecme-implicit-iv-07: Yes

    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)


    Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
    for more information about IESG DISCUSS and COMMENT positions.


    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/dra= ft-ietf-ipsecme-implicit-iv/



    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

    Thanks for the work on this mechanism. I have no substantive comments
    beyond those that have already been shared, although I do have some
    minor editorial comments.

    ---------------------------------------------------------------------------=

    =C2=A72:

    >=C2=A0 In some context, such as IoT, it may be preferable to avoid carr= ying

    Nit: "...some contexts..."

    Fixed=C2=A0
    ---------------------------------------------------------------------------=

    =C2=A75:

    >=C2=A0 An initiator supporting this feature SHOULD propose implicit IV<= br> >=C2=A0 algorithms in the Transform Type 1 (Encryption Algorithm)
    >=C2=A0 Substructure of the Proposal Substructure inside the SA Payload.=

    Please expand "SA" on first use.

    Fixed=C2=A0
    ---------------------------------------------------------------------------=

    > 7.=C2=A0 Security Consideration

    Nit: "Considerations"
    Fixed=C2=A0

    ---------------------------------------------------------------------------=

    =C2=A77:

    >=C2=A0 extensions ([RFC6311], [RFC7383]) do allow it to repeat, so ther= e is
    >=C2=A0 no an easy way to derive unique IV from IKEv2 header fields.

    Nit: "...not an easy way..."
    Fixed=C2=A0


    _______________________________________________
    IPsec mailing list
    IPsec@ietf.org
    https://www.ietf.org/mailman/listinfo/ipsec
    --000000000000df45d005951bb602-- From nobody Thu Oct 17 13:06:13 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E39120974; Thu, 17 Oct 2019 13:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=XF69q9zE; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=A8id5G8s 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 d4DaP8WFVxUN; Thu, 17 Oct 2019 13:05:55 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D47C120241; Thu, 17 Oct 2019 13:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7577; q=dns/txt; s=iport; t=1571342755; x=1572552355; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mqpORR8+Ys7aGa7LTdPcHQ1AVlglc+/sTmISs9VJEJk=; b=XF69q9zEknARG/nRDR3BnENg2piM8CjIn9xPlarngmeTPSiCpCH9r23/ j5T48POHr1Gw1saC03nz/PJVZujIllkThGDFKn90VcNjwn4Okmw940bie 9P4w3A4ym15BHHvzsM9Xznd9Va3MJ7d6hGfN7lrzeZH0/7m5lI6Ehy8DC g=; IronPort-PHdr: =?us-ascii?q?9a23=3ABlcPshzgoA6YmvnXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZudCkT+NPfsZgQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAADyyKhd/4cNJK1cCRoBAQEBAQE?= =?us-ascii?q?BAQEDAQEBAREBAQECAgEBAQGBaQMBAQEBCwGBSlAFbFcgBAsqh2wDilCCXIl?= =?us-ascii?q?rjhSBLhSBEANUCQEBAQwBARgNCAIBAYRAAoMGJDYHDgIDCQEBBAEBAQIBBQR?= =?us-ascii?q?thS0MhUsBAQEEAQEQKAYBASoCCAMBCwQCAQgRBAEBHxAhBgsdCAIEAQ0FCBq?= =?us-ascii?q?DAYJGAy4BAgykdgKBOIhhgieCfQEBBYE0AYNWDQuCFwMGgTQBikqBJh0YgUA?= =?us-ascii?q?/gRFGgh4uPoIaRwEBAoEsAQgKAQkEFIM+giyMa6ApQQqCIocMigqEJoI6h1G?= =?us-ascii?q?NXYFfjjCBP4ZlghCMUYI6AgQCBAUCDgEBBYFZATEsO3FwFTuCbBM9EBSBUIN?= =?us-ascii?q?zhRSFP3QKNWqNCQ0XB4InAQE?= X-IronPort-AV: E=Sophos;i="5.67,308,1566864000"; d="scan'208";a="345487769" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Oct 2019 20:05:53 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x9HK5rXT004786 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Oct 2019 20:05:53 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 17 Oct 2019 15:05:52 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 17 Oct 2019 15:05:52 -0500 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 17 Oct 2019 16:05:51 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KvOnz040zSIWc6Lyrrxff6bMPeTchmusXCNgotPC20QCXurMAUGvLNhWAFhcEswwk3HjFTiFah1cP3aadcVZngvd+9QEUHVlEZnBQ+bQuVDBGMBK2xJ8C9i9e7O+0HTRv27uK48JRh+jk1nuxonWt7wnlK5o0Vg6R1inAfhgoAYisrQgnoose1j6FyxNhSGTjxj0Tkq7nAXyjlSQD0+LM52tOemKNfLPwNP0p1Encq7G6qmOzpZ0yFdVI0HEMOIlwNIxy7IB0gE6mTROeIAowZyIEk/U2BNTURneofl3LWG31QWrLFBKuC7TWSS5iU8g2nCYGi81SoXJLtfAZWga8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VBy1V7EppHlpTH81kDSTtvBnYyv2AdAJHQCgdLNMZ7w=; b=R4Wm2fwim3ythKPCBrqveRC5Mnu2UhQz1yAOm/Exrc9SHT8WMzeD+AxelRU7oqBHNqRBwe6lKAifaNrHTpnZpDCNHuf0ZqCGlg2wycnv/AY7RmvuYcIa7W8gAcRSfNQFsW3ChJoaEUvjRMzqXCUQ0IGXeX/Xi2V5wEDQHbIAiZB68GDXgnHOdsfQKmn5MlcU9euufro1DbStrEWD2wbMZROGrrHsgb87uKuMYo5SdxMqnh15X7LR3BsGsXbIoAekc04/PkVns4D+ouG3zRSC0yoETgidpHpt48ArisfEjxZf8qI32zgHYXqs7Sjf/4iP6cyYrIaJkBg536IQYqcl+w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VBy1V7EppHlpTH81kDSTtvBnYyv2AdAJHQCgdLNMZ7w=; b=A8id5G8sFqucys1LGS7qHhALMAETfHe3KKtxmH/sT6+hXyFXpEtOCXwcuzdTtQmXBHAsjMSigfYlKG/f5AvnV6ouZDIWzNXHAeFhAHRZrYbGvsd6WIuPgoWgUpWs77kwVxfhRFrYIwNbEo8Fz+0ddrDUxOAiFW0wKb8hoMf6eV4= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2803.namprd11.prod.outlook.com (52.135.246.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Thu, 17 Oct 2019 20:05:50 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5082:c814:2836:9e2a]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5082:c814:2836:9e2a%7]) with mapi id 15.20.2347.024; Thu, 17 Oct 2019 20:05:50 +0000 From: "Panos Kampanakis (pkampana)" To: Yaron Sheffer , "secdir@ietf.org" CC: "draft-ietf-ace-coap-est.all@ietf.org" , "ietf@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15 Thread-Index: AQHVgcaC5NivFu6vxkuLEqSa/tiqS6ddYSVAgAHm+LA= Date: Thu, 17 Oct 2019 20:05:50 +0000 Message-ID: References: <157097172245.20767.1326966836276837764@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:2090:1009:838:76da:e180:2a19] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 300cd109-7421-408e-a07d-08d7533d6854 x-ms-traffictypediagnostic: BN7PR11MB2803: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01930B2BA8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(396003)(366004)(39860400002)(346002)(199004)(189003)(52084003)(13464003)(476003)(6246003)(186003)(6306002)(4326008)(5660300002)(55016002)(9686003)(81156014)(81166006)(8676002)(76116006)(66476007)(64756008)(8936002)(66946007)(66446008)(86362001)(66556008)(52536014)(76176011)(7696005)(53546011)(2501003)(6506007)(102836004)(33656002)(316002)(966005)(11346002)(7736002)(305945005)(14444005)(256004)(446003)(2906002)(54906003)(99286004)(110136005)(486006)(229853002)(6436002)(46003)(14454004)(6116002)(25786009)(71190400001)(74316002)(71200400001)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2803; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HkcfHpbta6pUBpAG/FowYDoUFyCHfnBTQXzF/3ReOjPRCLu4yyk+VYxTqI0AdQFWnWGWGhYlUFQWQBy6QUgFnrUoy9DKn+xn67c9iMdOzJ0KtP5tg/mLNTc5eOziN+My+jhveckOTi1IwHXVXs9Df/IDKszW/rXsQb3cLeSAs7vC52k9jjhQAWt7GqDw0sIDzLE+IfphKEmsHJ7E+eLGib1vER3ngjspEvgCZgSZ6YSwk8VURAAZhGpuTlfDu+/ocHej75pxii0WERIu/B4KzRXCq1a9Y86lD2kN5wLJUTfnMOYJUCUq/XnlhC06nnBbJRbtzp/kqoejPaIKkq1zmXD9fKfmRvTG25H5aaIXUZddYr94IBo48RZ6S3WZT5vkZZMi+jM0phFVH97FRzFkopOUhdGTI/0oN+GLjgu+SjgdKOCP+zncw1XmoXVHVJ+kwutkM1vBIvoufuHH9nCwyg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 300cd109-7421-408e-a07d-08d7533d6854 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2019 20:05:50.3392 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ERho8cwrooHKQteWL8MUrZVXWr2sEeaixdGbj6iOtaOwuPMoj/2DY8JxkRuG7rRCs9dKkT3j+Up0aj6CjcDwMQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2803 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.24, xch-rcd-014.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [secdir] [Ace] Secdir last call review of draft-ietf-ace-coap-est-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 20:06:00 -0000 Hi Yaron, I addressed the remaining issues from your responses in the git issue https= ://github.com/SanKumar2015/EST-coaps/issues/152#issuecomment-543315662=20 Please check them out and let me know if you have more comments.=20 Rgs,=20 Panos -----Original Message----- From: Ace On Behalf Of Panos Kampanakis (pkampana) Sent: Wednesday, October 16, 2019 11:06 AM To: Yaron Sheffer ; secdir@ietf.org Cc: draft-ietf-ace-coap-est.all@ietf.org; ietf@ietf.org; ace@ietf.org Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15 Hi Yaron, Thank you for the thorough review and feedback.=20 To make sure I don't miss any of your comments over an email thread, I trac= k all your feedback in git issue 152 https://github.com/SanKumar2015/EST-co= aps/issues/152 There I tried to address all your comments and question and = clarify some points.=20 I also pushed minor changes to fix a few of the issues you brought up. The = diff of the changes pushed is here https://github.com/SanKumar2015/EST-coap= s/commit/86d785f2122596f28674fe8e403d30467c98abfb=20 Please review the git issue and let us know if there are pending concerns. = Otherwise I am planning to reupload a new iteration next week.=20 Rgs,=20 Panos -----Original Message----- From: Ace On Behalf Of Yaron Sheffer via Datatracker Sent: Sunday, October 13, 2019 9:02 AM To: secdir@ietf.org Cc: draft-ietf-ace-coap-est.all@ietf.org; ietf@ietf.org; ace@ietf.org Subject: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15 Reviewer: Yaron Sheffer Review result: Has Issues This document defines a new profile for EST (simple certificate enrollment)= for restricted devices, to be run on top of CoAP and DTLS, instead of the = usual HTTP and TLS. Overall, I tend to be suspicious of "restricted" profiles, and this is a ca= se in point. An implementation of DTLS is no simpler than TLS and most woul= d probably support both protocols. And basically anything supports HTTP. So= why would it make sense to define a whole new profile just to avoid using = TCP very rarely (say, for daily certificate enrollment), when this profile = even needs to include its own fragmentation/buffering mechanisms because th= e ASN.1 payloads are too long? In other words, we are introducing new and a= dditional complexity with little or no performance gain. - 2. Only certificate-based client authentication is supported. Hopefully s= ome time soon we'll be able to use PAKE here, to bootstrap the PKI. - 4. "Crypto agility is important" - this statement is somewhat meaningless= : do we require more than one cipher suite, which would ensure some level o= f agility? - Also, when we say "Sec. 4.4 of RFC 7925" do we mean *only* Sec. 4.4 or al= so the subsections: 4.4.1 etc. - "in DTLS 1.3 the Supported Elliptic Curves extension has been renamed to = Supported Groups". This is probably true for an older version of the draft,= I couldn't find anything to support it in -32. - "the Finished message must be computed" - this whole paragraph is unclear= . Are we changing the Finished/MAC computation in DTLS (if so, this must be p= ointed out very clearly)? Or are we explaining a point about channel bindin= g (if we are, this doesn't come across). - Similarly for the following paragraph: is this a performance optimizatio= n, or a change to DTLS? And by the way, why are standard session resumption= mechanisms not used? - I don't see value in the short EST URI paths given that most of the "weig= ht" is in ASN.1 data, and the paths are negligible in comparison. Moreover, if = the paths are different, shouldn't this document formally UPDATE RFC 7030? = I think it is no longer a profile. - Non-default server port: the examples include an IPv6 address in addition= to the port number. Is there a way to use relative URIs (omitting the IP a= ddress) but include a port number? The server may not know its own IP addre= ss (IPv4 with NAT) or the address may be dynamic. - The server MUST support the default /.well-known/est root resource, but t= hen in the next sentence we discuss non-default URIs. In the case of the se= rver having multiple "identities" (the main purpose of the "arbitrary label", AF= AIU), the root resource is confusing - which identity is it associated with= ? And then how is discovery managed for each identity, and is there a way to = discover the identities? - There is nowhere in this document a full formal definition of content typ= e TBD287 (a single cert). - Content type negotiation: I can see how it works for enrollment. But in t= he case of /cacerts, if the server has a list of certs in its explicit TA s= tore (e.g. to support rollover), how can TBD287 (a single cert) make sense? - It is mighty confusing to denote "content format" by "ct" (presumably, th= is stands for "content type"). - "ASN.1 encoded in binary format" - I think this should be, "DER-encoded A= SN.1, in its native binary form". - Please don't use "he" and "she" for the server and the client. Both are m= erely "it". - "The Registrar MUST authenticate and optionally authorize the client requ= ests" - this statement is too weak. The Registrar must also ensure that cli= ents only send CSRs that pertain to their authenticated identity (channel b= inding), even when POP-linking is not used. I think this is worthy of its o= wn subsection, describing the validation required for each particular EST f= low. - The following paragraph is not clear: is PoP-linking useful/recommended/m= andated in this scenario? IMO there should be some 2119 word regarding serv= er-side validation of the tls-unique. - "Table 1 contains the URI mappings between EST-coaps and EST that the Reg= istrar MUST adhere to." But the immediately preceding paragraph describes a= case where a server-side generation on the EST-coaps side is mapped to cli= ent-side generation on the EST-HTTPS side, which is not a Table 1 mapping! - "the encrypted CMS EnvelopedData blob MUST be converted at the Registrar"= - can this be done without decrypting the blob, IOW must the Registrar be = privy to the key wrapping key? - The Registrar must support resource discovery: does it mean that resource= discovery messages are simply proxied upstream, or that the Registrar pres= ents a simpler resource structure (maybe with no discovery) to its clients = while performing discovery upstream? - Security Considerations: there's a long discussion about replacing the im= plicit TAs with explicit ones. If we (rightly) mandate that the client re-v= erify the server's cert after getting the /certs response, we are losing mo= st of the minor performance gain that keeping the DTLS connection open migh= t have given us. So why not unambiguously mandate the simpler "MUST close t= he connection after /certs" instead? Besides, /cacerts is a very rare opera= tion. Why optimise it at all? - "Improper CSR requests" - what are they? What's the server supposed to do= ? Please give a reference. - A.3, response: I may be missing something, but the binary blob "3081...9f= d9" does not parse as PKCS#8 to me. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Thu Oct 17 20:48:09 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F63B1201DC for ; Thu, 17 Oct 2019 20:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhPbQ8ERJkbB for ; Thu, 17 Oct 2019 20:48:06 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 1EDAB120052 for ; Thu, 17 Oct 2019 20:48:05 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9I3lx4D012638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 17 Oct 2019 23:48:02 -0400 Date: Thu, 17 Oct 2019 20:47:59 -0700 From: Benjamin Kaduk To: Christian Huitema Cc: secdir@ietf.org Message-ID: <20191018034759.GC43312@kduck.mit.edu> References: <157094241575.1368.11692727174528463365@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <157094241575.1368.11692727174528463365@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-anima-bootstrapping-keyinfra-28 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 03:48:08 -0000 Hi Christian, Thanks for taking the time to re-review this epic. It's reassuring to have the extra opinion that the document is much improved! I asked the authors to respond to your few remaining comments and am holding a Discuss ballot for a couple of boring points about clarity of protocol details. -Ben On Sat, Oct 12, 2019 at 09:53:35PM -0700, Christian Huitema via Datatracker wrote: > Reviewer: Christian Huitema > Review result: Has Nits > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area directors. > Document editors and WG chairs should treat these comments just like any other > last call comments. > > The summary of the review is ready with nits. > > The draft-28 is much improved from the version that I originally reviewed, or > even from the intermediate version 20. The issues flagged in the original > review are now addressed. The draft now develops options for "nonceless > vouchers", which allows for offline onboarding scenario and addresses one of > the concerns expressed in my initial review. It also develops a TOFU option for > MASA servers, which has different security properties than the initial design. > That may be a useful mode of operation, and the related security issues are > discussed in subsection 11.4 of the security consideration sections. Draft 28 > addresses scenarios like "death of a manufacturer" that were flagged in the > first reviews. Generally, I find the revised security consideration section > much more developed and comprehensive than in the original drafts. > > Draft 28 adds an extended privacy consideration section, which is welcome. On > the other hand, the authors may consider toning down the commentary text in > section 10.3, "The so-called "call-home" mechanism that occurs as part of the > BRSKI-MASA connection standardizes what has been deemed by some as a sinister > mechanism for corporate oversight of individuals." That text was already in > draft-20, but feels a bit too petulant for standard track RFC. > > I flagged a couple of technical nits: > > I have a minor concern with the text on TLS usage in section 5.1 and 5.2. In > section 5.1, BRSKI-EST TLS establishment details, I read "Use of TLS 1.3 (or > newer) is encouraged. TLS 1.2 or newer is REQUIRED." Does that mean that > BRSKI-EST TLS servers MAY reject connection attempts using a TLS version lower > than 1.2, or maybe that pledges SHOULD refuse connections if the server tries > to negotiate a TLS version lower than 1.2? We have experience in other > deployments that even "low end" vendors will not cheap lower security solutions > if that leads to interop failures, and that having at least some > implementations being strict in what they accept is a good way to raise the bar > for everybody. Same issue in section 5.2, regarding BRSKI MASA connections. > > In section 5.4.1, "This document does not make a specific recommendation" > (regarding whether to use public PKI, DANE, or pinned certificates for MASA > authentication. That's probably fine from a security point of view, but the > absence of at least one recommended solution ay well end up causing interesting > interoperability issues. > > Editorial Nits: > > In section 1.4, the text says "The major intended beneficiary is that it > possible to use the credentials deployed by this protocol to secure the > Autonomic Control Plane (ACP) ([I-D.ietf-anima-autonomic-control-plane])." I > think you mean "benefit" instead of "beneficiary". > > In section 2.3.1, the text says "The serialNumber fields is defined in > [RFC5280], and is a SHOULD field in [IDevID]." I understand that you mean that > according to [IDevId] the field SHOULD be present, but calling that a "SHOULD > field" is jargon. > > In section 7.4.1, I read that "A MASA has the option of not including a nonce > is in the voucher, and/or not requiring one to be present in the > voucher-request." The "is in" looks like some kind of typo. > > In section 10.2, typo, "arbtirary" for "arbitrary". > > From nobody Fri Oct 18 03:48:31 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7024F12006E for ; Fri, 18 Oct 2019 03:48:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.106.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <157139570940.3816.11770801245601858362.idtracker@ietfa.amsl.com> Date: Fri, 18 Oct 2019 03:48:29 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 10:48:29 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-10-31 Reviewer LC end Draft Takeshi Takahashi None draft-ietf-netmod-yang-data-ext-04 Last calls: Reviewer LC end Draft Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Daniel Gillmor 2018-03-19 draft-gutmann-scep-14 Leif Johansson 2019-09-02 draft-ietf-tls-sni-encryption-08 Kathleen Moriarty 2019-09-23 draft-ietf-isis-yang-isis-cfg-42 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Sandra Murphy 2019-07-08 draft-ietf-i2nsf-applicability-18 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Tim Polk 2019-08-01 draft-ietf-acme-star-10 Vincent Roca 2019-10-14 draft-ietf-dmm-pmipv6-dlif-04 Stefan Santesson 2019-10-10 draft-ietf-payload-rtp-ttml-03 Melinda Shore 2019-11-07 draft-thaler-iftype-reg-05 Valery Smyslov 2019-10-30 draft-ietf-core-senml-more-units-02 Robert Sparks 2019-10-29 draft-ietf-cose-hash-sig-04 David Waltermire 2019-08-07 draft-ietf-oauth-jwt-introspection-response-08 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Derrell Piper 2019-10-23 draft-ietf-nfsv4-rpc-tls-03 Tim Polk 2019-10-04 draft-ietf-lwig-curve-representations-08 Next in the reviewer rotation: Sean Turner Carl Wallace David Waltermire Samuel Weiler Brian Weis Klaas Wierenga Christopher Wood Paul Wouters Liang Xia Taylor Yu From nobody Fri Oct 18 04:12:55 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9DBB120110 for ; Fri, 18 Oct 2019 04:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es 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 hkgXosWE7mIQ for ; Fri, 18 Oct 2019 04:12:41 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 523E7120851 for ; Fri, 18 Oct 2019 04:12:40 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id y91so4246886ede.9 for ; Fri, 18 Oct 2019 04:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kFke+xMnACHK4gRyehapddZVAaZLJqvaDBZc8OohRMo=; b=sFqsMhqjDOFzOwhutj4blbpv5Wpt2PKOxwO8R18G+Gdov9q14qewEcwXr0daBrCxzm /81019CyIj9i15biclbrddbSCCzMabYw3nSuX3d7qnXXjF9v7YTwjOPNZJLHncIMGvVj FqUWFWBZlJYuflqq9nUDZSOkQ1abnstrjQXVoMlmWirVTMbSTOM15WCAhNAwdg2lDis7 Sc1xrD9HaECPNCmZOIHqffbq5KfkqizCo3maIbCga+oJ4FcJfrVwQYdIvvstsJmoxcF1 NLdxdwB23CacT0HA+klLCDmHgKOC+UdTPL0YgNugHyfi0OCzNcLqs4+RJMsHIa4f/HDO uMQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kFke+xMnACHK4gRyehapddZVAaZLJqvaDBZc8OohRMo=; b=Od4hvbSQxXbykhvvJWyM2NaGVS1O+wqx3GpNY4bnNrTmOdA4LniU2IJvxOFfkejend J5d3jxXrw2uNou7d5HFVpD/Sn1y+aLA/36YxZr2IaW4FxN77bmP8JJLjuHwyp55AhTPT Z7FrRFgwxXLmLnGkiC2dsNrwFqW0zsrhhCwimEx42hRVcysV/VtYJKLcoA24EptiL1G8 y+Ozy51tCLGYZtRuWWWg91zT5cc3Ci577+52ANc1J9a/Jl5+X5kByDODlh+FeTgrvEKt O4ybRluxMb/Z+A4VhghE5MqvBIyEjm6mhMFLXP8I0AG36efX2TgNTCU6FbOwTa5iTc5U JcZw== X-Gm-Message-State: APjAAAWupXd1FRNRuOLJMvUpiY2lRObnn4rvSwrnpnmE5aMAfdS48pXK 0TU/T9zYlpXqnX70lNyHL6v/B2qEtLu9BKSYS0G/3w== X-Google-Smtp-Source: APXvYqwrQ1Tsllc6ZguvIHVqe8uZVx+viVXd8gBuxAoRdrnXz8kEtu/P6bOyC5lJphtRaug2hhqImhx05DoIwP5p2WA= X-Received: by 2002:a17:906:6ad7:: with SMTP id q23mr7813041ejs.214.1571397158408; Fri, 18 Oct 2019 04:12:38 -0700 (PDT) MIME-Version: 1.0 References: <157100555733.20750.5488529297693995498@ietfa.amsl.com> In-Reply-To: <157100555733.20750.5488529297693995498@ietfa.amsl.com> From: CARLOS JESUS BERNARDOS CANO Date: Fri, 18 Oct 2019 13:12:22 +0200 Message-ID: To: Joseph Salowey Cc: secdir@ietf.org, draft-ietf-dmm-distributed-mobility-anchoring.all@ietf.org, The IESG , dmm Content-Type: multipart/alternative; boundary="0000000000006db02105952d69ef" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dmm-distributed-mobility-anchoring-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 11:12:44 -0000 --0000000000006db02105952d69ef Content-Type: text/plain; charset="UTF-8" Dear Joseph, Thanks a lot for the review. We will improve the security consideration section by including also some of the considerations mentioned in draft-ietf -dmm-deployment-models-04, and also by better scoping current text. We believe we don't need much more in terms of text, as the document is informational, and the actual security mechanisms for a distributed anchoring solution would depend on the specifics of that solution. We can also better reflect that rational in the text. Thanks, Carlos On Mon, Oct 14, 2019 at 12:25 AM Joseph Salowey via Datatracker < noreply@ietf.org> wrote: > Reviewer: Joseph Salowey > Review result: Has Issues > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The summary of the review is the document has issues with the security > considerations section. > > The security consideration section is extremely light. It mainly contains > text > from RFC 7333. It seems that there should be more discussion of security > as it > relates to the different configurations and different cases. Do each of > these > cases have the same security properties and require the same types of > security > controls? > > Are the IPSEC recommendations mentioned in the security considerations of > draft-ietf-dmm-deployment-models-04 applicable for all the cases? Should > these be pointed out in the security considerations section? > > > -- Special Issue "Beyond 5G Evolution": https://www.mdpi.com/journal/electronics/special_issues/beyond_5g --0000000000006db02105952d69ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Dear Joseph,

    Thanks a lot for the revie= w. We will improve the security consideration section by including also som= e of the considerations mentioned in=C2=A0draft-ietf-dmm-deployment-models-04, and also by better scoping current text. We believ= e we don't need much more in terms of text, as the document is informat= ional, and the actual security mechanisms for a distributed anchoring solut= ion would depend on the specifics of that solution. We can also better refl= ect that rational in the text.

    Thanks,
    <= br>
    Carlos

    On Mon, Oct 14, 2019 at 12:25 AM Joseph Salowey v= ia Datatracker <noreply@ietf.org= > wrote:
    Revi= ewer: Joseph Salowey
    Review result: Has Issues

    I have reviewed this document as part of the security directorate's
    ongoing effort to review all IETF documents being processed by the
    IESG.=C2=A0 These comments were written primarily for the benefit of the security area directors.=C2=A0 Document editors and WG chairs should treat<= br> these comments just like any other last call comments.

    The summary of the review is the document has issues with the security
    considerations section.

    The security consideration section is extremely light.=C2=A0 It mainly cont= ains text
    from RFC 7333.=C2=A0 It seems that there should be more discussion of secur= ity as it
    relates to the different configurations and different cases.=C2=A0 =C2=A0Do= each of these
    cases have the same security properties and require the same types of secur= ity
    controls?

    Are the IPSEC recommendations mentioned in the security considerations of draft-ietf-dmm-deployment-models-04 applicable for all the cases?=C2=A0 =C2= =A0Should
    these be pointed out in the security considerations section?




    --
    --0000000000006db02105952d69ef-- From nobody Fri Oct 18 09:28:28 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 339B2120870; Fri, 18 Oct 2019 09:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1571415965; bh=m6vQWalALcoD0piCvVBy8rfj40zHpudakGU78kEhiNA=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=wV+xgFrhC4UwFC4zALHIB0LYk/QF7tODUBJbXLuCmcp1fQZw8+qxv9EAPU0ts1KKh Owb/BJjhEMGcpljaCCk6ISUzuwEp3X0SSNd0pSBb+lg1rMUMVIPm3YJTgObPYC28CS n93jSX7xUgSyJIQkYYuoCX5mXnu+HFaWT9lIWjis= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Oct 18 09:26:01 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F38D112086B; Fri, 18 Oct 2019 09:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1571415961; bh=m6vQWalALcoD0piCvVBy8rfj40zHpudakGU78kEhiNA=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=A4BGL/XdUYJeIWiBabfK+rCSwO05unMKJt3YqplSKapfJAENxDhRUhNmzvwP3QRNP +F1eNv825uwTIRAL+wDysxVew2mTb0nx0tDxrBkdaXJxdg8zgrgbRs7omMjiPNusWa a9RneWdkqMZPwEE/yiJHoADxZl0fWJOMlf87SwX4= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A938120103 for ; Fri, 18 Oct 2019 09:25:52 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.106.0 Auto-Submitted: auto-generated Precedence: bulk Reply_to: MIME-Version: 1.0 Message-ID: <157141595216.3845.10953218042567195196.idtracker@ietfa.amsl.com> Date: Fri, 18 Oct 2019 09:25:52 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 18 Oct 2019 09:28:27 -0700 Subject: [secdir] [new-work] WG Review: Media OPerationS (mops) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 16:26:10 -0000 QSBuZXcgSUVURiBXRyBoYXMgYmVlbiBwcm9wb3NlZCBpbiB0aGUgT3BlcmF0aW9ucyBhbmQgTWFu YWdlbWVudCBBcmVhLiBUaGUKSUVTRyBoYXMgbm90IG1hZGUgYW55IGRldGVybWluYXRpb24geWV0 LiBUaGUgZm9sbG93aW5nIGRyYWZ0IGNoYXJ0ZXIgd2FzCnN1Ym1pdHRlZCwgYW5kIGlzIHByb3Zp ZGVkIGZvciBpbmZvcm1hdGlvbmFsIHB1cnBvc2VzIG9ubHkuIFBsZWFzZSBzZW5kIHlvdXIKY29t bWVudHMgdG8gdGhlIElFU0cgbWFpbGluZyBsaXN0IChpZXNnQGlldGYub3JnKSBieSAyMDE5LTEw LTI4LgoKTWVkaWEgT1BlcmF0aW9uUyAobW9wcykKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KQ3VycmVudCBzdGF0 dXM6IFByb3Bvc2VkIFdHCgpDaGFpcnM6CiAgTGVzbGllIERhaWdsZSA8bGRhaWdsZUB0aGlua2lu Z2NhdC5jb20+CgpBc3NpZ25lZCBBcmVhIERpcmVjdG9yOgogIMOJcmljIFZ5bmNrZSA8ZXZ5bmNr ZUBjaXNjby5jb20+CgpPcGVyYXRpb25zIGFuZCBNYW5hZ2VtZW50IEFyZWEgRGlyZWN0b3JzOgog IFdhcnJlbiBLdW1hcmkgPHdhcnJlbkBrdW1hcmkubmV0PgogIElnbmFzIEJhZ2RvbmFzIDxpYmFn ZG9uYUBnbWFpbC5jb20+CgpUZWNobmljYWwgYWR2aXNvcnM6CiAgV2FycmVuIEt1bWFyaSA8d2Fy cmVuQGt1bWFyaS5uZXQ+CgpNYWlsaW5nIGxpc3Q6CiAgQWRkcmVzczogbW9wc0BpZXRmLm9yZwog IFRvIHN1YnNjcmliZTogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tb3Bz CiAgQXJjaGl2ZTogaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9tb3Bz LwoKR3JvdXAgcGFnZTogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ncm91cC9tb3BzLwoK Q2hhcnRlcjogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvY2hhcnRlci1pZXRmLW1v cHMvCgpJbnRlcm5ldC0gYW5kIEludGVybmV0LXByb3RvY29sLWRlbGl2ZXJlZCBtZWRpYSBpcyB3 aWRlc3ByZWFkLCBsZWFkaW5nIHRvCnNpZ25pZmljYW50IHRlY2hub2xvZ3kgZGV2ZWxvcG1lbnQg YWNyb3NzIGluZHVzdHJpZXMgbm90IHRyYWRpdGlvbmFsbHkgdGhvdWdodApvZiBhcyBJbnRlcm5l dCB0ZWNobm9sb2d5IGRldmVsb3BlcnMgb3Igb3BlcmF0b3JzLCBhcyB3ZWxsIGFzIGNvbnNpZGVy YWJsZQpxdWFudGl0aWVzIG9mIHRyYWZmaWMgb24gbG9jYWwgYW5kIHRyYW5zaXQgbmV0d29ya3Mu IFRoZSBmb2N1cyBvZiBNT1BTIGlzIG9uCmlkZW50aWZ5aW5nIGFyZWFzIHdoZXJlIGV4aXN0aW5n IHByb3RvY29scyBhbmQvb3IgbmV0d29ya3MgYXJlIGNoYWxsZW5nZWQgYnkKdGhlc2UgdXBkYXRl ZCByZXF1aXJlbWVudHMuCgpNT1BTIHdpbGwgc29saWNpdCBpbnB1dCBvbiBvcGVyYXRpb25hbCBp c3N1ZXMgYW5kIHByYWN0aWNlczsgZXhpc3RpbmcgYW5kCnByb3Bvc2VkIHRlY2hub2xvZ2llcyBy ZWxhdGVkIHRvIHRoZSBkZXBsb3ltZW50LCBlbmdpbmVlcmluZywgYW5kIG9wZXJhdGlvbgpvZiBt ZWRpYSBzdHJlYW1pbmcgYW5kIG1hbmlwdWxhdGlvbiBwcm90b2NvbHMgYW5kIHByb2NlZHVyZXMg aW4gdGhlIGdsb2JhbApJbnRlcm5ldDsgYW5kIGludGVyLWRvbWFpbiBhbmQgd2l0aGluLWRvbWFp biBuZXR3b3JraW5nLiBJbiB0aGUgY29udGV4dCBvZgp0aGlzIHdvcmtpbmcgZ3JvdXAsIG1lZGlh IGlzIGNvbnNpZGVyZWQgdG8gaW5jbHVkZSB0aGUgdHJhbnNwb3J0IG9mIHZpZGVvLAphdWRpbywg b2JqZWN0cyBhbmQgYW55IGNvbWJpbmF0aW9uIHRoZXJlb2YsIHBvc3NpYmx5IG5vbi1zZXF1ZW50 aWFsbHkuIFRoZQpzY29wZSBpcyBtZWRpYSBhbmQgbWVkaWEgcHJvdG9jb2xz4oCZIGludGVyYWN0 aW9ucyB3aXRoIHRoZSBuZXR3b3JrLCBidXQgbm90CnRoZSB0ZWNobm9sb2dpZXMgb2YgY29udHJv bCBwcm90b2NvbHMgb3IgbWVkaWEgZm9ybWF0cy4KCk1PUFMgcHJvdmlkZXMgYSB2ZW51ZSBmb3Ig Ym90aCB2aWRlbyBpbmR1c3RyeSBhbmQgSW50ZXJuZXQgZW5naW5lZXJpbmcKZXhwZXJ0cyB0byBl bmdhZ2UgaW4gZGlzY3Vzc2lvbiBvZiB2aWRlbyB0ZWNobm9sb2d54oCZcyByZXF1aXJlbWVudHMg b2YKbmV0d29ya2luZyBzdGFuZGFyZHMsIGFzIHdlbGwgYXMgcHJvcG9zYWxzIGZvciBuZXcgdXNl cyBvZiBJUCB0ZWNobm9sb2d5CmluIHZpZGVvLiBXaGVyZSBuZXcgcHJvdG9jb2xzIGFyZSBuZWVk ZWQsIE1PUFMgd2lsbCBoZWxwIGlkZW50aWZ5IGNhbmRpZGF0ZQp2ZW51ZXMgZm9yIHRoZWlyIGRl dmVsb3BtZW50LgoKVGhlIGdvYWxzIG9mIE1PUFMgaW5jbHVkZSBkb2N1bWVudGluZyBleGlzdGlu ZyBwcm90b2NvbCBhbmQgb3BlcmF0aW9uYWwgaXNzdWVzCndpdGggbWVkaWEgb24gdGhlIEludGVy bmV0LCBhbmQgaWRlbnRpZnlpbmcgcmVxdWlyZW1lbnRzIGZvciBwb3RlbnRpYWwgSUVURgp3b3Jr LiBUaGUgZ2VuZXJhbCBwcm9jZXNzIG9mIGVsYWJvcmF0aW9uIHRocm91Z2ggZG9jdW1lbnRhdGlv biB3aWxsIGJlIGZvcgppc3N1ZXMgdG8gYmUgaWRlbnRpZmllZCAob24gdGhlIG1haWxpbmcgbGlz dCkgYW5kIHByZXNlbnRhdGlvbnMgbWFkZSBhdCBXRwptZWV0aW5ncy4gV2hlbiB0b3BpY3MgbWVy aXQgbW9yZSBjb2hlcmVudCBkb2N1bWVudGF0aW9uLCBNT1BTIHdpbGwgYWRvcHQKd29ya2luZyBn cm91cCBkb2N1bWVudHMgdG8gY2FwdHVyZSB0aGUgaW5mb3JtYXRpb24gaW4gSW50ZXJuZXQtRHJh ZnRzLiBJZiB0aGUKd29ya2luZyBncm91cCBjb25zZW5zdXMgaXMgdGhhdCB0aGUgbWF0ZXJpYWwg b2YgdGhlIEludGVybmV0LURyYWZ0IGlzCmdlbmVyYWxseSB1c2VmdWwgZm9yIGFyY2hpdmFsIHB1 cnBvc2VzLCB0aGUgV0cgd2lsbCBzZWVrIHB1YmxpY2F0aW9uIG9mIHRoZQp3b3JrIGl0ZW1zIGFz IFJGQ3MuIEF0IGFueSBwb2ludCDigJQgZnJvbSBlYXJseSBkaXNjdXNzaW9uIG9mIHRvcGljcywg dGhyb3VnaApsYXRlciBkb2N1bWVudGF0aW9uIHN0YWdlcyDigJQgTU9QUyBtYXkgaWRlbnRpZnkg YSBtb3JlIGFwcHJvcHJpYXRlIFdHIGZvciB0aGUKbWF0dGVyIGFuZC9vciBkb2N1bWVudCwgYW5k IGRpc3BhdGNoIGl0LgoKV2l0aCB0aGF0IGluIG1pbmQsIE1PUFMgd2lsbDoKCjEvIFNvbGljaXQg cmVndWxhciB1cGRhdGVzIGZyb20gb3RoZXIgbWVkaWEgdGVjaG5vbG9neSBkZXZlbG9waW5nCmNv bnNvcnRpYS9zdGFuZGFyZHMgYm9kaWVzIHdvcmtpbmcgd2l0aCBJRVRGLWRldmVsb3BlZCBwcm90 b2NvbHMuCgoyLyBTb2xpY2l0IGlucHV0IGZyb20gbmV0d29yayBvcGVyYXRvcnMgYW5kIHVzZXJz IHRvIGlkZW50aWZ5IG9wZXJhdGlvbmFsCmlzc3VlcyB3aXRoIG1lZGlhIGRlbGl2ZXJ5IGluIGFu ZCBhY3Jvc3MgbmV0d29ya3MsIGFuZCBkZXRlcm1pbmUgc29sdXRpb25zIG9yCndvcmthcm91bmRz IHRvIHRob3NlIGlzc3Vlcy4KCjMvIFNvbGljaXQgZGlzY3Vzc2lvbiBhbmQgZG9jdW1lbnRhdGlv biBvZiB0aGUgaXNzdWVzIGFuZCBvcHBvcnR1bml0aWVzIGluCm1lZGlhIGFjcXVpc2l0aW9uIGFu ZCBkZWxpdmVyeSwgYW5kIG9mIHRoZSByZXN1bHRpbmcgcHJvdG9jb2xzIGFuZAp0ZWNobm9sb2dp ZXMgZGV2ZWxvcGVkIG91dHNpZGUgdGhlIElFVEYuCgo0LyBEb2N1bWVudCBvcGVyYXRpb25hbCBy ZXF1aXJlbWVudHMgZm9yIG1lZGlhIGFjcXVpc2l0aW9uIChmb3IgZXhhbXBsZSwgZnJvbQpjYW1l cmFzIGFuZCByZWNvcmRpbmcgZGV2aWNlcykgYW5kIGRlbGl2ZXJ5LgoKNS8gRGV2ZWxvcCBvcGVy YXRpb25hbCBpbmZvcm1hdGlvbiB0byBhaWQgaW4gb3BlcmF0aW9uIG9mIG1lZGlhIHRlY2hub2xv Z2llcwppbiB0aGUgZ2xvYmFsIEludGVybmV0LgoKVGhlc2UgYWN0aXZpdGllcyBzaG91bGQgZG9j dW1lbnQgbWVkaWEgb3BlcmF0aW9uYWwgZXhwZXJpZW5jZSwgaW5jbHVkaW5nCmdsb2JhbCBJbnRl cm5ldCwgaW50ZXItZG9tYWluIGFuZCB3aXRoaW4tZG9tYWluIG9wZXJhdGlvbnMuCgpJbiBhbGwg Y2FzZXMgb2Ygd29ya2luZyB3aXRoIG90aGVyIG9yZ2FuaXphdGlvbnMgbWVudGlvbmVkIGFib3Zl LCBNT1BTIHdpbGwKd29yayB3aXRoIGV4aXN0aW5nIGxpYWlzb24gbWFuYWdlcnMgd2hlcmUgdGhl IElFVEYgaGFzIHRoZW0sIGFuZCBpbmZvcm1hbApjb25uZWN0aW9ucyB3aXRoIG90aGVyIG9yZ2Fu aXphdGlvbnMgb3RoZXJ3aXNlLiBJZiBuZXcgZm9ybWFsIGxpYWlzb24KcmVsYXRpb25zaGlwcyBh cmUgcmVxdWlyZWQsIE1PUFMgd2lsbCB3b3JrIHdpdGggdGhlIElBQiB0byBoZWxwIGVzdGFibGlz aAp0aGVtLgoKTWVkaWEgb3BlcmF0aW9uYWwgYW5kIGRlcGxveW1lbnQgaXNzdWVzIHdpdGggc3Bl Y2lmaWMgcHJvdG9jb2xzIG9yCnRlY2hub2xvZ2llcyAoc3VjaCBhcyBBcHBsaWNhdGlvbnMsIFRy YW5zcG9ydCBQcm90b2NvbHMsIFJvdXRpbmcgUHJvdG9jb2xzLApETlMgb3IgU3ViLUlQIFByb3Rv Y29scykgcmVtYWluIHRoZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgZ3JvdXBzIG9yIGFyZWFzCnJl c3BvbnNpYmxlIGZvciB0aG9zZSBwcm90b2NvbHMgb3IgdGVjaG5vbG9naWVzLiBIb3dldmVyLCB0 aGUgTU9QUyBXb3JraW5nCkdyb3VwIG1heSBwcm92aWRlIGlucHV0IHRvIHRob3NlIGFyZWFzL2dy b3VwcywgYXMgbmVlZGVkLCBhbmQgY29vcGVyYXRlIHdpdGgKdGhvc2UgYXJlYXMvZ3JvdXBzIGlu IHJldmlld2luZyBzb2x1dGlvbnMgdG8gTU9QUyBvcGVyYXRpb25hbCBhbmQgZGVwbG95bWVudApw cm9ibGVtcy4KClRoZXJlIG11c3QgYmUgYSBjb250aW51aW5nIGV4cHJlc3Npb24gb2YgaW50ZXJl c3QgZm9yIHRoZSBXb3JraW5nIEdyb3VwIHRvCndvcmsgb24gYSBwYXJ0aWN1bGFyIHdvcmsgaXRl bS4gSWYgdGhlcmUgaXMgbm8gbG9uZ2VyIHN1ZmZpY2llbnQgaW50ZXJlc3QgaW4KdGhlIFdvcmtp bmcgR3JvdXAgaW4gYSB3b3JrIGl0ZW0sIHRoZSBpdGVtIG1heSBiZSByZW1vdmVkIGZyb20gdGhl IGxpc3Qgb2YKV29ya2luZyBHcm91cCBpdGVtcy4KClRoZSBJRVNHIGlzIGVzdGFibGlzaGluZyB0 aGlzIHdvcmtpbmcgZ3JvdXAgb24gYW4gZXhwZXJpbWVudGFsIGJhc2lzIGFuZAppbnRlbmRzIHRv IHJldmlldyBpdCwgZm9yIHJlY2hhcnRlcmluZyB0byBjb250aW51ZSBvciBlbHNlIGNsb3N1cmUs IGluIDIKeWVhcnMuCgpNaWxlc3RvbmVzOgoKICBGZWIgMjAyMCAtIERyYWZ0IG9mIGVkZ2UgbmV0 d29yayBvcGVyYXRpb25hbCBjb25zaWRlcmF0aW9ucyBmb3Igc3RyZWFtaW5nCiAgbWVkaWEKCiAg RmViIDIwMjAgLSBJbml0aWFsIGRyYWZ0IG9wZXJhdGlvbmFsIGNvbnNpZGVyYXRpb25zIGZvciBs b3cgbGF0ZW5jeQogIHN0cmVhbWluZyB2aWRlbyBhcHBsaWNhdGlvbnMKCiAgTWFyIDIwMjAgLSBE cmFmdCBkb2N1bWVudGluZyBTdHJlYW1pbmcgVmlkZW8gQWxsaWFuY2UgKFNWQSkgcmVsaWFuY2Ug b24KICBJRVRGIHByb3RvY29scwoKICBNYXIgMjAyMCAtIERyYWZ0IGRvY3VtZW50aW5nIFNvY2ll dHkgb2YgTW90aW9uIFBpY3R1cmUgYW5kIFRlbGV2aXNpb24KICBFbmdpbmVlcnMgKFNNUFRFKSBw cm90b2NvbCByZWxpYW5jZSBvbiBJRVRGIHByb3RvY29scwoKICBKdWwgMjAyMCAtIExhc3QtY2Fs bCBkb2N1bWVudCBvbiBTdHJlYW1pbmcgVmlkZW8gQWxsaWFuY2UgKFNWQSkgcmVsaWFuY2Ugb24K ICBJRVRGIHByb3RvY29scyAoaW5jbHVkaW5nIGV4cGxpY2l0IG91dHJlYWNoIHRvIFNWQSkKCiAg SnVsIDIwMjAgLSBMYXN0LWNhbGwgZG9jdW1lbnQgb24gU29jaWV0eSBvZiBNb3Rpb24gUGljdHVy ZSBhbmQgVGVsZXZpc2lvbgogIEVuZ2luZWVycyAoU01QVEUpIHByb3RvY29sIHJlbGlhbmNlIG9u IElFVEYgcHJvdG9jb2xzIChpbmNsdWRpbmcgZXhwbGljaXQKICBvdXRyZWFjaCB0byBTTVBURSkK CiAgSnVsIDIwMjAgLSBSZXZpc2VkIGRyYWZ0IG9mIGVkZ2UgbmV0d29yayBvcGVyYXRpb25hbCBj b25zaWRlcmF0aW9ucyBmb3IKICBzdHJlYW1pbmcgbWVkaWEKCiAgSnVsIDIwMjAgLSBSZXZpc2Vk IGRyYWZ0IG9wZXJhdGlvbmFsIGNvbnNpZGVyYXRpb25zIGZvciBsb3cgbGF0ZW5jeQogIHN0cmVh bWluZyB2aWRlbyBhcHBsaWNhdGlvbnMKCiAgTm92IDIwMjAgLSBMYXN0LWNhbGwgZG9jdW1lbnQg b24gZWRnZSBuZXR3b3JrIGNvbnNpZGVyYXRpb25zIGZvciBzdHJlYW1pbmcKICBtZWRpYQoKICBO b3YgMjAyMCAtIExhc3QtY2FsbCBkb2N1bWVudCBvbiBvcGVyYXRpb25hbCBjb25zaWRlcmF0aW9u cyBmb3IgbG93IGxhdGVuY3kKICBzdHJlYW1pbmcgdmlkZW8gYXBwbGljYXRpb25zCgogIE5vdiAy MDIwIC0gRGV2ZWxvcCB3b3JrIGl0ZW1zIHNwZWNpZmljIHRvIG1lZGlhIGFjcXVpc2l0aW9uIGFu ZCBkZWxpdmVyeQoKICBOb3YgMjAyMSAtIElFU0cgdG8gZGVjaWRlIHdoZXRoZXIgY29udGludWUs IHJlLWNoYXJ0ZXIgb3IgY2xvc2UgTU9QUyBXRwoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCm5ldy13b3JrIG1haWxpbmcgbGlzdApuZXctd29ya0BpZXRm Lm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldy13b3JrCg== From nobody Fri Oct 18 15:58:03 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459571209C0; Fri, 18 Oct 2019 15:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 TocsZbXy17ws; Fri, 18 Oct 2019 15:57:40 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-dm3nam06on0705.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe56::705]) (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 E0A9B120979; Fri, 18 Oct 2019 15:57:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ScIc5yGX7lvGAAR4TZNSXq2ATV8aSQg5TL/yVFw1tMohliKECVtIfgViw8p3pLmZzBkgbbLqV5nJ9NI37Nol2kUY6yxqBh/gAyL8C1UlR2Nm2bnbUR6vOAWFI3vnKDtS8Lr2/+g8pjQQ+ZtAALPiQrt9z119J6EAudnZkQYkJFdSp/KfJrSMWg5NCsIGbJVQu1EVIz6V4Hru6Ychna5BVL80p97roLwsOojZl+d6LWvP3qBOrU3N3fiZax2yhihs11SWpJUlQzWOEo823wiC1W5yInPO+T2QLXmLGJNUuCIsJ92Bdl1a7806xwblNhzG+MLfA1h5IPGR11M5MtqiRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GHiIrx7YCp8ifNnsC1qHyALcebOkMXvV31Aqb01WRJg=; b=JhefbyljEyU4AB4lGP/gn2uiNVSTNub60uwTvusz/rqZInMvrfspvLukWeDtVI3FCWLnbOo/Qbfi9m806TNGWUgc1YGyKTOhNm3cQI6oHyNESiLcIBN5eDwDSCM8tI4DeMRHcZ+CNIT0FQFnunh7fB5SnyXQfjTUmZAJyjw2KyPUmB+Mlm6ejtlvzcfNqQlqcUGvDJ9KINIAQmlKlIakY5Us1+B6wacN1iGCBiPSufEGHpcPVMoJ0gMQaDBAnrWcoO1lDVyS7wS+HH8v64BUjo9kujkFxnJstaQqke5vnM4gt36l7JPyg/LAs0jzgsiVjCYbNvzBfbhBgjSM9G6tbw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GHiIrx7YCp8ifNnsC1qHyALcebOkMXvV31Aqb01WRJg=; b=jwxtJory/lAgU3B/nE+y6WUBEnxztr479u/vcMw3jpRBt6EsjyG3iW3AxaTmyQqB+anzDzv2ZSvQT8o3KEGNZmmYtKX98uroPuvIXSIo2YqKtX94AmiBLTWwa208luTo73ebCeZrPazhec2MxS9rsOCBUuz8Gpn184+JQ0oeulE= Received: from BYAPR00MB0565.namprd00.prod.outlook.com (20.179.56.23) by BYAPR00MB0565.namprd00.prod.outlook.com (20.179.56.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2403.0; Fri, 18 Oct 2019 22:57:37 +0000 Received: from BYAPR00MB0565.namprd00.prod.outlook.com ([fe80::4d8f:c1b3:70d4:2de4]) by BYAPR00MB0565.namprd00.prod.outlook.com ([fe80::4d8f:c1b3:70d4:2de4%5]) with mapi id 15.20.2403.000; Fri, 18 Oct 2019 22:57:36 +0000 From: Mike Jones To: Yoav Nir , "secdir@ietf.org" CC: "draft-ietf-ace-cwt-proof-of-possession.all@ietf.org" , "ietf@ietf.org" , "ace@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-ace-cwt-proof-of-possession-08 Thread-Index: AQHVfHcUHTxGfXrAZEKn6Qqm5R9W5adduhGQgANbx6A= Date: Fri, 18 Oct 2019 22:57:36 +0000 Message-ID: References: <157038789080.6563.18028321376777169887@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=5f10aac0-f5c3-403a-912c-000003962139; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-10-16T19:40:01Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.93.218] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e0ebe8fd-481e-431d-dda0-08d7541e91d8 x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: BYAPR00MB0565: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01949FE337 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(366004)(136003)(346002)(396003)(39860400002)(199004)(189003)(13464003)(64756008)(10290500003)(11346002)(14454004)(66946007)(316002)(54896002)(66556008)(2501003)(55016002)(71190400001)(6246003)(6436002)(71200400001)(10090500001)(606006)(476003)(76116006)(4326008)(446003)(99286004)(22452003)(110136005)(66574012)(478600001)(66476007)(54906003)(6306002)(9686003)(966005)(236005)(66446008)(8990500004)(486006)(5660300002)(256004)(8936002)(26005)(66066001)(52536014)(229853002)(14444005)(76176011)(74316002)(2906002)(7736002)(53546011)(6116002)(790700001)(3846002)(7696005)(33656002)(6506007)(81156014)(81166006)(8676002)(186003)(102836004)(86362001)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR00MB0565; H:BYAPR00MB0565.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: woe/DUDM5R6j/7kpdGak3uJqdF2OQeJwiQXluHqd95ltNQx5s+TeB0oQWhaXJr2RFL9iPuPnzB3zMD6jaEdH4xQWWhRnS+WA1PXl3ny68J6eHR2SORXOSpOrNIuif2ueXy9Kxo89zauJyRv7p8bvdtb00ZKL/ejiDA0PG3kmM1NgnuKMHtEDTBRmGiUC3MqtH74PPls9YwadnIN9UztfR2TTTXStr6MgmU4EZ96gSNXPyAi//+FSqxSCi9QBPPzZSPjvWma4Bti1+koiEgVMvpWM5rPE84E7Zp/E2O+PF+VuNsYX9u1GHmZjw0147BVWPOEvy34gl6sSz79kd4TgVf0NWgd3ENw8lTig6tKMfeUQPHFFuPksOepPaqidIXxxLvPVTlkDvA9QD/vK8oOlKSqbhuaogyHMiLgA3kVRvjo= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR00MB0565A4BCE00C1799451135A8F56C0BYAPR00MB0565namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: e0ebe8fd-481e-431d-dda0-08d7541e91d8 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2019 22:57:36.7356 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YtiJcnZHdphkIe8SDfuCxkNr16JVsQmSt5R7liGBa+yqtnm5IJodkMxK5Hu3eNYYMfPXW1ogFch8TAOc2ZnHvA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR00MB0565 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ace-cwt-proof-of-possession-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 22:57:48 -0000 --_000_BYAPR00MB0565A4BCE00C1799451135A8F56C0BYAPR00MB0565namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWW9hdiwNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYWNlLWN3 dC1wcm9vZi1vZi1wb3NzZXNzaW9uLTA5IGhhcyBiZWVuIHB1Ymxpc2hlZCwgd2hpY2ggYWRkcmVz c2VzIHlvdXIgcmV2aWV3IGNvbW1lbnRzIGluIHRoZSB3YXlzIHByb3Bvc2VkIGJlbG93LiAgVGhh bmtzIGFnYWluIGZvciB5b3VyIHJldmlldyENCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogTWlrZSBKb25lcw0K U2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDE2LCAyMDE5IDE6MjEgUE0NClRvOiBZb2F2IE5pciA8 eW5pci5pZXRmQGdtYWlsLmNvbT47IHNlY2RpckBpZXRmLm9yZw0KQ2M6IGRyYWZ0LWlldGYtYWNl LWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLmFsbEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgYWNl QGlldGYub3JnDQpTdWJqZWN0OiBSRTogU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQt aWV0Zi1hY2UtY3d0LXByb29mLW9mLXBvc3Nlc3Npb24tMDgNCg0KDQpUaGFua3MgYSBsb3QgZm9y IHlvdXIgcmV2aWV3LCBZb2F2LiAgUmVwbGllcyBhcmUgaW5saW5lLCBwcmVmaXhlZCBieSDigJxN aWtlPuKAneKApg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFlvYXYg TmlyIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZzxtYWlsdG86bm9yZXBseUBpZXRm Lm9yZz4+DQpTZW50OiBTdW5kYXksIE9jdG9iZXIgNiwgMjAxOSAxMTo1MiBBTQ0KVG86IHNlY2Rp ckBpZXRmLm9yZzxtYWlsdG86c2VjZGlyQGlldGYub3JnPg0KQ2M6IGRyYWZ0LWlldGYtYWNlLWN3 dC1wcm9vZi1vZi1wb3NzZXNzaW9uLmFsbEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1hY2Ut Y3d0LXByb29mLW9mLXBvc3Nlc3Npb24uYWxsQGlldGYub3JnPjsgaWV0ZkBpZXRmLm9yZzxtYWls dG86aWV0ZkBpZXRmLm9yZz47IGFjZUBpZXRmLm9yZzxtYWlsdG86YWNlQGlldGYub3JnPg0KU3Vi amVjdDogU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1hY2UtY3d0LXByb29m LW9mLXBvc3Nlc3Npb24tMDgNCg0KDQoNClJldmlld2VyOiBZb2F2IE5pcg0KDQpSZXZpZXcgcmVz dWx0OiBIYXMgTml0cw0KDQoNCg0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFy dCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcg YWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlIGNv bW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1 cml0eSBhcmVhIGRpcmVjdG9ycy4NCg0KRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNo b3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBj b21tZW50cy4NCg0KDQoNCkkgdGhpbmsgdGhlIGRvY3VtZW50IHNob3dzIHRoYXQgc2VjdXJpdHkg YXNwZWN0cyBoYXZlIGJlZW4gY29uc2lkZXJlZCBhbmQgaGFuZGxlZCB3ZWxsLiBIb3dldmVyLCB0 aGUgZG9jdW1lbnQgaGFzIGlzc3VlcyB3aXRoIGNsYXJpdHkgYW5kIHJlYWRhYmlsaXR5Og0KDQoN Cg0KRm9yIHN0YXJ0ZXJzLCB0aGUgQWJzdHJhY3QgYW5kIEludHJvZHVjdGlvbiBhcmUgbmVhcmx5 IGlkZW50aWNhbC4gVGhlIEludHJvZHVjdGlvbiBjb3VsZCBpbnN0ZWFkIGJlIHVzZWQgdG8gZXhw bGFpbiB0aGUgZG9tYWluLCB3aG8gdGhlICJwbGF5ZXJzIiBhcmUgYW5kIHdoYXQgdGhleSBhcmUg dHJ5aW5nIHRvIGFjY29tcGxpc2guIEluc3RlYWQsIHNlY3Rpb24gMiBpbnRyb2R1Y2VzIHRoZSB0 ZXJtcyBJc3N1ZXIsIFByZXNlbnRlciBhbmQgUmVjaXBpZW50IHdpdGggZGVmaW5pdGlvbnMgdGhh dCBzb3VuZCBsaWtlIHRoZSBDQSwgdGhlIEVuZCBFbnRpdHkgYW5kIHRoZSBSZWx5aW5nIFBhcnR5 IGZyb20gUEtJLCB3aXRoIGEgbGl0dGxlIE9BdXRoIHRlcm1pbm9sb2d5IG1peGVkIGluLiBUaGVy ZSBpcyBubyBleHBsYW5hdGlvbiBhYm91dCB3aG8gdGhpcyBpc3N1ZXIgaXMsIGFuZCB3aGF0IHRo ZSB0cnVzdCBtb2RlbCBpcy4NCg0KDQoNCk1pa2U+IFRoaXMgZG9jdW1lbnQgc3RydWN0dXJlIGlz IGludGVudGlvbmFsbHkgcGFyYWxsZWwgdG8gUkZDIDc4MDAuICBJbiBwYXJ0aWN1bGFyLCB0aGUg VGVybWlub2xvZ3kgc2VjdGlvbiBpcyB0aGVyZSBzcGVjaWZpY2FsbHkgdG8gaW50cm9kdWNlIHRo ZSBwbGF5ZXJzLiAgWWVzLCBlZGl0b3JpYWxseSwgdGhpcyBjb3VsZCBoYXZlIGJlZW4gZG9uZSBp biB0aGUgSW50cm9kdWN0aW9uLCBidXQgdGhpcyBpcyB0aGUgc3R5bGUgdHlwaWNhbGx5IHVzZWQg YnkgT0F1dGgsIEpPU0UsIENPU0UsIGFuZCBBQ0Ugc3BlY2lmaWNhdGlvbnMuICBJ4oCZbSByZWx1 Y3RhbnQgdG8gZGV2aWF0ZSBmcm9tIGl0IGluIHRoaXMgcGFydGljdWxhciBzcGVjaWZpY2F0aW9u IHVubGVzcyB0aGVyZeKAmXMgYSBjb21wZWxsaW5nIHJlYXNvbiB0byBkbyBzby4NCg0KDQoNCk1p a2U+IFdobyB0aGUgaXNzdWVyIGlzIGlzIGRpc2N1c3NlZCBpbiB0aGUgbGFzdCBwYXJhZ3JhcGgg b2YgU2VjdGlvbiAzLiAgVGhlIHRydXN0IG1vZGVsIGlzIGRlc2NyaWJlZCBpbiB0aGUgbGFzdCBw YXJhZ3JhcGggb2YgU2VjdGlvbiA0IChTZWN1cml0eSBDb25zaWRlcmF0aW9ucykuDQoNCg0KDQpN aWtlPiBUaGVyZWZvcmUsIHVubGVzcyB0aGVyZSBpcyBhIHNwZWNpZmljIGNoYW5nZSB0aGF0IHlv dSB3YW50IHRvIHN1Z2dlc3QsIEkgcHJvcG9zZSB0byBsZWF2ZSB0aGUgSW50cm9kdWN0aW9uIGFu ZCBUZXJtaW5vbG9neSBzZWN0aW9ucyBhcyBpcy4NCg0KDQoNClRoZSBTZWN1cml0eSBDb25zaWRl cmF0aW9ucyBzZWN0aW9uIGFsc28gaGFzIHNvbWUgcHJvYmxlbXMuICBRdW90aW5nIHRoZSBzZWNv bmQNCg0KcGFyYWdyYXBoOg0KDQogICBBcHBsaWNhdGlvbnMgdXRpbGl6aW5nIHByb29mIG9mIHBv c3Nlc3Npb24gU0hPVUxEIGFsc28gdXRpbGl6ZQ0KDQogICBhdWRpZW5jZSByZXN0cmljdGlvbiwg YXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4xLjMgb2YgW0NXVF0sIGFzIGl0DQoNCiAgIHByb3Zp ZGVzIGFkZGl0aW9uYWwgcHJvdGVjdGlvbnMuICBBdWRpZW5jZSByZXN0cmljdGlvbiBjYW4gYmUg dXNlZCBieQ0KDQogICByZWNpcGllbnRzIHRvIHJlamVjdCBtZXNzYWdlcyBpbnRlbmRlZCBmb3Ig ZGlmZmVyZW50IHJlY2lwaWVudHMuDQoNCg0KDQpXaHk/IFdoeSBpcyB0aGUgYXVkIGNsYWltIG5l ZWRlZCB3aXRoIGEgY25mIGNsYWltIChidXQgbm90IGluIG90aGVyIGNhc2VzKT8NCg0KTmVpdGhl ciB0aGlzIGRvY3VtZW50IG5vciBSRkMgODM5MiBwcm92aWRlcyBpbnNpZ2h0IGFzIHRvIHdoZW4g YXVkIGlzIGFwcHJvcHJpYXRlLiBUaGF0IHRoZXkgYWxsb3cgcmVjaXBpZW50cyB0byByZWplY3Qg bWVzc2FnZXMgbm90IGludGVuZGVkIGZvciB0aGVtIGRvZXMgbm90IHNvdW5kIGxpa2UgYSBzZWN1 cml0eSBmZWF0dXJlLg0KDQoNCg0KTWlrZT4gSGF2aW5nIGFuIGF1ZGllbmNlIGluIGEgdG9rZW4g aXMgYSBzZWN1cml0eSBmZWF0dXJlLCBhcyBpdCBwcmV2ZW50cyBhIGxlZ2l0aW1hdGUgdG9rZW4g aW50ZW5kZWQgZm9yIG9uZSByZWNpcGllbnQgZnJvbSBiZWluZyByZXBsYXllZCB0byBnYWluIGFj Y2VzcyBhdCBhIGRpZmZlcmVudCByZWNpcGllbnQuICBZb3XigJlyZSByaWdodCB0aGF0IHRoaXMg aXMgdXNlZnVsL3JlcXVpcmVkIGluIG1hbnkgc2l0dWF0aW9ucyBldmVuIHdoZW4g4oCcY25m4oCd IGlzbuKAmXQgYmVpbmcgdXNlZC4gIEhvd2V2ZXIsIHJldmlld2VycyBvZiBkcmFmdHMgb2Ygd2hh dCBiZWNhbWUgUkZDIDc4MDAgd2FudGVkIHRoaXMgdGV4dCBhZGRlZCB0byByZW1pbmQgcGVvcGxl IHRoYXQgYXVkaWVuY2UgcmVzdHJpY3Rpb24gaXMgb2Z0ZW4gdXNlZnVsIGV2ZW4gd2hlbiB5b3Ug aGF2ZSBwcm9vZiBvZiBwb3NzZXNzaW9uLCBhcyBpdCBkZWZlbmRzIGFnYWluc3QgZGlmZmVyZW50 IHRocmVhdHMuDQoNCg0KDQpNaWtlPiBUbyBtYWtlIHRoaXMgY2xlYXJlciwgSSBwcm9wb3NlIHRv IGFkZCB0aGlzIHBhcmVudGhldGljYWwgcmVtYXJrIGF0IHRoZSBlbmQgb2YgdGhpcyBwYXJhZ3Jh cGg6IOKAnChPZiBjb3Vyc2UsIGFwcGxpY2F0aW9ucyBub3QgdXNpbmcgcHJvb2Ygb2YgcG9zc2Vz c2lvbiBjYW4gYWxzbyBiZW5lZml0IGZyb20gdXNpbmcgYXVkaWVuY2UgcmVzdHJpY3Rpb24gdG8g cmVqZWN0IG1lc3NhZ2VzIGludGVuZGVkIGZvciBkaWZmZXJlbnQgcmVjaXBpZW50cy4p4oCdICBJ ZiB5b3XigJlkIHByZWZlciBkaWZmZXJlbnQgd29yZGluZywgcGxlYXNlIGxldCBtZSBrbm93IHdo YXQgaXQgaXMuDQoNCg0KDQpQYXJhZ3JhcGggMyBzYXlzOiAiQSByZWNpcGllbnQgbWlnaHQgbm90 IHVuZGVyc3RhbmQgdGhlICJjbmYiIGNsYWltLiIgICBUaGlzDQoNCnJlLWFmZmlybXMgdGhhdCB3 ZSBuZWVkIGFuIGV4cGxhbmF0aW9uIG9mIHdobyB0aGUgcGFydGllcyB0byB0aGlzIHByb3RvY29s IGFyZS4NCg0KV2UgZ2VuZXJhbGx5IGRvbid0IHNlbmQgbWVzc2FnZXMgdG8gcmVjaXBpZW50cyB0 aGF0IGRvbid0IHVuZGVyc3RhbmQgdGhlbS4gSXMgdGhpcyBhIGNsb3NlZCBzeXN0ZW0gd2l0aCBr bm93biBlbnRpdGllcywgb3IgaXMgdGhpcyBhIHByb3RvY29sIHdoZXJlIHRoZSBwYXJ0aWVzIGNv bnRhY3QgcmFuZG9tIG90aGVyIHBhcnRpZXMgb24gdGhlIEludGVybmV0Pw0KDQoNCg0KTWlrZT4g UGVyIG15IHJlc3BvbnNlIHRvIHRoZSBHZW5hcnQgcmV2aWV3LCB3ZeKAmXJlIGFscmVhZHkgcHJv cG9zaW5nIHRvIGRlbGV0ZSB0aGlzIHBhcmFncmFwaCwgYXMgaXTigJlzIG5vdCBhY3Rpb25hYmxl LiAgTm90ZSB0aGF0IHRoZSByZXF1aXJlbWVudCB0byBpZ25vcmUgbm90LXVuZGVyc3Rvb2QgY2xh aW1zIGNvbWVzIGZyb20gU2VjdGlvbiAzIG9mIFJGQyA4MzkyICh3aGljaCBhbHNvIHdhcyBpbmhl cml0ZWQgZnJvbSBSRkMgNzUxOSksIGFuZCBzbyBpcyBub3QgdW5pcXVlIHRvIHRoaXMgc3BlY2lm aWNhdGlvbi4NCg0KDQoNCk1pa2U+IFRoZSBleGFjdCBwYXJ0aWVzIHRvIHRoZSBwcm90b2NvbCBh cmUgZGVwZW5kZW50IHVwb24gdGhlIGFwcGxpY2F0aW9uLCBhcyBkaXNjdXNzZWQgaW4gdGhlIGxh c3QgcGFyYWdyYXBoIG9mIFNlY3Rpb24gNC4gIFRoaXMgc3BlY2lmaWNhdGlvbiBpcyBkZWZpbmlu ZyBQb1Aga2V5IHJlcHJlc2VudGF0aW9ucy4gIEl04oCZcyBpbnRlbnRpb25hbGx5IGxlYXZpbmcg dGhlIG1lc3NhZ2VzIGNvbnZleWluZyBDV1RzIHdpdGgg4oCcY25m4oCdIGNsYWltcyB1cCB0byB0 aGUgYXBwbGljYXRpb25zIHVzaW5nIHRoZW0uICBBZ2FpbiwgdGhpcyBpcyBpbnRlbnRpb25hbGx5 IGV4YWN0bHkgcGFyYWxsZWwgdG8gUkZDIDc4MDAuDQoNCg0KDQpJJ2QgYWxzbyBsb3NlIHNvbWUg b2YgdGhlIEludHJvZHVjdGlvbiB0byBDcnlwdG8gaW4gdGhlIHNlY29uZC10by1sYXN0IHBhcmFn cmFwaC4NCg0KDQoNCk1pa2U+IEkgYWdyZWUgdGhhdCB0aGlzIGlzIG92ZXJseSBwZWRhbnRpYy4g IEkgcHJvcG9zZSB0byBkZWxldGUgdGhlIHBhcmVudGhldGljYWwg4oCcZS5nLuKAnSBjbGF1c2Ug YXQgdGhlIGVuZCwgd2hpY2ggd2lsbCBtYWtlIGl0IG9uY2UgYWdhaW4gZXhhY3RseSBwYXJhbGxl bCB0byB0aGUgY29ycmVzcG9uZGluZyB0ZXh0IGluIFJGQyA3ODAwLiAgTGV0IG1lIGtub3cgaWYg eW914oCZZCBhIHNwZWNpZmljIGZ1cnRoZXIgY2hhbmdlIHRvIHRoaXMgcGFyYWdyYXBoLg0KDQoN Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFRoYW5rcywNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KDQo= --_000_BYAPR00MB0565A4BCE00C1799451135A8F56C0BYAPR00MB0565namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi UGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsO30NCnNwYW4uRW1haWxT dHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0Rjcy Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBZ b2F2PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wOSI+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLTA5PC9hPiBoYXMg YmVlbiBwdWJsaXNoZWQsIHdoaWNoIGFkZHJlc3NlcyB5b3VyIHJldmlldyBjb21tZW50cw0KIGlu IHRoZSB3YXlzIHByb3Bvc2VkIGJlbG93LiZuYnNwOyBUaGFua3MgYWdhaW4gZm9yIHlvdXIgcmV2 aWV3ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBNaWtlIEpvbmVzIDxicj4NCjxiPlNlbnQ6 PC9iPiBXZWRuZXNkYXksIE9jdG9iZXIgMTYsIDIwMTkgMToyMSBQTTxicj4NCjxiPlRvOjwvYj4g WW9hdiBOaXIgJmx0O3luaXIuaWV0ZkBnbWFpbC5jb20mZ3Q7OyBzZWNkaXJAaWV0Zi5vcmc8YnI+ DQo8Yj5DYzo8L2I+IGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLmFsbEBp ZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgYWNlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJFOiBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Yt b2YtcG9zc2Vzc2lvbi0wODxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+VGhhbmtzIGEgbG90IGZvciB5b3VyIHJldmlldywgWW9hdi4mbmJzcDsgUmVwbGllcyBhcmUg aW5saW5lLCBwcmVmaXhlZCBieSDigJw8c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+TWlrZSZn dDs8L3NwYW4+4oCd4oCmPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogWW9hdiBOaXIgdmlhIERhdGF0cmFja2VyICZsdDs8 YSBocmVmPSJtYWlsdG86bm9yZXBseUBpZXRmLm9yZyI+bm9yZXBseUBpZXRmLm9yZzwvYT4mZ3Q7 DQo8YnI+DQpTZW50OiBTdW5kYXksIE9jdG9iZXIgNiwgMjAxOSAxMTo1MiBBTTxicj4NClRvOiA8 YSBocmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3JnIj5zZWNkaXJAaWV0Zi5vcmc8L2E+PGJyPg0K Q2M6IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lv bi5hbGxAaWV0Zi5vcmciPmRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLmFs bEBpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86aWV0ZkBpZXRmLm9yZyI+aWV0ZkBpZXRm Lm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzphY2VAaWV0Zi5vcmciPmFjZUBpZXRmLm9yZzwvYT48 YnI+DQpTdWJqZWN0OiBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWFjZS1j d3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wODxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5S ZXZpZXdlcjogWW9hdiBOaXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PlJldmlldyByZXN1bHQ6IEhhcyBOaXRzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkg aGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVj dG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWlu ZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuJm5ic3A7IFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRl biBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9y cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkRvY3VtZW50IGVkaXRv cnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFu eSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PkkgdGhpbmsgdGhlIGRvY3VtZW50IHNob3dzIHRoYXQgc2VjdXJpdHkgYXNwZWN0cyBoYXZlIGJl ZW4gY29uc2lkZXJlZCBhbmQgaGFuZGxlZCB3ZWxsLiBIb3dldmVyLCB0aGUgZG9jdW1lbnQgaGFz IGlzc3VlcyB3aXRoIGNsYXJpdHkgYW5kIHJlYWRhYmlsaXR5OjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5Gb3Igc3RhcnRlcnMsIHRoZSBBYnN0cmFjdCBhbmQgSW50cm9kdWN0aW9uIGFy ZSBuZWFybHkgaWRlbnRpY2FsLiBUaGUgSW50cm9kdWN0aW9uIGNvdWxkIGluc3RlYWQgYmUgdXNl ZCB0byBleHBsYWluIHRoZSBkb21haW4sIHdobyB0aGUgJnF1b3Q7cGxheWVycyZxdW90OyBhcmUg YW5kIHdoYXQgdGhleSBhcmUgdHJ5aW5nIHRvIGFjY29tcGxpc2guIEluc3RlYWQsIHNlY3Rpb24g MiBpbnRyb2R1Y2VzIHRoZSB0ZXJtcyBJc3N1ZXIsDQogUHJlc2VudGVyIGFuZCBSZWNpcGllbnQg d2l0aCBkZWZpbml0aW9ucyB0aGF0IHNvdW5kIGxpa2UgdGhlIENBLCB0aGUgRW5kIEVudGl0eSBh bmQgdGhlIFJlbHlpbmcgUGFydHkgZnJvbSBQS0ksIHdpdGggYSBsaXR0bGUgT0F1dGggdGVybWlu b2xvZ3kgbWl4ZWQgaW4uIFRoZXJlIGlzIG5vIGV4cGxhbmF0aW9uIGFib3V0IHdobyB0aGlzIGlz c3VlciBpcywgYW5kIHdoYXQgdGhlIHRydXN0IG1vZGVsIGlzLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+TWlrZSZndDsgVGhpcyBkb2N1 bWVudCBzdHJ1Y3R1cmUgaXMgaW50ZW50aW9uYWxseSBwYXJhbGxlbCB0byBSRkMgNzgwMC4mbmJz cDsgSW4gcGFydGljdWxhciwgdGhlIFRlcm1pbm9sb2d5IHNlY3Rpb24gaXMgdGhlcmUgc3BlY2lm aWNhbGx5IHRvIGludHJvZHVjZSB0aGUgcGxheWVycy4mbmJzcDsgWWVzLCBlZGl0b3JpYWxseSwg dGhpcyBjb3VsZCBoYXZlIGJlZW4gZG9uZSBpbg0KIHRoZSBJbnRyb2R1Y3Rpb24sIGJ1dCB0aGlz IGlzIHRoZSBzdHlsZSB0eXBpY2FsbHkgdXNlZCBieSBPQXV0aCwgSk9TRSwgQ09TRSwgYW5kIEFD RSBzcGVjaWZpY2F0aW9ucy4mbmJzcDsgSeKAmW0gcmVsdWN0YW50IHRvIGRldmlhdGUgZnJvbSBp dCBpbiB0aGlzIHBhcnRpY3VsYXIgc3BlY2lmaWNhdGlvbiB1bmxlc3MgdGhlcmXigJlzIGEgY29t cGVsbGluZyByZWFzb24gdG8gZG8gc28uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjojMDBCMDUwIj5NaWtlJmd0OyBXaG8gdGhlIGlzc3VlciBpcyBpcyBkaXNjdXNzZWQgaW4gdGhl IGxhc3QgcGFyYWdyYXBoIG9mIFNlY3Rpb24gMy4mbmJzcDsgVGhlIHRydXN0IG1vZGVsIGlzIGRl c2NyaWJlZCBpbiB0aGUgbGFzdCBwYXJhZ3JhcGggb2YgU2VjdGlvbiA0IChTZWN1cml0eSBDb25z aWRlcmF0aW9ucykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5N aWtlJmd0OyBUaGVyZWZvcmUsIHVubGVzcyB0aGVyZSBpcyBhIHNwZWNpZmljIGNoYW5nZSB0aGF0 IHlvdSB3YW50IHRvIHN1Z2dlc3QsIEkgcHJvcG9zZSB0byBsZWF2ZSB0aGUgSW50cm9kdWN0aW9u IGFuZCBUZXJtaW5vbG9neSBzZWN0aW9ucyBhcyBpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIGFsc28gaGFzIHNvbWUgcHJvYmxlbXMuJm5ic3A7IFF1 b3RpbmcgdGhlIHNlY29uZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ cGFyYWdyYXBoOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7IEFwcGxpY2F0aW9ucyB1dGlsaXppbmcgcHJvb2Ygb2YgcG9zc2Vzc2lvbiBTSE9VTEQg YWxzbyB1dGlsaXplPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsgYXVkaWVuY2UgcmVzdHJpY3Rpb24sIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMu MS4zIG9mIFtDV1RdLCBhcyBpdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7IHByb3ZpZGVzIGFkZGl0aW9uYWwgcHJvdGVjdGlvbnMuJm5ic3A7IEF1 ZGllbmNlIHJlc3RyaWN0aW9uIGNhbiBiZSB1c2VkIGJ5PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsgJm5ic3A7cmVjaXBpZW50cyB0byByZWplY3QgbWVzc2Fn ZXMgaW50ZW5kZWQgZm9yIGRpZmZlcmVudCByZWNpcGllbnRzLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5XaHk/IFdoeSBpcyB0aGUgYXVkIGNsYWltIG5lZWRlZCB3aXRoIGEgY25mIGNs YWltIChidXQgbm90IGluIG90aGVyIGNhc2VzKT8NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+TmVpdGhlciB0aGlzIGRvY3VtZW50IG5vciBSRkMgODM5MiBwcm92aWRl cyBpbnNpZ2h0IGFzIHRvIHdoZW4gYXVkIGlzIGFwcHJvcHJpYXRlLiBUaGF0IHRoZXkgYWxsb3cg cmVjaXBpZW50cyB0byByZWplY3QgbWVzc2FnZXMgbm90IGludGVuZGVkIGZvciB0aGVtIGRvZXMg bm90IHNvdW5kIGxpa2UgYSBzZWN1cml0eSBmZWF0dXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+TWlrZSZndDsgSGF2aW5nIGFuIGF1 ZGllbmNlIGluIGEgdG9rZW4gaXMgYSBzZWN1cml0eSBmZWF0dXJlLCBhcyBpdCBwcmV2ZW50cyBh IGxlZ2l0aW1hdGUgdG9rZW4gaW50ZW5kZWQgZm9yIG9uZSByZWNpcGllbnQgZnJvbSBiZWluZyBy ZXBsYXllZCB0byBnYWluIGFjY2VzcyBhdCBhIGRpZmZlcmVudCByZWNpcGllbnQuJm5ic3A7IFlv deKAmXJlIHJpZ2h0IHRoYXQgdGhpcw0KIGlzIHVzZWZ1bC9yZXF1aXJlZCBpbiBtYW55IHNpdHVh dGlvbnMgZXZlbiB3aGVuIOKAnGNuZuKAnSBpc27igJl0IGJlaW5nIHVzZWQuJm5ic3A7IEhvd2V2 ZXIsIHJldmlld2VycyBvZiBkcmFmdHMgb2Ygd2hhdCBiZWNhbWUgUkZDIDc4MDAgd2FudGVkIHRo aXMgdGV4dCBhZGRlZCB0byByZW1pbmQgcGVvcGxlIHRoYXQgYXVkaWVuY2UgcmVzdHJpY3Rpb24g aXMgb2Z0ZW4gdXNlZnVsIGV2ZW4gd2hlbiB5b3UgaGF2ZSBwcm9vZiBvZiBwb3NzZXNzaW9uLCBh cyBpdCBkZWZlbmRzDQogYWdhaW5zdCBkaWZmZXJlbnQgdGhyZWF0cy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1 MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPk1pa2UmZ3Q7IFRvIG1ha2UgdGhpcyBjbGVhcmVy LCBJIHByb3Bvc2UgdG8gYWRkIHRoaXMgcGFyZW50aGV0aWNhbCByZW1hcmsgYXQgdGhlIGVuZCBv ZiB0aGlzIHBhcmFncmFwaDog4oCcKE9mIGNvdXJzZSwgYXBwbGljYXRpb25zIG5vdCB1c2luZyBw cm9vZiBvZiBwb3NzZXNzaW9uIGNhbiBhbHNvIGJlbmVmaXQgZnJvbSB1c2luZyBhdWRpZW5jZSBy ZXN0cmljdGlvbg0KIHRvIHJlamVjdCBtZXNzYWdlcyBpbnRlbmRlZCBmb3IgZGlmZmVyZW50IHJl Y2lwaWVudHMuKeKAnSZuYnNwOyBJZiB5b3XigJlkIHByZWZlciBkaWZmZXJlbnQgd29yZGluZywg cGxlYXNlIGxldCBtZSBrbm93IHdoYXQgaXQgaXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5QYXJhZ3JhcGggMyBzYXlzOiAmcXVvdDtBIHJlY2lwaWVudCBtaWdodCBub3Qg dW5kZXJzdGFuZCB0aGUgJnF1b3Q7Y25mJnF1b3Q7IGNsYWltLiZxdW90OyZuYnNwOyZuYnNwOyBU aGlzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5yZS1hZmZpcm1zIHRo YXQgd2UgbmVlZCBhbiBleHBsYW5hdGlvbiBvZiB3aG8gdGhlIHBhcnRpZXMgdG8gdGhpcyBwcm90 b2NvbCBhcmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5XZSBnZW5l cmFsbHkgZG9uJ3Qgc2VuZCBtZXNzYWdlcyB0byByZWNpcGllbnRzIHRoYXQgZG9uJ3QgdW5kZXJz dGFuZCB0aGVtLiBJcyB0aGlzIGEgY2xvc2VkIHN5c3RlbSB3aXRoIGtub3duIGVudGl0aWVzLCBv ciBpcyB0aGlzIGEgcHJvdG9jb2wgd2hlcmUgdGhlIHBhcnRpZXMgY29udGFjdCByYW5kb20gb3Ro ZXIgcGFydGllcyBvbiB0aGUgSW50ZXJuZXQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MEIwNTAiPk1pa2UmZ3Q7IFBlciBteSByZXNwb25zZSB0byB0aGUgR2VuYXJ0IHJldmlldywgd2Xi gJlyZSBhbHJlYWR5IHByb3Bvc2luZyB0byBkZWxldGUgdGhpcyBwYXJhZ3JhcGgsIGFzIGl04oCZ cyBub3QgYWN0aW9uYWJsZS4mbmJzcDsgTm90ZSB0aGF0IHRoZSByZXF1aXJlbWVudCB0byBpZ25v cmUgbm90LXVuZGVyc3Rvb2QgY2xhaW1zIGNvbWVzIGZyb20gU2VjdGlvbiAzIG9mIFJGQw0KIDgz OTIgKHdoaWNoIGFsc28gd2FzIGluaGVyaXRlZCBmcm9tIFJGQyA3NTE5KSwgYW5kIHNvIGlzIG5v dCB1bmlxdWUgdG8gdGhpcyBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iY29sb3I6IzAwQjA1MCI+TWlrZSZndDsgVGhlIGV4YWN0IHBhcnRpZXMgdG8gdGhlIHByb3Rv Y29sIGFyZSBkZXBlbmRlbnQgdXBvbiB0aGUgYXBwbGljYXRpb24sIGFzIGRpc2N1c3NlZCBpbiB0 aGUgbGFzdCBwYXJhZ3JhcGggb2YgU2VjdGlvbiA0LiZuYnNwOyBUaGlzIHNwZWNpZmljYXRpb24g aXMgZGVmaW5pbmcgUG9QIGtleSByZXByZXNlbnRhdGlvbnMuJm5ic3A7IEl04oCZcyBpbnRlbnRp b25hbGx5IGxlYXZpbmcNCiB0aGUgbWVzc2FnZXMgY29udmV5aW5nIENXVHMgd2l0aCDigJxjbmbi gJ0gY2xhaW1zIHVwIHRvIHRoZSBhcHBsaWNhdGlvbnMgdXNpbmcgdGhlbS4mbmJzcDsgQWdhaW4s IHRoaXMgaXMgaW50ZW50aW9uYWxseSBleGFjdGx5IHBhcmFsbGVsIHRvIFJGQyA3ODAwLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSdkIGFsc28gbG9zZSBzb21lIG9mIHRo ZSBJbnRyb2R1Y3Rpb24gdG8gQ3J5cHRvIGluIHRoZSBzZWNvbmQtdG8tbGFzdCBwYXJhZ3JhcGgu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUw Ij5NaWtlJmd0OyBJIGFncmVlIHRoYXQgdGhpcyBpcyBvdmVybHkgcGVkYW50aWMuJm5ic3A7IEkg cHJvcG9zZSB0byBkZWxldGUgdGhlIHBhcmVudGhldGljYWwg4oCcZS5nLuKAnSBjbGF1c2UgYXQg dGhlIGVuZCwgd2hpY2ggd2lsbCBtYWtlIGl0IG9uY2UgYWdhaW4gZXhhY3RseSBwYXJhbGxlbCB0 byB0aGUgY29ycmVzcG9uZGluZyB0ZXh0IGluIFJGQyA3ODAwLiZuYnNwOyBMZXQgbWUga25vdw0K IGlmIHlvdeKAmWQgYSBzcGVjaWZpYyBmdXJ0aGVyIGNoYW5nZSB0byB0aGlzIHBhcmFncmFwaC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iY29sb3I6IzAwQjA1MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BYAPR00MB0565A4BCE00C1799451135A8F56C0BYAPR00MB0565namp_-- From nobody Mon Oct 21 04:49:27 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8921E120110; Mon, 21 Oct 2019 04:49:13 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 ClOHCH3A9NSZ; Mon, 21 Oct 2019 04:49:10 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 5F76E120073; Mon, 21 Oct 2019 04:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1571658549; d=isode.com; s=june2016; i=@isode.com; bh=BoNaTl9v/GWDnThrCyAE+J5fGT9w6l3JyI4L1Lw/ZOU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=gn2AlnHSELma7/nA18rH4sAtCPvBb2wK39MAiZkHQnGyNgK2eM/GJgjiYCobeNtIpLjyK1 lsBlvS1jGGyaAdiiYF9W/kDSTs8+yPvIMQQ+E6JS5nwgipdEV1sONug8urTlf+jYS3NPxX mlo3TA9p/RVdwAyktZH4APsZD+ojUSs=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 21 Oct 2019 12:49:09 +0100 To: Daniel Migault , Adam Roach , secdir@ietf.org Cc: IPsecME WG , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-implicit-iv@ietf.org, The IESG References: <157119428147.28057.3364707659942003352.idtracker@ietfa.amsl.com> From: Alexey Melnikov Message-ID: Date: Mon, 21 Oct 2019 12:48:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------61EAFEF949E1759879E2684A" Content-Language: en-GB Archived-At: Subject: Re: [secdir] [IPsec] Adam Roach's Yes on draft-ietf-ipsecme-implicit-iv-07: (with COMMENT) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 11:49:14 -0000 --------------61EAFEF949E1759879E2684A Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi Daniel, On 17/10/2019 15:05, Daniel Migault wrote: > Hi, > > Just to make everyone aware, we have issued a new version that we hope=20 > addresses all concerns. > https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-08 Thank you for posting -08 and -09. I just need one more change: IANA pointed out that you removed the name=20 of the registry from the IANA Considerations section. You should add it=20 back, as not having it in the document is confusing. Thank you, Alexey > Yours, > Daniel > > On Tue, Oct 15, 2019 at 11:07 PM Daniel Migault=20 > > wrote: > > Hi Adam, > > Thanks for the feed back. All your comments have been fixed on the > current local version available at: > https://github.com/mglt/draft-mglt-ipsecme-implicit-iv/blob/master/dra= ft-ietf-ipsecme-implicit-iv.txt > > We expect to publish the version tomorrow. > > Yours, > Daniel > > > > On Tue, Oct 15, 2019 at 10:51 PM Adam Roach via Datatracker > > wrote: > > Adam Roach has entered the following ballot position for > draft-ietf-ipsecme-implicit-iv-07: Yes > > When responding, please keep the subject line intact and reply > to all > email addresses included in the To and CC lines. (Feel free to > cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found > here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ > > > > ------------------------------------------------------------------= ---- > COMMENT: > ------------------------------------------------------------------= ---- > > Thanks for the work on this mechanism. I have no substantive > comments > beyond those that have already been shared, although I do have > some > minor editorial comments. > > ------------------------------------------------------------------= --------- > > =C2=A72: > > >=C2=A0 In some context, such as IoT, it may be preferable to avoi= d > carrying > > Nit: "...some contexts..." > > Fixed > > ------------------------------------------------------------------= --------- > > =C2=A75: > > >=C2=A0 An initiator supporting this feature SHOULD propose implic= it IV > >=C2=A0 algorithms in the Transform Type 1 (Encryption Algorithm) > >=C2=A0 Substructure of the Proposal Substructure inside the SA > Payload. > > Please expand "SA" on first use. > > Fixed > > ------------------------------------------------------------------= --------- > > > 7.=C2=A0 Security Consideration > > Nit: "Considerations" > > Fixed > > > ------------------------------------------------------------------= --------- > > =C2=A77: > > >=C2=A0 extensions ([RFC6311], [RFC7383]) do allow it to repeat, s= o > there is > >=C2=A0 no an easy way to derive unique IV from IKEv2 header field= s. > > Nit: "...not an easy way..." > > Fixed > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --------------61EAFEF949E1759879E2684A Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

    Hi Daniel,

    On 17/10/2019 15:05, Daniel Migault wrote:
    Hi,=C2=A0

    Just to make everyone aware, we have issued a new version that we hope addresses all concerns.=C2=A0

    Thank you for posting -08 and -09.

    I just need one more change: IANA pointed out that you removed the name of the registry from the IANA Considerations section. You should add it back, as not having it in the document is confusing.

    Thank you,

    Alexey

    Yours,=C2=A0
    Daniel

    On Tue, Oct 15, 2019 at 11:07 PM Daniel Migault <daniel.migault@ericsson.com> wrote:
    Hi Adam,=C2=A0

    Thanks for the feed back. All your comments have been fixed on the current local version available at:

    We expect to publish the version tomorrow.

    Yours,=C2=A0
    Daniel



    On Tue, Oct 15, 2019 at 10:51 PM Adam Roach via Datatracker <noreply@ietf.org> wrote:
    Adam Roach has entered the following ballot position for
    draft-ietf-ipsecme-implicit-iv-07: Yes

    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)


    Please refer to https://www.ietf.org/iesg/stateme= nt/discuss-criteria.html
    for more information about IESG DISCUSS and COMMENT positions.


    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/= draft-ietf-ipsecme-implicit-iv/



    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

    Thanks for the work on this mechanism. I have no substantive comments
    beyond those that have already been shared, although I do have some
    minor editorial comments.

    ---------------------------------------------------------------------------<= br>
    =C2=A72:

    >=C2=A0 In some context, such as IoT, it may be preferabl= e to avoid carrying

    Nit: "...some contexts..."

    Fixed=C2=A0
    ---------------------------------------------------------------------------<= br>
    =C2=A75:

    >=C2=A0 An initiator supporting this feature SHOULD propose implicit IV
    >=C2=A0 algorithms in the Transform Type 1 (Encryption Algorithm)
    >=C2=A0 Substructure of the Proposal Substructure inside the SA Payload.

    Please expand "SA" on first use.

    Fixed=C2=A0
    ---------------------------------------------------------------------------<= br>
    > 7.=C2=A0 Security Consideration

    Nit: "Considerations"
    Fixed=C2=A0

    ---------------------------------------------------------------------------<= br>
    =C2=A77:

    >=C2=A0 extensions ([RFC6311], [RFC7383]) do allow it to repeat, so there is
    >=C2=A0 no an easy way to derive unique IV from IKEv2 header fields.

    Nit: "...not an easy way..."
    Fixed=C2=A0


    _______________________________________________
    IPsec mailing list
    IPsec@ietf.org
    https://www.ietf.org/mailman/list= info/ipsec

    _______________________________=
________________
secdir mailing list
secdir=
@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirR=
eview
    --------------61EAFEF949E1759879E2684A-- From nobody Mon Oct 21 05:47:21 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BFE12013B; Mon, 21 Oct 2019 05:47:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Vincent Roca via Datatracker To: Cc: draft-ietf-dmm-pmipv6-dlif.all@ietf.org, ietf@ietf.org, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.106.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Vincent Roca Message-ID: <157166202760.31949.6972305880517491481@ietfa.amsl.com> Date: Mon, 21 Oct 2019 05:47:07 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dmm-pmipv6-dlif-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 12:47:08 -0000 Reviewer: Vincent Roca Review result: Has Nits Hello, I have reviewed this document as part of the security directorate’s ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Almost ready / has nits RFC4832 is a nice document that explains in detail security threats for the class of mobility management protocol PMIPv6 belongs to. It is referenced by RFC5213 which itself is referenced by the current document. Therefore I think that an interested reader can find the requiered information. However, the small text of section 6 that refers to RFC5213 and updates a few sentences to apply RFC5213 recommendations to MAARs, is misleading in my opinion. It suggests there is a single threat, the impersonation of a MAAR, and since using IPsec eliminates this threat, a reader can easily conclude there's nothing else. But what about the other benefits of using IPsec? Is the use of IPsec only for endpoint authentication (what I understand)? What about anti-replay, integrity, confidentiality? Is it meaningless in the present context? By the way, what is the attacker model? The subject is too complex, the risks are too varied, and I don't like this way of presenting things that overly simplifies the problems. Clarification on a different topic: This is a detail, but the document refers to the S-MAAR's global address or P-MAAR's global address as if there was a necessarily a single address. What happens if a MAAR has multiple global addresses? It may happen with a router that is multiply connected to the Internet. Cheers. Vincent From nobody Mon Oct 21 12:30:39 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E55612086C; Mon, 21 Oct 2019 12:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjDTQwaJ5OCq; Mon, 21 Oct 2019 12:30:26 -0700 (PDT) Received: from mail-vs1-f65.google.com (mail-vs1-f65.google.com [209.85.217.65]) (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 A9DF71208B8; Mon, 21 Oct 2019 12:30:25 -0700 (PDT) Received: by mail-vs1-f65.google.com with SMTP id v19so9684561vsv.3; Mon, 21 Oct 2019 12:30:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Drs9YQIPcb6crNlgYPNih2kiFPiuBKFxKfjUn0iEIK8=; b=Gy7/za9YBDIR1DFo6vj+bKcUW80A0vak8TtUkY/2lVMTyrJxTzePF5FQV0A/xSbZ4K Di76mtxmOHU/8UqymcnumMCXoOiQmDSX7Km4W5oezGpjJN48DjoANsjpRLIls1522Ehh M2aiB+9QaPsg2SobZoiqDQa1iJlkIjTjf20SSNcY7J0Xh6DtYmnWDCiPqKT5mUqE803Z hzomYh5YzqDPKlU7p4TYI/LvGnZtGNWHCFxJ6HkEpwEcdZij24fTxdClJLjZnypQgyky f2nFMvwIcYP7kNYMq0s8aJz6oSCV5NbfrfYRM9jk1jl1oZe9+cX6+gfz6pTSRxUkYGRG 988A== X-Gm-Message-State: APjAAAUYT5qPDgyHKWOboaEkBzGVAlsuAExvhAYWXivTwNaJL18XYgXv 6N/gZ1gyFoTTsxinAsU8L0L1MGn87xWPTHU9JKeJcOB4UWo= X-Google-Smtp-Source: APXvYqzvkF5re67UyMGTIG+/zPERnNlEoy0IglN7TZEwsMczfsptUMLKYAwk1bhmM/nAWf2sMQCzAd22w/8vVevC/qE= X-Received: by 2002:a67:e88b:: with SMTP id x11mr14296897vsn.180.1571686224552; Mon, 21 Oct 2019 12:30:24 -0700 (PDT) MIME-Version: 1.0 References: <157119428147.28057.3364707659942003352.idtracker@ietfa.amsl.com> In-Reply-To: From: Daniel Migault Date: Mon, 21 Oct 2019 15:30:13 -0400 Message-ID: To: Alexey Melnikov Cc: Daniel Migault , Adam Roach , secdir@ietf.org, IPsecME WG , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-implicit-iv@ietf.org, The IESG Content-Type: multipart/alternative; boundary="0000000000001ce8b1059570b77c" Archived-At: Subject: Re: [secdir] [IPsec] Adam Roach's Yes on draft-ietf-ipsecme-implicit-iv-07: (with COMMENT) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 19:30:37 -0000 --0000000000001ce8b1059570b77c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Alexey, I just posted a new version with the following text: """ The IANA has assigned the following code points to the registry Transform Type 1 - Encryption Algorithm Transform IDs [IANA]: """ Yours, Daniel On Mon, Oct 21, 2019 at 7:49 AM Alexey Melnikov wrote: > Hi Daniel, > On 17/10/2019 15:05, Daniel Migault wrote: > > Hi, > > Just to make everyone aware, we have issued a new version that we hope > addresses all concerns. > https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-08 > > Thank you for posting -08 and -09. > > I just need one more change: IANA pointed out that you removed the name o= f > the registry from the IANA Considerations section. You should add it back= , > as not having it in the document is confusing. > > Thank you, > > Alexey > > Yours, > Daniel > > On Tue, Oct 15, 2019 at 11:07 PM Daniel Migault < > daniel.migault@ericsson.com> wrote: > >> Hi Adam, >> >> Thanks for the feed back. All your comments have been fixed on the >> current local version available at: >> >> https://github.com/mglt/draft-mglt-ipsecme-implicit-iv/blob/master/draft= -ietf-ipsecme-implicit-iv.txt >> >> We expect to publish the version tomorrow. >> >> Yours, >> Daniel >> >> >> >> On Tue, Oct 15, 2019 at 10:51 PM Adam Roach via Datatracker < >> noreply@ietf.org> wrote: >> >>> Adam Roach has entered the following ballot position for >>> draft-ietf-ipsecme-implicit-iv-07: Yes >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to >>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> Thanks for the work on this mechanism. I have no substantive comments >>> beyond those that have already been shared, although I do have some >>> minor editorial comments. >>> >>> >>> -----------------------------------------------------------------------= ---- >>> >>> =C2=A72: >>> >>> > In some context, such as IoT, it may be preferable to avoid carrying >>> >>> Nit: "...some contexts..." >>> >>> Fixed >> >>> >>> -----------------------------------------------------------------------= ---- >>> >>> =C2=A75: >>> >>> > An initiator supporting this feature SHOULD propose implicit IV >>> > algorithms in the Transform Type 1 (Encryption Algorithm) >>> > Substructure of the Proposal Substructure inside the SA Payload. >>> >>> Please expand "SA" on first use. >>> >>> Fixed >> >>> >>> -----------------------------------------------------------------------= ---- >>> >>> > 7. Security Consideration >>> >>> Nit: "Considerations" >>> >> Fixed >> >>> >>> >>> -----------------------------------------------------------------------= ---- >>> >>> =C2=A77: >>> >>> > extensions ([RFC6311], [RFC7383]) do allow it to repeat, so there is >>> > no an easy way to derive unique IV from IKEv2 header fields. >>> >>> Nit: "...not an easy way..." >>> >> Fixed >> >>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >> > _______________________________________________ > secdir mailing listsecdir@ietf.orghttps://www.ietf.org/mailman/listinfo/s= ecdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --0000000000001ce8b1059570b77c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thanks Alexey,=C2=A0

    I just posted a ne= w version with the following text:

    ""&qu= ot;
    =C2=A0 =C2=A0The IANA has assigned the following code points = to the registry
    =C2=A0 =C2=A0Transform Type 1 - Encryption Algorithm Tra= nsform IDs [IANA]:

    """=C2=A0
    Yours,=C2=A0
    Daniel

    On Mon, Oct 21, 2019 at 7:49 AM Ale= xey Melnikov <alexey.melnik= ov@isode.com> wrote:
    =20 =20 =20

    Hi Daniel,

    On 17/10/2019 15:05, Daniel Migault wrote:
    =20
    Hi,=C2=A0

    Just to make everyone aware, we have issued a new version that we hope addresses all concerns.=C2=A0

    Thank you for posting -08 and -09.

    I just need one more change: IANA pointed out that you removed the name of the registry from the IANA Considerations section. You should add it back, as not having it in the document is confusing.

    Thank you,

    Alexey

    Yours,=C2=A0
    Daniel

    On Tue, Oct 15, 2019 at 11:07 PM Daniel Migault <daniel.migault@ericsson.com> wrote:
    Hi Adam,=C2=A0

    Thanks for the feed back. All your comments have been fixed on the current local version available at:

    We expect to publish the version tomorrow.

    Yours,=C2=A0
    Daniel



    On Tue, Oct 15, 2019 at 10:51 PM Adam Roach via Datatracker <noreply@ietf.org> wrote:
    Adam Roach = has entered the following ballot position for
    draft-ietf-ipsecme-implicit-iv-07: Yes

    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)


    Please refer to https://www= .ietf.org/iesg/statement/discuss-criteria.html
    for more information about IESG DISCUSS and COMMENT positions.


    The document, along with other ballot positions, can be found here:
    https://datatracker.= ietf.org/doc/draft-ietf-ipsecme-implicit-iv/



    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

    Thanks for the work on this mechanism. I have no substantive comments
    beyond those that have already been shared, although I do have some
    minor editorial comments.

    ---------------------------------------------------------------------------=

    =C2=A72:

    >=C2=A0 In some context, such as IoT, it may be preferab= le to avoid carrying

    Nit: "...some contexts..."

    Fixed=C2=A0
    ---------------------------------------------------------------------------=

    =C2=A75:

    >=C2=A0 An initiator supporting this feature SHOULD propose implicit IV
    >=C2=A0 algorithms in the Transform Type 1 (Encryption Algorithm)
    >=C2=A0 Substructure of the Proposal Substructure inside the SA Payload.

    Please expand "SA" on first use.

    Fixed=C2=A0
    ---------------------------------------------------------------------------=

    > 7.=C2=A0 Security Consideration

    Nit: "Considerations"
    Fixed=C2=A0

    ---------------------------------------------------------------------------=

    =C2=A77:

    >=C2=A0 extensions ([RFC6311], [RFC7383]) do allow it to repeat, so there is
    >=C2=A0 no an easy way to derive unique IV from IKEv2 header fields.

    Nit: "...not an easy way..."
    Fixed=C2=A0


    _______________________________________________
    IPsec mailing list
    IPsec@i= etf.org
    https://www.ietf.org/mailman/listinfo/ips= ec

    _______________________________________________
secdir mailing list
secdir@ietf.org
=
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
    _______________________________________________
    IPsec mailing list
    IPsec@ietf.org
    https://www.ietf.org/mailman/listinfo/ipsec
    --0000000000001ce8b1059570b77c-- From nobody Tue Oct 22 00:21:20 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B7612004F; Tue, 22 Oct 2019 00:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smyslov.net 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 6-2TkSTO9Hut; Tue, 22 Oct 2019 00:21:05 -0700 (PDT) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (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 CF51212002F; Tue, 22 Oct 2019 00:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:Cc:To:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=eB6Xf/vg+EdWUhR97Dm96pijyYqx7PqtzwH8TrYxBPY=; b=ACU80qcJfp1wwTcUNRLeOwHNdv uGdEyyogad7mqJkcgWcHnNChe9vFZMpSpxiCl2HDzBC+M8wxBxHjQEnzYFj5TUmhBCxSVOANtvzAF 7OEZCQxAxmzJoa1pL3f8vIVhb1odStBnNX87UfrAET2F7zflsxhVwD8ng4LVGEeM4nfa8M5A973aR ahpBitb7NdkLjLQazUYKnSzMb+TtLcL+o04M2OHwG7jxZ00ZYijgsP2TvPYXIMg6abkPjys4kUNOd ZZJjPCQ5hHa1QYUu9IK0EGXpaiy4ZdAooEoJpmxTpARvH8xbLebXXTlqJg+EppIA7mucoc81caZo6 0dGDQPgw==; Received: from [82.138.51.4] (port=58649 helo=buildpc) by direct.host-care.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.92) (envelope-from ) id 1iMoTT-0007yX-Uw; Tue, 22 Oct 2019 03:21:00 -0400 From: "Valery Smyslov" To: Cc: , , Date: Tue, 22 Oct 2019 10:20:58 +0300 Message-ID: <050d01d588a9$41b06ef0$c5114cd0$@smyslov.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdWIpdf2A1a6Eq92S7mADJGdYNFbGw== Content-Language: ru X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [secdir] Secdir Last Call review of draft-ietf-core-senml-more-units X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2019 07:21:07 -0000 Reviewer: Valery Smyslov Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is a short document that defines additional measurement units and subunits to be used in SenML (RFC8428). As such the primary purpose of the document is to request IANA to update "SenML Units" registry and to create a new one - a "secondary units" sub-registry. The document doesn't define any actual protocol. The Security Considerations section refers to RFC8428, since introduction of new measurement units is believed to not bring any new security implications. Nit (not related to security). In para: SenML packs MAY, but SHOULD NOT, use secondary units in place of SenML units, where the exception of the "SHOULD NOT" lies in the context of specific existing data models that are based on these secondary units. I think that uppercase "MAY" is redundant here, because using "SHOULD NOT" always assumes that there may be exceptions. From nobody Tue Oct 22 08:05:53 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9673F120859; Tue, 22 Oct 2019 08:05:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks via Datatracker To: Cc: last-call@ietf.org, draft-ietf-cose-hash-sig.all@ietf.org, cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.107.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Sparks Message-ID: <157175673652.3089.14383037666901135010@ietfa.amsl.com> Date: Tue, 22 Oct 2019 08:05:36 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-cose-hash-sig-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2019 15:05:44 -0000 Reviewer: Robert Sparks Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is ready for publication as Proposed Standard RFC. This document specifies conventions for using the HSS/MLS hash-based signature algorithm with COSE. It is straightforward, but relies strongly on its normative references. It adds entries to two registries. From nobody Tue Oct 22 12:54:44 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA84B1200D6; Tue, 22 Oct 2019 12:54:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Derrell Piper via Datatracker To: Cc: nfsv4@ietf.org, draft-ietf-nfsv4-rpc-tls.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.107.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Derrell Piper Message-ID: <157177407766.13058.11570408881931663610@ietfa.amsl.com> Date: Tue, 22 Oct 2019 12:54:37 -0700 Archived-At: Subject: [secdir] Secdir early review of draft-ietf-nfsv4-rpc-tls-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2019 19:54:38 -0000 Reviewer: Derrell Piper Review result: Not Ready Reviewer: Derrell Piper Review result: Not Ready I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents entering the IESG. These comments are directed at the security area director(s). Document editors and WG chairs should treat these comments like any other last call comments. This draft is entitled, "Remote Procedure Call Encryption by Default", except it does not define this. It instead discusses opportunistic RPC encryption using TLS (DTLS), encryption that might be used if the sun, moon, and stars align, and likely only if you're running one of two NFS implementations mentioned in this draft, which exclude most existing NFS servers on the Internet today and is incompatible with Linux (pp. 13). To some extent, this draft simply defines a new enum in ONC RPC, named AUTH_TLS. It completely handwaves all code changes in RPC and NFS to support TLS, PKI, GSS-API, or DNSSEC. It contains no pseudocode, just RFC2119 MUST, MAYs, and SHOULDs. pp. 5, Discovery "The mechanism described in this document interoperates fully with RPC implementations that do not support TLS. The use of TLS is automatically disabled in these cases." Hence, Not Ready. I have great sympathy for wanting to try to make it possible to use TLS by default in new NFS servers that support it, however even then, I think this draft falls short. It seems self-contradictory at times, and seems to continue to default to off, not on, which is exactly what RFC7258 says we ought not be doing anymore. Or maybe it doesn't intend to say this, since Token binding and TLSA are mentioned in Security Considerations, but optional, so it kinda does. So, defer to the ADs. pp. 6, Discovery "Once the TLS handshake is complete, the RPC client and server will have established a secure channel for communicating. The client MUST switch to a security flavor other than AUTH_TLS within that channel, presumably after negotiating down redundant RPCSEC_GSS privacy and integrity services and applying channel binding." What are the code changes? GSS-API is subtle, please explain. Are there really no TLS or DTLS changes for any of this? pp. 6, Discovery, STARTTLS discussion ONC RPC person needed. The AUTH_NONE and NULL RPC text is of concern. pp. 7, Authentication "If authentication of either peer fails, or if authorization based on those identities blocks access to the server, the client association SHOULD be rejected." MUST be rejected. pp. 7, Authentication "Once a TLS session is established, the server MUST NOT utilize the client peer's TLS identity for the purpose of authorizing individual RPC requests." That's a curious statement to end a section on Authentication with. At least justify that statement. pp. 8, TLS Requirements "Support for TLS-PSK mutual authentication [RFC4279] is OPTIONAL." Considering this is retrofit security for a legacy UNIX UID/GID protocol, making PSKs OPTIONAL almost seems quaint here, but okay. pp. 8, TLS Requirements "Support for and negotiation of compression is OPTIONAL." Noted. pp. 9, Operation on Other Transports "Transports that provide intrinsic TLS-level security (e.g. QUIC) would need to be accomodated separatey from the current document. In such cases, use of TLS might not be opportunistic as it is for TCP or UDP." "opportunitic" is misspelled, and I don't know what to make of this sentence, but I have very partisan views on QUIC, so defer to the ADs. I assume Section 5.1.3 is there for RDMA but it doesn't say anything. pp. 11, X.509 Certificates Using Fingerprints "Implementations MUST support SHA-1 as the hash algorithm for the fingerprint. To prevent attacks based on hash collisions, support for a more contemporary hash function, such as SHA-256, is RECOMMENDED." SHA-1's deprecated, right? So we shoudn't be mandating SHA-1 in new RFCs, right? Defer to AD. pp. 11 Pre-Shared Keys "should be exposed" -> "SHOULD be exposed" pp. 12, DESY, Hammerspace, and Linux Why are these two implementations called out? This section does not give me confidence that this all interoperates, is it supposed to? pp. 13, Security Considerations Since absolute compatibilty with fielded insecure NFS is stated as a requirement, the obvious downgrade attack is not only permitted, but required. Again, RFC7258 says that's no longer acceptable, doesn't it? nAgain, defer to the ADs. "Implementations must take care to accurately represent to all RPC consumers the level of security that is actually in effect." How? pp. 14, Security Considerations for AUTH_SYS on TLS "In light of the above, it is RECOMMENDED that when AUTH_SYS is used, RPC clients present authentication material necessary for RPC servers they contact to have a degree of trust that the clients are acting responsibly." Hence, "if the sun, moon, and stars align." Again, this is not in the spirit of RFC7258. And just to remind, AUTH_SYS doesn't make sense on non-UNIX operating systems, but that perhaps is my partisan viewpoint. In closing, there's two broad questions to consider: 1) Does this do no harm? 2) Does it improve security on the Internet in the spirit of RFC7258? This is going to have to be much more detailed to convince me that it does either of these things for any implementation other than DESY or Hammerspace, and without other reference implemenatation in the BSDs or a least some flavors of Linux, you can't say this broadly interoperable either. Distributed file systems are never easy, hence DCE/AFS, so granted it's not an easy problem, but this is not ready to advance on Standards Track, unless merely being interoperable with legacy code is all we aspire to, and I sincerely hope it's not. Perhaps this needle can be threaded and with appropriate configuration by enterprising people, TLS can be configured with DNSSEC and GSS-API in RPC and NFS and it will do something reasonable and secure, but I would like to see at least some more comments from implementation experience before I could recommend this advance. Derrell From nobody Tue Oct 22 14:21:31 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBA812008D; Tue, 22 Oct 2019 14:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 UrJmHDq7Gjmc; Tue, 22 Oct 2019 14:21:26 -0700 (PDT) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.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 DC7991200F7; Tue, 22 Oct 2019 14:21:23 -0700 (PDT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x9MLJGQo022303; Tue, 22 Oct 2019 21:21:19 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2019-08-05; bh=bzMDsfNYoJLYp/Lo+ImTp4RxZlyD8kiW8qj/RKiqIaw=; b=BxPhv2xyzfL6d47iv3CXG/FYfT86iRlgYQUmDmXNL7tfEMlvLFCX8EZ3zu/jATK8MQt+ /Sw+i+fLzAVofa7Hg4DXUVpn/REEUf5HlwogSzZXpctrJp60VL/b+cX7KQDaPeVcqJ2l XO93voCcEu/RudxUSB9zQK4tNZ6KZ44/1ZYIhF/ZDgxD8W/CHkw+wiI09oZyfUQWp5qv JD+OQ1bKfaQqWZihyh+a65+JnLf9gpQd8jHLKQel6feap3vV3JR2WouO3vgAD/HEnBHh 3AS0/vyiUmhLXbT8NdEKTCRUvGpgHrLp/kjunDhlWmsKs3wj9trk2G2ZWd/60JXRDiZm +A== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2120.oracle.com with ESMTP id 2vqu4qsc1r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 22 Oct 2019 21:21:18 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x9MLIRuQ150200; Tue, 22 Oct 2019 21:21:18 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3030.oracle.com with ESMTP id 2vsx2ryj60-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 22 Oct 2019 21:21:18 +0000 Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x9MLLEID015064; Tue, 22 Oct 2019 21:21:14 GMT Received: from anon-dhcp-153.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 22 Oct 2019 14:21:14 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Chuck Lever In-Reply-To: <157177407766.13058.11570408881931663610@ietfa.amsl.com> Date: Tue, 22 Oct 2019 17:21:12 -0400 Cc: secdir@ietf.org, nfsv4@ietf.org, draft-ietf-nfsv4-rpc-tls.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5FBB7F0B-450A-417A-AD80-B1BB2BBDE1CC@oracle.com> References: <157177407766.13058.11570408881931663610@ietfa.amsl.com> To: Derrell Piper X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9418 signatures=668684 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910220183 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9418 signatures=668684 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910220183 Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-nfsv4-rpc-tls-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2019 21:21:29 -0000 Derrell, thank you for your comments. > On Oct 22, 2019, at 3:54 PM, Derrell Piper via Datatracker = wrote: >=20 > Reviewer: Derrell Piper > Review result: Not Ready >=20 > Reviewer: Derrell Piper > Review result: Not Ready >=20 > I reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents entering the IESG. These comments > are directed at the security area director(s). Document editors and = WG > chairs should treat these comments like any other last call comments. >=20 > This draft is entitled, "Remote Procedure Call Encryption by Default", > except it does not define this. The document defines a mechanism to achieve this purpose. The goal is that any server administrator can deploy a certificate (or other authentication material) on her NFS server, and client implementations that comply with this document will be able to employ encryption with no additional encryption material needed. If client implementation policy requires encryption (which over time, clients should do) then encryption will be available everywhere without the need to provide special configuration on each client (unlike GSS/Kerberos). I can retitle this document "Towards Remote Procedure Call Encryption by Default". Please let me know if you have a preferred title. > It instead discusses opportunistic RPC > encryption using TLS (DTLS), encryption that might be used if the sun, > moon, and stars align, and likely only if you're running one of two = NFS > implementations mentioned in this draft, which exclude most existing = NFS > servers on the Internet today and is incompatible with Linux (pp. 13). >=20 > To some extent, this draft simply defines a new enum in ONC RPC, named > AUTH_TLS. It completely handwaves all code changes in RPC and NFS to > support TLS, PKI, GSS-API, or DNSSEC. It contains no pseudocode, just > RFC2119 MUST, MAYs, and SHOULDs. I refer you to other work products of the nfsv4 working group. In them you will find no pseudo-code (except for XDR), only MUST, MAY, and SHOULD. As a protocol specification, it assumes that support for TLS, PKI, GSS-API, and/or DNSSEC is already available in an implementation where RPC-on-TLS might be added. Should the document state that? > pp. 5, Discovery >=20 > "The mechanism described in this document interoperates fully with RPC > implementations that do not support TLS. The use of TLS is = automatically > disabled in these cases." >=20 > Hence, Not Ready. >=20 > I have great sympathy for wanting to try to make it possible to use = TLS > by default in new NFS servers that support it, however even then, I > think this draft falls short. It seems self-contradictory at times, = and > seems to continue to default to off, not on, which is exactly what > RFC7258 says we ought not be doing anymore. This mechanism is the first step towards making RPC encryption the default everywhere. And, except for policy changes in NFS implementations, the only necessary coding change is support for sending and recognizing RPC_AUTH_TLS, and then performing a TLS handshake before allowing further RPC traffic on a connection. > Or maybe it doesn't intend to say this, since Token binding and TLSA = are > mentioned in Security Considerations, but optional, so it kinda does. > So, defer to the ADs. >=20 > pp. 6, Discovery >=20 > "Once the TLS handshake is complete, the RPC client and server will = have > established a secure channel for communicating. The client MUST = switch > to a security flavor other than AUTH_TLS within that channel, = presumably > after negotiating down redundant RPCSEC_GSS privacy and integrity > services and applying channel binding." >=20 > What are the code changes? GSS-API is subtle, please explain. Are > there really no TLS or DTLS changes for any of this? An ALPN number is allocated. No other code changes to TLS are required. What kind of code changes do you expect, other than implementation-specific logic to interpose the TLS handshake at the proper moment? Would it be appropriate to detail those changes in a document that is suppose to be implementation- agnostic? > pp. 6, Discovery, STARTTLS discussion >=20 > ONC RPC person needed. The AUTH_NONE and NULL RPC text is of concern. Can you be more specific? > pp. 7, Authentication >=20 > "If authentication of either peer fails, or if authorization based on > those identities blocks access to the server, the client association > SHOULD be rejected." >=20 > MUST be rejected. >=20 > pp. 7, Authentication >=20 > "Once a TLS session is established, the server MUST NOT utilize the > client peer's TLS identity for the purpose of authorizing individual = RPC > requests." >=20 > That's a curious statement to end a section on Authentication with. = At > least justify that statement. I can change this to a "MUST NOT substitute RPC_AUTH_TLS or the peer identity used for TLS authentication, for the existing forms of per-request RPC authentication specified by RFC 5531". > pp. 8, TLS Requirements >=20 > "Support for TLS-PSK mutual authentication [RFC4279] is OPTIONAL." >=20 > Considering this is retrofit security for a legacy UNIX UID/GID > protocol, making PSKs OPTIONAL almost seems quaint here, but okay. What is your preferred alternative? > pp. 8, TLS Requirements >=20 > "Support for and negotiation of compression is OPTIONAL." Noted. >=20 > pp. 9, Operation on Other Transports >=20 > "Transports that provide intrinsic TLS-level security (e.g. QUIC) = would > need to be accomodated separatey from the current document. In such > cases, use of TLS might not be opportunistic as it is for TCP or UDP." >=20 > "opportunitic" is misspelled, and I don't know what to make of this > sentence, but I have very partisan views on QUIC, so defer to the ADs. >=20 > I assume Section 5.1.3 is there for RDMA but it doesn't say anything. >=20 > pp. 11, X.509 Certificates Using Fingerprints >=20 > "Implementations MUST support SHA-1 as the hash algorithm for the > fingerprint. To prevent attacks based on hash collisions, support for = a > more contemporary hash function, such as SHA-256, is RECOMMENDED." >=20 > SHA-1's deprecated, right? So we shoudn't be mandating SHA-1 in new > RFCs, right? Defer to AD. I can change this to SHA-256, or whatever is the current preference. > pp. 11 Pre-Shared Keys >=20 > "should be exposed" -> "SHOULD be exposed" >=20 > pp. 12, DESY, Hammerspace, and Linux >=20 > Why are these two implementations called out? This section does not > give me confidence that this all interoperates, is it supposed to? My understanding of the Implementation Status section is to show that there are at least two implementations of the protocol specified in the document. I was not aware that this section was supposed to make any statement about interoperability with implementations not mentioned here. In fact, that would seem to be difficult to do in a document that is fixed at publication time -- it can't refer to future implementations, of course. In any event, a Linux kernel implementation is under way, and I believe there is also interest among Solaris and FreeBSD implementers. My plan is to introduce those implementations to the list in this section as they become publicly available. I am not at liberty to announce products that are not public. > pp. 13, Security Considerations >=20 > Since absolute compatibilty with fielded insecure NFS is stated as a > requirement, the obvious downgrade attack is not only permitted, but > required. Again, RFC7258 says that's no longer acceptable, doesn't = it? > nAgain, defer to the ADs. >=20 > "Implementations must take care to accurately represent to all RPC > consumers the level of security that is actually in effect." How? I can clarify this. > pp. 14, Security Considerations for AUTH_SYS on TLS >=20 > "In light of the above, it is RECOMMENDED that when AUTH_SYS is used, > RPC clients present authentication material necessary for RPC servers > they contact to have a degree of trust that the clients are acting > responsibly." >=20 > Hence, "if the sun, moon, and stars align." Again, this is not in the > spirit of RFC7258. The point of this language is to suggest a policy of requiring TLS, rather than leaving it as opportunistic. This is good implementation guidance. > And just to remind, AUTH_SYS doesn't make sense on > non-UNIX operating systems, but that perhaps is my partisan viewpoint. AUTH_SYS is the most widely deployed RPC authentication flavor by far. Addressing the security shortcomings for this flavor is a prime motivation for enabling encryption via TLS. > In closing, there's two broad questions to consider: >=20 > 1) Does this do no harm? What exactly would demonstrate harmlessness? > 2) Does it improve security on the Internet in the spirit of RFC7258? >=20 > This is going to have to be much more detailed to convince me that it > does either of these things for any implementation other than DESY or > Hammerspace, and without other reference implemenatation in the BSDs = or > a least some flavors of Linux, you can't say this broadly = interoperable > either. Simple analysis of the discovery protocol specified here shows that the mechanism can indeed detect when its peer does not support RPC_AUTH_TLS, and then not use it. We host two NFS interoperability events a year and can easily demonstrate that we have achieved reasonable interop, if that is required by the IESG. > Distributed file systems are never easy, hence DCE/AFS, so > granted it's not an easy problem, but this is not ready to advance on > Standards Track, unless merely being interoperable with legacy code is > all we aspire to, and I sincerely hope it's not. >=20 > Perhaps this needle can be threaded and with appropriate configuration > by enterprising people, TLS can be configured with DNSSEC and GSS-API = in > RPC and NFS and it will do something reasonable and secure, but I = would > like to see at least some more comments from implementation experience > before I could recommend this advance. >=20 > Derrell >=20 >=20 -- Chuck Lever From nobody Wed Oct 23 03:24:25 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E671200F4; Wed, 23 Oct 2019 03:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-vbBiT46IwJ; Wed, 23 Oct 2019 03:24:13 -0700 (PDT) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 75CB51200D8; Wed, 23 Oct 2019 03:24:13 -0700 (PDT) Received: by mail-ot1-x32c.google.com with SMTP id e11so16924745otl.5; Wed, 23 Oct 2019 03:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qPQN3k2a3O64XhlHEayznSlT1FSTpTeFtKHg8ALlnaY=; b=IzLuByxTrMzBrkt9YbsuuS6GjvRIEpBk8d14OulPvQb3kGTyrp6Nu9a6+5ogJvR6cc l5qj48atVAczuMJtS979lYIBEzblyeoEV6vH36SIVis5fePr3IzweL3s8Y/4roMHRe5c JJct6IvlxPGvE9ShWXPN+OJHJmLGKJrkM62Nl7pxQ7kXNKrKbjgF1jGO3hGT7kJsyRv0 5gg/CSkyhM8VIUgMI1sPXLjBLaCpMAxHFx4/glftyWB7nZPdJXqX/rR69JaxssrpZblc PFw1+JiV8XUMDLbZKgjPlgnklfmbl9kpDmWt6u5173ZsLUw7lZvW62jm5RCc8WDJbrmL jvLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qPQN3k2a3O64XhlHEayznSlT1FSTpTeFtKHg8ALlnaY=; b=i7e1oiD3jn7gPf5ARgRGqH01lE9K2FyxEOTw8ZClu9mtd3PVN/XZosVatkAGk7RxgD Y0DdO5BYpFgUJiANzvYq/pT6Di0ljSmdw3IqY3i6gePaF3/+/3jh0Bdl4ZDWsGPy+HUW pVwCsWv/cpRsWqoGXtqFJilNbiImWj6VWzC8uYRS183/T0CPfvjC22eXPEjh8ZRcMUKZ WlQhxPqyUMEIiFecgAahwz8zPSI6QhHfmcTYObrgyQ5nhsvNV+z+OKmn7A785TYYG5LA ZSC9o/aKx7IFoeGMuR7vMTeqQZY1kzih9x6CgjvBPXNnrcv/0EY5sPUF5aPnCmd7ZxoS lVXA== X-Gm-Message-State: APjAAAX0O955xgtrfLMeOBNyoOo1z2EYQr/af8O/5JmScFROd1dax8Ag EusjA5K5ioOdNVRG99SGpjO2tfR3F+iJGOnGi7E= X-Google-Smtp-Source: APXvYqwd8pELBozdADQXFV6KDTx3vqjMTSBca//q93bdZ1vfLaWaifvtucZ0RbwtmKD/+xyTt69Xb3PDdz75K6U8OVo= X-Received: by 2002:a05:6830:1205:: with SMTP id r5mr6322787otp.294.1571826252451; Wed, 23 Oct 2019 03:24:12 -0700 (PDT) MIME-Version: 1.0 References: <157177407766.13058.11570408881931663610@ietfa.amsl.com> <5FBB7F0B-450A-417A-AD80-B1BB2BBDE1CC@oracle.com> In-Reply-To: <5FBB7F0B-450A-417A-AD80-B1BB2BBDE1CC@oracle.com> From: David Noveck Date: Wed, 23 Oct 2019 06:24:01 -0400 Message-ID: To: Chuck Lever Cc: Derrell Piper , NFSv4 , draft-ietf-nfsv4-rpc-tls.all@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary="0000000000006d1d300595915154" Archived-At: Subject: Re: [secdir] [nfsv4] Secdir early review of draft-ietf-nfsv4-rpc-tls-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2019 10:24:17 -0000 --0000000000006d1d300595915154 Content-Type: text/plain; charset="UTF-8" >> This is going to have to be much more detailed to convince me that it >> does either of these things for any implementation other than DESY or >> Hammerspace, and without other reference implemenatation in the BSDs or >> a least some flavors of Linux, you can't say this broadly interoperable >> either. The document doesn't say that and there is no reason for it to do so. The document's job is to defne a means by which better security could be achieved, when implementations are available. If one waits for implementations to be done before approviing the specification, one is going to be waiting a long time, and NFS security will remain in its current unsatisfactory state indefinitely. > We host two NFS interoperability events a year and can easily > demonstrate that we have achieved reasonable interop, if that > is required by the IESG. I don't believe it is required for a Proposed Standard. As I understand it, no actual implementations are required although the working group has decided that prototyping of extensions is desirable. Going beyond that point and requiring full implementations of protocols that have not been approved would be a mistake. >> Distributed file systems are never easy, hence DCE/AFS, so >> granted it's not an easy problem, but this is not ready to advance on >> Standards Track, unless merely being interoperable with legacy code is >> all we aspire to, and I sincerely hope it's not. I think it should be clear that Chuck's and Trond's aspirations go beyond this. If they didn't, there would have been no need to work on this document. The situation is similar for those who have worked on implementations. If interoperation with legacy code is all one aspires to, one could implement the security specfified in rfcs 7530 and 5661. These people and the working group clearly want something better. That being said, the ability to work with legacy implementations is, in practical terms, a requirement of this enterprise. There is no point in defining a secure protocol island that cannot communicate with the implementations that exist today. > > Perhaps this needle can be threaded and with appropriate configuration > > by enterprising people, TLS can be configured with DNSSEC and GSS-API in > > RPC and NFS and it will do something reasonable and secure, If I understand this correctly, Derrel is saying that, with the appropriate configuration which he mentions, you would have someting "reasonanble and secure" :-) That makes it hard for me to undertstand the negative tone of this review. In any case, I think his specific suggestions should be followed up on to get the document ready for WGLC. . > like to see at least some more comments from implementation experience > before I could recommend this advance. I think this is the wrong approach. In my experience, it is very hard to get people to invest resources in implementing something that is not at least a Proposed Standand, and potentially open to radical change before publication. From a return-on-investment perspective, it doesn't make sense to invest in anytihing beyond limited prototyping. The fact that so much expeimental implementation has already been done in this area illustrates the perceived urgency of the situation with regard to NFS security. That work will continue in any case and implemtation experience will be available but I feel it would be a mistake to hold this document up waiting for it. I think it would be best if the document is clarified and improved, go through WGLC, and be considered for adoption as a Proposed Standard. That is a better way of getting resources allocated to the job of improving NFS security. Of course, if anyone has an appoach to improving NFS security, that is better than that in rpc-tls, the working group would intestested in earing about it. On Tue, Oct 22, 2019 at 5:21 PM Chuck Lever wrote: > Derrell, thank you for your comments. > > > > On Oct 22, 2019, at 3:54 PM, Derrell Piper via Datatracker < > noreply@ietf.org> wrote: > > > > Reviewer: Derrell Piper > > Review result: Not Ready > > > > Reviewer: Derrell Piper > > Review result: Not Ready > > > > I reviewed this document as part of the security directorate's ongoing > > effort to review all IETF documents entering the IESG. These comments > > are directed at the security area director(s). Document editors and WG > > chairs should treat these comments like any other last call comments. > > > > This draft is entitled, "Remote Procedure Call Encryption by Default", > > except it does not define this. > > The document defines a mechanism to achieve this purpose. The goal is > that any server administrator can deploy a certificate (or other > authentication material) on her NFS server, and client implementations > that comply with this document will be able to employ encryption with > no additional encryption material needed. If client implementation > policy requires encryption (which over time, clients should do) then > encryption will be available everywhere without the need to provide > special configuration on each client (unlike GSS/Kerberos). > > I can retitle this document "Towards Remote Procedure Call Encryption > by Default". Please let me know if you have a preferred title. > > > > It instead discusses opportunistic RPC > > encryption using TLS (DTLS), encryption that might be used if the sun, > > moon, and stars align, and likely only if you're running one of two NFS > > implementations mentioned in this draft, which exclude most existing NFS > > servers on the Internet today and is incompatible with Linux (pp. 13). > > > > To some extent, this draft simply defines a new enum in ONC RPC, named > > AUTH_TLS. It completely handwaves all code changes in RPC and NFS to > > support TLS, PKI, GSS-API, or DNSSEC. It contains no pseudocode, just > > RFC2119 MUST, MAYs, and SHOULDs. > > I refer you to other work products of the nfsv4 working group. In them > you will find no pseudo-code (except for XDR), only MUST, MAY, and > SHOULD. As a protocol specification, it assumes that support for TLS, > PKI, GSS-API, and/or DNSSEC is already available in an implementation > where RPC-on-TLS might be added. Should the document state that? > > > > pp. 5, Discovery > > > > "The mechanism described in this document interoperates fully with RPC > > implementations that do not support TLS. The use of TLS is automatically > > disabled in these cases." > > > > Hence, Not Ready. > > > > I have great sympathy for wanting to try to make it possible to use TLS > > by default in new NFS servers that support it, however even then, I > > think this draft falls short. It seems self-contradictory at times, and > > seems to continue to default to off, not on, which is exactly what > > RFC7258 says we ought not be doing anymore. > > This mechanism is the first step towards making RPC encryption > the default everywhere. And, except for policy changes in NFS > implementations, the only necessary coding change is support > for sending and recognizing RPC_AUTH_TLS, and then performing > a TLS handshake before allowing further RPC traffic on a > connection. > > > > Or maybe it doesn't intend to say this, since Token binding and TLSA are > > mentioned in Security Considerations, but optional, so it kinda does. > > So, defer to the ADs. > > > > pp. 6, Discovery > > > > "Once the TLS handshake is complete, the RPC client and server will have > > established a secure channel for communicating. The client MUST switch > > to a security flavor other than AUTH_TLS within that channel, presumably > > after negotiating down redundant RPCSEC_GSS privacy and integrity > > services and applying channel binding." > > > > What are the code changes? GSS-API is subtle, please explain. Are > > there really no TLS or DTLS changes for any of this? > > An ALPN number is allocated. No other code changes to TLS are > required. What kind of code changes do you expect, other than > implementation-specific logic to interpose the TLS handshake > at the proper moment? Would it be appropriate to detail those > changes in a document that is suppose to be implementation- > agnostic? > > > > pp. 6, Discovery, STARTTLS discussion > > > > ONC RPC person needed. The AUTH_NONE and NULL RPC text is of concern. > > Can you be more specific? > > > > pp. 7, Authentication > > > > "If authentication of either peer fails, or if authorization based on > > those identities blocks access to the server, the client association > > SHOULD be rejected." > > > > MUST be rejected. > > > > pp. 7, Authentication > > > > "Once a TLS session is established, the server MUST NOT utilize the > > client peer's TLS identity for the purpose of authorizing individual RPC > > requests." > > > > That's a curious statement to end a section on Authentication with. At > > least justify that statement. > > I can change this to a "MUST NOT substitute RPC_AUTH_TLS or the > peer identity used for TLS authentication, for the existing forms > of per-request RPC authentication specified by RFC 5531". > > > > pp. 8, TLS Requirements > > > > "Support for TLS-PSK mutual authentication [RFC4279] is OPTIONAL." > > > > Considering this is retrofit security for a legacy UNIX UID/GID > > protocol, making PSKs OPTIONAL almost seems quaint here, but okay. > > What is your preferred alternative? > > > > pp. 8, TLS Requirements > > > > "Support for and negotiation of compression is OPTIONAL." Noted. > > > > pp. 9, Operation on Other Transports > > > > "Transports that provide intrinsic TLS-level security (e.g. QUIC) would > > need to be accomodated separatey from the current document. In such > > cases, use of TLS might not be opportunistic as it is for TCP or UDP." > > > > "opportunitic" is misspelled, and I don't know what to make of this > > sentence, but I have very partisan views on QUIC, so defer to the ADs. > > > > I assume Section 5.1.3 is there for RDMA but it doesn't say anything. > > > > pp. 11, X.509 Certificates Using Fingerprints > > > > "Implementations MUST support SHA-1 as the hash algorithm for the > > fingerprint. To prevent attacks based on hash collisions, support for a > > more contemporary hash function, such as SHA-256, is RECOMMENDED." > > > > SHA-1's deprecated, right? So we shoudn't be mandating SHA-1 in new > > RFCs, right? Defer to AD. > > I can change this to SHA-256, or whatever is the current > preference. > > > > pp. 11 Pre-Shared Keys > > > > "should be exposed" -> "SHOULD be exposed" > > > > pp. 12, DESY, Hammerspace, and Linux > > > > Why are these two implementations called out? This section does not > > give me confidence that this all interoperates, is it supposed to? > > My understanding of the Implementation Status section is to > show that there are at least two implementations of the protocol > specified in the document. I was not aware that this section was > supposed to make any statement about interoperability with > implementations not mentioned here. In fact, that would seem to > be difficult to do in a document that is fixed at publication > time -- it can't refer to future implementations, of course. > > In any event, a Linux kernel implementation is under way, and > I believe there is also interest among Solaris and FreeBSD > implementers. My plan is to introduce those implementations to > the list in this section as they become publicly available. I > am not at liberty to announce products that are not public. > > > > pp. 13, Security Considerations > > > > Since absolute compatibilty with fielded insecure NFS is stated as a > > requirement, the obvious downgrade attack is not only permitted, but > > required. Again, RFC7258 says that's no longer acceptable, doesn't it? > > nAgain, defer to the ADs. > > > > "Implementations must take care to accurately represent to all RPC > > consumers the level of security that is actually in effect." How? > > I can clarify this. > > > > pp. 14, Security Considerations for AUTH_SYS on TLS > > > > "In light of the above, it is RECOMMENDED that when AUTH_SYS is used, > > RPC clients present authentication material necessary for RPC servers > > they contact to have a degree of trust that the clients are acting > > responsibly." > > > > Hence, "if the sun, moon, and stars align." Again, this is not in the > > spirit of RFC7258. > > The point of this language is to suggest a policy of requiring > TLS, rather than leaving it as opportunistic. This is good > implementation guidance. > > > > And just to remind, AUTH_SYS doesn't make sense on > > non-UNIX operating systems, but that perhaps is my partisan viewpoint. > > AUTH_SYS is the most widely deployed RPC authentication flavor > by far. Addressing the security shortcomings for this flavor > is a prime motivation for enabling encryption via TLS. > > > > In closing, there's two broad questions to consider: > > > > 1) Does this do no harm? > > What exactly would demonstrate harmlessness? > > > > 2) Does it improve security on the Internet in the spirit of RFC7258? > > > > This is going to have to be much more detailed to convince me that it > > does either of these things for any implementation other than DESY or > > Hammerspace, and without other reference implemenatation in the BSDs or > > a least some flavors of Linux, you can't say this broadly interoperable > > either. > > Simple analysis of the discovery protocol specified here shows > that the mechanism can indeed detect when its peer does not > support RPC_AUTH_TLS, and then not use it. > > We host two NFS interoperability events a year and can easily > demonstrate that we have achieved reasonable interop, if that > is required by the IESG. > > > > Distributed file systems are never easy, hence DCE/AFS, so > > granted it's not an easy problem, but this is not ready to advance on > > Standards Track, unless merely being interoperable with legacy code is > > all we aspire to, and I sincerely hope it's not. > > > > Perhaps this needle can be threaded and with appropriate configuration > > by enterprising people, TLS can be configured with DNSSEC and GSS-API in > > RPC and NFS and it will do something reasonable and secure, but I would > > like to see at least some more comments from implementation experience > > before I could recommend this advance. > > > > Derrell > > > > > > -- > Chuck Lever > > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www.ietf.org/mailman/listinfo/nfsv4 > --0000000000006d1d300595915154 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    >= > This is going to have to be much more detailed to convince me that it<= br>>> does either of these things for any implementation other than D= ESY or
    >> Hammerspace, and without other reference implemenatation= in the BSDs or
    >> a least some flavors of Linux, you can't sa= y this broadly interoperable
    >> either.

    The document doesn't say that a= nd there is no reason for it to do so.=C2=A0 The document's
    job is to defne= a means by which better security could be achieved, when implementations
    are a= vailable.=C2=A0 =C2=A0If one waits for implementations to be done before ap= proviing the
    specification, one is going to be waiting a long time, and NFS sec= urity will remain
    in its current unsatisfactory state indefinitely.

    > We host two NFS interoperability events a year an= d can easily
    > demonstrate that we have achieved reasonable interop, = if that
    > is required by the IESG.

    I don't believe= it is required=C2=A0for a Proposed Standard.=C2=A0 =C2=A0As I understand
    it, no actual implementations are required=C2=A0although the worki= ng group=C2=A0
    has decided that prototyping of extensions is desi= rable.=C2=A0 =C2=A0Going
    beyond that point and requiring full imp= lementations of protocols that
    have not been approved would be a = mistake.
    =C2=A0
    >= > Distributed file systems are never easy, hence DCE/AFS, so
    >> gra= nted it's not an easy problem, but this is not ready to advance on
    >&= gt; Standards Track, unless merely being interoperable with legacy code is<= /span>
    &= gt;> all we aspire to, and I sincerely hope it's not.

    I think it should be clear that C= huck's and Trond's aspirations go beyond this.
    If they didn't, there would have been n= o need to work on this document.
    The situation is similar for those who have worked on implementat= ions.

    =
    If interoperation with legacy code = is all one aspires to, one could implement
    the security specfified in rfcs 7530 and 5661.=C2=A0 = =C2=A0These people and the working
    group clearly want something better.

    That being said, the ability to work with legacy implementations is= , in practical
    terms, a= requirement of this enterprise.=C2=A0 =C2=A0There is no point in defining = a secure=C2=A0
    protocol= island that cannot communicate with the implementations that exist today.<= /span>

    > > Perhaps this needle can be threaded and with appropriat= e configuration
    > > by enterprising people, TLS can be configured with= DNSSEC and GSS-API in
    > > RPC and NFS and it will do something reas= onable and secure,=C2=A0

    If I understand = this correctly, Derrel is saying that, with the appropriate configuration
    which he mentions, you w= ould have someting "reasonanble and secure"=C2=A0 :-)

    That makes it hard for me to u= ndertstand the negative tone of this review.=C2=A0 =C2=A0In any case,
    I think=C2=A0his specific suggestions should be followed up on to get th= e document ready for
    WGLC.<= /div>
    .=C2=A0=C2=A0
    > like to see at least so= me more comments from implementation experience
    > before I could recommen= d this advance.=C2=A0=C2=A0

    I think thi= s is the wrong approach.=C2=A0 =C2=A0In my experience, it is very hard to g= et people to
    invest resources in implementing something that is n= ot at least a Proposed Standand,
    and potentially open to=C2=A0 ra= dical change before publication.=C2=A0 From a return-on-investment
    perspective, it doesn't make sense to invest in anytihing beyond limi= ted prototyping.

    The fact that so much expeimental= implementation has already been done in this area
    illustrates th= e perceived urgency of the situation with regard to NFS security.=C2=A0 =C2= =A0That
    work will continue in any case and implemtation experienc= e will be available but I
    feel it would be a mistake to hold this= document up waiting for it.=C2=A0 =C2=A0I think it would be
    best= if the document is clarified and improved, go through WGLC, and be conside= red
    for adoption as a Proposed Standard.=C2=A0 =C2=A0That is a be= tter way of getting resources
    allocated to the job of improving N= FS security.

    Of course, if anyone has an appoach t= o improving NFS security, that is better than
    that in rpc-tls, th= e working group would intestested in earing about it.

    On Tue, Oct 22, = 2019 at 5:21 PM Chuck Lever <c= huck.lever@oracle.com> wrote:
    Derrell, thank you for your comments.


    > On Oct 22, 2019, at 3:54 PM, Derrell Piper via Datatracker <noreply@ietf.org> wro= te:
    >
    > Reviewer: Derrell Piper
    > Review result: Not Ready
    >
    > Reviewer: Derrell Piper
    > Review result: Not Ready
    >
    > I reviewed this document as part of the security directorate's ong= oing
    > effort to review all IETF documents entering the IESG.=C2=A0 These com= ments
    > are directed at the security area director(s).=C2=A0 Document editors = and WG
    > chairs should treat these comments like any other last call comments.<= br> >
    > This draft is entitled, "Remote Procedure Call Encryption by Defa= ult",
    > except it does not define this.

    The document defines a mechanism to achieve this purpose. The goal is
    that any server administrator can deploy a certificate (or other
    authentication material) on her NFS server, and client implementations
    that comply with this document will be able to employ encryption with
    no additional encryption material needed. If client implementation
    policy requires encryption (which over time, clients should do) then
    encryption will be available everywhere without the need to provide
    special configuration on each client (unlike GSS/Kerberos).

    I can retitle this document "Towards Remote Procedure Call Encryption<= br> by Default". Please let me know if you have a preferred title.


    >=C2=A0 It instead discusses opportunistic RPC
    > encryption using TLS (DTLS), encryption that might be used if the sun,=
    > moon, and stars align, and likely only if you're running one of tw= o NFS
    > implementations mentioned in this draft, which exclude most existing N= FS
    > servers on the Internet today and is incompatible with Linux (pp. 13).=
    >
    > To some extent, this draft simply defines a new enum in ONC RPC, named=
    > AUTH_TLS.=C2=A0 It completely handwaves all code changes in RPC and NF= S to
    > support TLS, PKI, GSS-API, or DNSSEC.=C2=A0 It contains no pseudocode,= just
    > RFC2119 MUST, MAYs, and SHOULDs.

    I refer you to other work products of the nfsv4 working group. In them
    you will find no pseudo-code (except for XDR), only MUST, MAY, and
    SHOULD. As a protocol specification, it assumes that support for TLS,
    PKI, GSS-API, and/or DNSSEC is already available in an implementation
    where RPC-on-TLS might be added. Should the document state that?


    > pp. 5, Discovery
    >
    > "The mechanism described in this document interoperates fully wit= h RPC
    > implementations that do not support TLS. The use of TLS is automatical= ly
    > disabled in these cases."
    >
    > Hence, Not Ready.
    >
    > I have great sympathy for wanting to try to make it possible to use TL= S
    > by default in new NFS servers that support it, however even then, I > think this draft falls short.=C2=A0 It seems self-contradictory at tim= es, and
    > seems to continue to default to off, not on, which is exactly what
    > RFC7258 says we ought not be doing anymore.

    This mechanism is the first step towards making RPC encryption
    the default everywhere. And, except for policy changes in NFS
    implementations, the only necessary coding change is support
    for sending and recognizing RPC_AUTH_TLS, and then performing
    a TLS handshake before allowing further RPC traffic on a
    connection.


    > Or maybe it doesn't intend to say this, since Token binding and TL= SA are
    > mentioned in Security Considerations, but optional, so it kinda does.<= br> > So, defer to the ADs.
    >
    > pp. 6, Discovery
    >
    > "Once the TLS handshake is complete, the RPC client and server wi= ll have
    > established a secure channel for communicating.=C2=A0 The client MUST = switch
    > to a security flavor other than AUTH_TLS within that channel, presumab= ly
    > after negotiating down redundant RPCSEC_GSS privacy and integrity
    > services and applying channel binding."
    >
    > What are the code changes?=C2=A0 GSS-API is subtle, please explain.=C2= =A0 Are
    > there really no TLS or DTLS changes for any of this?

    An ALPN number is allocated. No other code changes to TLS are
    required. What kind of code changes do you expect, other than
    implementation-specific logic to interpose the TLS handshake
    at the proper moment? Would it be appropriate to detail those
    changes in a document that is suppose to be implementation-
    agnostic?


    > pp. 6, Discovery, STARTTLS discussion
    >
    > ONC RPC person needed.=C2=A0 The AUTH_NONE and NULL RPC text is of con= cern.

    Can you be more specific?


    > pp. 7, Authentication
    >
    > "If authentication of either peer fails, or if authorization base= d on
    > those identities blocks access to the server, the client association > SHOULD be rejected."
    >
    > MUST be rejected.
    >
    > pp. 7, Authentication
    >
    > "Once a TLS session is established, the server MUST NOT utilize t= he
    > client peer's TLS identity for the purpose of authorizing individu= al RPC
    > requests."
    >
    > That's a curious statement to end a section on Authentication with= .=C2=A0 At
    > least justify that statement.

    I can change this to a "MUST NOT substitute RPC_AUTH_TLS or the
    peer identity used for TLS authentication, for the existing forms
    of per-request RPC authentication specified by RFC 5531".


    > pp. 8, TLS Requirements
    >
    > "Support for TLS-PSK mutual authentication [RFC4279] is OPTIONAL.= "
    >
    > Considering this is retrofit security for a legacy UNIX UID/GID
    > protocol, making PSKs OPTIONAL almost seems quaint here, but okay.

    What is your preferred alternative?


    > pp. 8, TLS Requirements
    >
    > "Support for and negotiation of compression is OPTIONAL."=C2= =A0 Noted.
    >
    > pp. 9, Operation on Other Transports
    >
    > "Transports that provide intrinsic TLS-level security (e.g. QUIC)= would
    > need to be accomodated separatey from the current document.=C2=A0 In s= uch
    > cases, use of TLS might not be opportunistic as it is for TCP or UDP.&= quot;
    >
    > "opportunitic" is misspelled, and I don't know what to m= ake of this
    > sentence, but I have very partisan views on QUIC, so defer to the ADs.=
    >
    > I assume Section 5.1.3 is there for RDMA but it doesn't say anythi= ng.
    >
    > pp. 11, X.509 Certificates Using Fingerprints
    >
    > "Implementations MUST support SHA-1 as the hash algorithm for the=
    > fingerprint.=C2=A0 To prevent attacks based on hash collisions, suppor= t for a
    > more contemporary hash function, such as SHA-256, is RECOMMENDED."= ;
    >
    > SHA-1's deprecated, right?=C2=A0 So we shoudn't be mandating S= HA-1 in new
    > RFCs, right?=C2=A0 Defer to AD.

    I can change this to SHA-256, or whatever is the current
    preference.


    > pp. 11 Pre-Shared Keys
    >
    > "should be exposed" -> "SHOULD be exposed"
    >
    > pp. 12, DESY, Hammerspace, and Linux
    >
    > Why are these two implementations called out?=C2=A0 This section does = not
    > give me confidence that this all interoperates, is it supposed to?

    My understanding of the Implementation Status section is to
    show that there are at least two implementations of the protocol
    specified in the document. I was not aware that this section was
    supposed to make any statement about interoperability with
    implementations not mentioned here. In fact, that would seem to
    be difficult to do in a document that is fixed at publication
    time -- it can't refer to future implementations, of course.

    In any event, a Linux kernel implementation is under way, and
    I believe there is also interest among Solaris and FreeBSD
    implementers. My plan is to introduce those implementations to
    the list in this section as they become publicly available. I
    am not at liberty to announce products that are not public.


    > pp. 13, Security Considerations
    >
    > Since absolute compatibilty with fielded insecure NFS is stated as a > requirement, the obvious downgrade attack is not only permitted, but > required.=C2=A0 Again, RFC7258 says that's no longer acceptable, d= oesn't it?
    > nAgain, defer to the ADs.
    >
    > "Implementations must take care to accurately represent to all RP= C
    > consumers the level of security that is actually in effect."=C2= =A0 How?

    I can clarify this.


    > pp. 14, Security Considerations for AUTH_SYS on TLS
    >
    > "In light of the above, it is RECOMMENDED that when AUTH_SYS is u= sed,
    > RPC clients present authentication material necessary for RPC servers<= br> > they contact to have a degree of trust that the clients are acting
    > responsibly."
    >
    > Hence, "if the sun, moon, and stars align."=C2=A0 Again, thi= s is not in the
    > spirit of RFC7258.

    The point of this language is to suggest a policy of requiring
    TLS, rather than leaving it as opportunistic. This is good
    implementation guidance.


    > And just to remind, AUTH_SYS doesn't make sense on
    > non-UNIX operating systems, but that perhaps is my partisan viewpoint.=

    AUTH_SYS is the most widely deployed RPC authentication flavor
    by far. Addressing the security shortcomings for this flavor
    is a prime motivation for enabling encryption via TLS.


    > In closing, there's two broad questions to consider:
    >
    > 1) Does this do no harm?

    What exactly would demonstrate harmlessness?


    > 2) Does it improve security on the Internet in the spirit of RFC7258?<= br> >
    > This is going to have to be much more detailed to convince me that it<= br> > does either of these things for any implementation other than DESY or<= br> > Hammerspace, and without other reference implemenatation in the BSDs o= r
    > a least some flavors of Linux, you can't say this broadly interope= rable
    > either.

    Simple analysis of the discovery protocol specified here shows
    that the mechanism can indeed detect when its peer does not
    support RPC_AUTH_TLS, and then not use it.

    We host two NFS interoperability events a year and can easily
    demonstrate that we have achieved reasonable interop, if that
    is required by the IESG.


    > Distributed file systems are never easy, hence DCE/AFS, so
    > granted it's not an easy problem, but this is not ready to advance= on
    > Standards Track, unless merely being interoperable with legacy code is=
    > all we aspire to, and I sincerely hope it's not.
    >
    > Perhaps this needle can be threaded and with appropriate configuration=
    > by enterprising people, TLS can be configured with DNSSEC and GSS-API = in
    > RPC and NFS and it will do something reasonable and secure, but I woul= d
    > like to see at least some more comments from implementation experience=
    > before I could recommend this advance.
    >
    > Derrell
    >
    >

    --
    Chuck Lever



    _______________________________________________
    nfsv4 mailing list
    nfsv4@ietf.org
    https://www.ietf.org/mailman/listinfo/nfsv4
    --0000000000006d1d300595915154-- From nobody Wed Oct 23 07:17:14 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B3C120255; Wed, 23 Oct 2019 07:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 cZwvpprHsA-3; Wed, 23 Oct 2019 07:17:10 -0700 (PDT) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.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 0BB28120825; Wed, 23 Oct 2019 07:17:10 -0700 (PDT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x9NE4SNm001134; Wed, 23 Oct 2019 14:17:07 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2019-08-05; bh=gcHNk9Wy8VB99rjG2+Ld26lTVlKXGu1tVaLTu5ckdRs=; b=B0gaSED8/DH3P2i8S9PjcXSq9gH1vsg2ssMyrPg0PzWpH1HCshUG3MfTdHLu3ddn8TBt feXktz6lQKq6LDuWwNFNkpLnwtNAwo5LdmnOOzeXmc27Za9lZbX2OuvlERGMTunn0Dfn 9dgNc8Xr9YvXe6d5Qdh5C7ILfCKelcgxH98fQT5ge+QlpzOjJUDwiaf/EFUBLn03lTDc ff315PrTXfYmjazKKG6n1fTyV/TDuLnuKLYxWqFokjfmM16Tn8+jlzj1TuY3u0sgGxUM ITattON/nSlhySGtNRMy8fjAmN3eA/f3qvSFFYQ9OvP03CXKWZgiouns6nCDBpdZf/RU nQ== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2120.oracle.com with ESMTP id 2vqu4qwfnq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 23 Oct 2019 14:17:07 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x9NEEZlW012348; Wed, 23 Oct 2019 14:17:06 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3020.oracle.com with ESMTP id 2vt2hfdbyk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 23 Oct 2019 14:17:05 +0000 Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x9NEH5MI009941; Wed, 23 Oct 2019 14:17:05 GMT Received: from anon-dhcp-153.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 23 Oct 2019 07:17:04 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Chuck Lever In-Reply-To: Date: Wed, 23 Oct 2019 10:17:03 -0400 Cc: Derrell Piper , NFSv4 , draft-ietf-nfsv4-rpc-tls.all@ietf.org, secdir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <157177407766.13058.11570408881931663610@ietfa.amsl.com> <5FBB7F0B-450A-417A-AD80-B1BB2BBDE1CC@oracle.com> To: David Noveck X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9419 signatures=668684 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910230143 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9419 signatures=668684 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910230142 Archived-At: Subject: Re: [secdir] [nfsv4] Secdir early review of draft-ietf-nfsv4-rpc-tls-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2019 14:17:12 -0000 > On Oct 23, 2019, at 6:24 AM, David Noveck = wrote: >=20 > >> This is going to have to be much more detailed to convince me that = it > >> does either of these things for any implementation other than DESY = or > >> Hammerspace, and without other reference implemenatation in the = BSDs or > >> a least some flavors of Linux, you can't say this broadly = interoperable > >> either. >=20 > The document doesn't say that and there is no reason for it to do so. = The document's > job is to defne a means by which better security could be achieved, = when implementations > are available. If one waits for implementations to be done before = approviing the > specification, one is going to be waiting a long time, and NFS = security will remain > in its current unsatisfactory state indefinitely. >=20 > > We host two NFS interoperability events a year and can easily > > demonstrate that we have achieved reasonable interop, if that > > is required by the IESG. >=20 > I don't believe it is required for a Proposed Standard. As I = understand > it, no actual implementations are required although the working group=20= > has decided that prototyping of extensions is desirable. Going > beyond that point and requiring full implementations of protocols that > have not been approved would be a mistake. > =20 > >> Distributed file systems are never easy, hence DCE/AFS, so > >> granted it's not an easy problem, but this is not ready to advance = on > >> Standards Track, unless merely being interoperable with legacy code = is > >> all we aspire to, and I sincerely hope it's not. >=20 > I think it should be clear that Chuck's and Trond's aspirations go = beyond this. > If they didn't, there would have been no need to work on this = document. > The situation is similar for those who have worked on implementations. >=20 > If interoperation with legacy code is all one aspires to, one could = implement > the security specfified in rfcs 7530 and 5661. These people and the = working > group clearly want something better. >=20 > That being said, the ability to work with legacy implementations is, = in practical > terms, a requirement of this enterprise. There is no point in = defining a secure=20 > protocol island that cannot communicate with the implementations that = exist today. >=20 > > > Perhaps this needle can be threaded and with appropriate = configuration > > > by enterprising people, TLS can be configured with DNSSEC and = GSS-API in > > > RPC and NFS and it will do something reasonable and secure,=20 >=20 > If I understand this correctly, Derrel is saying that, with the = appropriate configuration > which he mentions, you would have someting "reasonanble and secure" = :-) >=20 > That makes it hard for me to undertstand the negative tone of this = review. In any case, > I think his specific suggestions should be followed up on to get the = document ready for > WGLC. Agreed. The entire review has been filed as an issue against the = document. https://github.com/chucklever/i-d-rpc-tls/issues/3 I will work with Trond to address the specific issues Derrell has called = out. > > like to see at least some more comments from implementation = experience > > before I could recommend this advance. =20 >=20 > I think this is the wrong approach. In my experience, it is very = hard to get people to > invest resources in implementing something that is not at least a = Proposed Standand, > and potentially open to radical change before publication. =46rom a = return-on-investment > perspective, it doesn't make sense to invest in anytihing beyond = limited prototyping. >=20 > The fact that so much expeimental implementation has already been done = in this area > illustrates the perceived urgency of the situation with regard to NFS = security. That > work will continue in any case and implemtation experience will be = available but I > feel it would be a mistake to hold this document up waiting for it. = I think it would be > best if the document is clarified and improved, go through WGLC, and = be considered > for adoption as a Proposed Standard. That is a better way of getting = resources > allocated to the job of improving NFS security. >=20 > Of course, if anyone has an appoach to improving NFS security, that is = better than > that in rpc-tls, the working group would intestested in earing about = it. I also welcome hearing new ideas in this area. -- Chuck Lever From nobody Wed Oct 23 07:26:52 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFC5120822; Wed, 23 Oct 2019 07:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHB_Or-NJ74b; Wed, 23 Oct 2019 07:26:41 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 893B0120255; Wed, 23 Oct 2019 07:26:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.68,221,1569276000"; d="scan'208,217";a="407797669" Received: from wifi-pro-83-058.paris.inria.fr ([128.93.83.58]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2019 16:26:38 +0200 From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Content-Type: multipart/alternative; boundary="Apple-Mail=_0456494B-32A5-4885-AB93-7E62D708C2E0" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Wed, 23 Oct 2019 16:26:38 +0200 Cc: iesg@ietf.org, secdir@ietf.org, draft-ietf-6tisch-minimal-security.all@tools.ietf.org, 6tisch <6tisch@ietf.org> To: hilarie@purplestreak.com X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [secdir] Security review of draft-ietf-6tisch-minimal-security-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2019 14:26:44 -0000 --Apple-Mail=_0456494B-32A5-4885-AB93-7E62D708C2E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Hilarie, Thank you for going over the document. Please see the responses inline. = Proposed changes to the working version of the document following your = review can be found at: = https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/8d= 77145e63531b604a7d4df4197515ffebde0927 = Kind regards, Mali=C5=A1a > Security review of Minimal Security Framework for 6TiSCH > draft-ietf-6tisch-minimal-security-12 >=20 > Do not be alarmed. I generated this review of this document as part > of the security directorate's ongoing effort to review all IETF > documents being processed by the IESG. These comments were written > with the intent of improving security requirements and considerations > in IETF drafts. Comments not addressed in last call may be included > in AD reviews during the IESG review. Document editors and WG chairs > should treat these comments just like any other last call comments. >=20 > Nodes can join a 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4e) > network) by issuing a request that is validated using pre-shared > keys. The document defines the Constrained Join Protocol and its > data structures. >=20 > The security considerations section has been done well. >=20 > The "short identifier" space consideration on page 34 might be > problematic under extreme conditions. If almost all values have > been used, a set of nodes might cause trouble by constantly > sending join requests. The JRC(s) would have to time out their > previous information, and there might be long delays before a > short identifier could be freed up. Perhaps there should be a rate > limit on join requests from any single node. (If there is such > a limit I didn't see it). On page 26, we define a parameter called =E2=80=9Cjoin rate=E2=80=9D = which sets the rate at which a Join Proxy (JP) forwards the requests on = behalf of different pledges into the network. We discuss the use of join = rate also in the Security Considerations section where I made the = following change to stress the applicability of the parameter to the = scenario you consider: OLD: A data cap on the JP prevents it from forwarding more traffic than = the network can handle. NEW: A data cap on the JP prevents it from forwarding more traffic than = the network can handle and enables throttling in case of an attack. Please let me know if the existing and the amended text sufficiently = clarifies the use of the join rate parameter. >=20 > Page 20 and page 23 mention "the user", but it is unclear what "user" > means in this framework. OLD: ...the (6LBR) pledge SHOULD signal to the user the presence of an = error condition,... NEW: ...the (6LBR) pledge SHOULD signal the presence of an error = condition,... >=20 > Page 34 says that "the loss of security properties is eminent". That > intended word was probably "imminent". I suggest rephrasing. Fixed. >=20 > Page 37 asks the reader to recall a "well-known" Bluetooth problem, = but > there is no citation for it. Either document it or remove it. Thanks, I removed this sentence as it wasn=E2=80=99t critical for the = comprehension of the rest of the paragraph. >=20 > Hilarie Orman >=20 --Apple-Mail=_0456494B-32A5-4885-AB93-7E62D708C2E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 
    Dear =
Hilarie,
    Thank you for going over the document. Please see the =
responses inline. Proposed changes to the working version of the =
document following your review can be found at:
    https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security=
/commits/8d77145e63531b604a7d4df4197515ffebde0927
    <= pre style=3D"box-sizing: border-box; font-size: 12.25px; margin-top: = 0px; margin-bottom: 1rem; overflow: auto; color: rgb(33, 37, 41); = white-space: pre-wrap; word-wrap: normal; word-break: normal; padding: = 0px;" class=3D"wordwrap">Kind = regards,
    Mali=C5=A1a

           =
Security review of Minimal Security Framework for 6TiSCH
		draft-ietf-6tisch-minimal-security-12

Do not be alarmed.  I generated this review of this document as part
of the security directorate's ongoing effort to review all IETF
documents being processed by the IESG.  These comments were written
with the intent of improving security requirements and considerations
in IETF drafts.  Comments not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.

Nodes can join a 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4e)
network) by issuing a request that is validated using pre-shared
keys.  The document defines the Constrained Join Protocol and its
data structures.

The security considerations section has been done well.

The "short identifier" space consideration on page 34 might be
problematic under extreme conditions.  If almost all values have
been used, a set of nodes might cause trouble by constantly
sending join requests.  The JRC(s) would have to time out their
previous information, and there might be long delays before a
short identifier could be freed up.  Perhaps there should be a rate
limit on join requests from any single node.  (If there is such
a limit I didn't see it).


    On page 26, we =
define a parameter called =E2=80=9Cjoin rate=E2=80=9D which sets the =
rate at which a Join Proxy (JP) forwards the requests on behalf of =
different pledges into the network. We discuss the use of join rate also =
in the Security Considerations section where I made the following change =
to stress the applicability of the parameter to the scenario you =
consider:
    OLD: A data cap on the JP prevents it from forwarding =
more traffic than the network can handle.
    NEW: A data cap on the JP prevents it from forwarding =
more traffic than the network can handle and enables throttling in case =
of an attack.
    Please let me know if the existing and the amended =
text sufficiently clarifies the use of the join rate =
parameter.

    
Page 20 and page 23 mention "the user", but it is unclear what "user"
means in this framework.


    OLD: ...the (6LBR) pledge SHOULD signal to the user =
the presence of an error condition,...
    NEW: ...the (6LBR) pledge SHOULD signal the presence =
of an error condition,...

    
Page 34 says that "the loss of security properties is eminent".  That
intended word was probably "imminent".  I suggest rephrasing.


    Fixed.

    
Page 37 asks the reader to recall a "well-known" Bluetooth problem, but
there is no citation for it.  Either document it or remove it.


    Thanks, I removed this sentence as it wasn=E2=80=99t =
critical for the comprehension of the rest of the paragraph.

    
Hilarie Orman
      = --Apple-Mail=_0456494B-32A5-4885-AB93-7E62D708C2E0-- From nobody Wed Oct 23 14:13:50 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28DB120100; Wed, 23 Oct 2019 14:13:43 -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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ivrjyvntVVG; Wed, 23 Oct 2019 14:13:41 -0700 (PDT) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670070.outbound.protection.outlook.com [40.107.67.70]) (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 B4D701200A4; Wed, 23 Oct 2019 14:13:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ktDxabs8IKaEcu4DaGaDEIZIcy0cvPN7KbxHnm/V5JykNllG40tb9rpXr4wshOS7n0N9tBQbSS1eYjXL0BcPk3qFrhrlR/j8gpN4IIG2Je939COTTOl/YoT4V5FUJ9ACNMVcFCVc0CiaNl520hpKA0+MmR9bw/AI68Z3co9nh85M3Bzy0iVeMSn3xJfnRECo98Sa9C/aR/ykmLNqkjxBn6r7//dY9+97J0xAFAFCrm1syce2LT95N0Cw+HdkP8HgomojHd4pZbIgikNsIdpegHTUNIK9t68Z9kQSmCwdBm1EolS2pSJ1lep3LX8Hs5R5VUYL6dKFykylO4kBEOLzZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rS24TSKHAFgOYs0OdOFumIUmU3B2EtySC7xzcRASmwk=; b=F6MR7mmB8ENo8sFe9llyMdEvJyH7iV+54MG4cycSW2bAeg+wWCNZxdN3cQG2/tEec8o0JQqSuARYNv5Mhyk2PCZxPmODRxR71Uti8wEId7q0bonJ5n9LSYqr14sCnfrMyRJtiHaebCk+HXHzniX+ZcLLTa4OQ4GevbxcW283qwHo4nEwVT/8B+h5J9jTCtYiOUV0RUoXxlMuBjxK3rwqHr/PwaARYdC3aXcgD/ICqaFJLYEDFBj4rt2pB6By0zCfhCcePdGufYS48kxmUgIR+J7XpayGB74SVivuingeBT6q9Kz7YwUoZuZwBsdJ/mSwkw/6kJNUdL8yJsnjH0jNmw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none Received: from YTBPR01MB2845.CANPRD01.PROD.OUTLOOK.COM (10.255.13.156) by YTBPR01MB3965.CANPRD01.PROD.OUTLOOK.COM (10.255.45.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.20; Wed, 23 Oct 2019 21:13:38 +0000 Received: from YTBPR01MB2845.CANPRD01.PROD.OUTLOOK.COM ([fe80::45c3:a411:3ee8:a12e]) by YTBPR01MB2845.CANPRD01.PROD.OUTLOOK.COM ([fe80::45c3:a411:3ee8:a12e%5]) with mapi id 15.20.2347.030; Wed, 23 Oct 2019 21:13:38 +0000 From: Rick Macklem To: David Noveck , Chuck Lever CC: "draft-ietf-nfsv4-rpc-tls.all@ietf.org" , NFSv4 , Derrell Piper , "secdir@ietf.org" Thread-Topic: [nfsv4] Secdir early review of draft-ietf-nfsv4-rpc-tls-03 Thread-Index: AQHViYwLKLhGhWnMfUOCVDCRbThM3adouMbo Date: Wed, 23 Oct 2019 21:13:38 +0000 Message-ID: References: <157177407766.13058.11570408881931663610@ietfa.amsl.com> <5FBB7F0B-450A-417A-AD80-B1BB2BBDE1CC@oracle.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b7293f28-f3ec-471c-e0b7-08d757fddfa0 x-ms-traffictypediagnostic: YTBPR01MB3965: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 019919A9E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(396003)(376002)(366004)(136003)(199004)(189003)(43544003)(25786009)(966005)(71200400001)(71190400001)(14454004)(478600001)(52536014)(256004)(14444005)(305945005)(74316002)(486006)(81156014)(8676002)(229853002)(81166006)(6436002)(476003)(6306002)(5660300002)(55016002)(11346002)(9686003)(6246003)(30864003)(66574012)(8936002)(110136005)(76176011)(4326008)(86362001)(99286004)(6506007)(54906003)(102836004)(53546011)(186003)(7696005)(33656002)(46003)(446003)(316002)(2906002)(786003)(76116006)(66446008)(64756008)(66556008)(66476007)(66946007); DIR:OUT; SFP:1101; SCL:1; SRVR:YTBPR01MB3965; H:YTBPR01MB2845.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4dotfcvQRuETMR8z/yObxAQPYEqKNZ/OkuqYefix1e/vgwv/sKxpbvMAiUJ4bvDAAVgnqdaGQ6uQVZ4HQksBi9vgWP90MbbQ3CeEMsVm3sv7OWys4YJcjL9DIsKPsImR0HarQ9GPomEKQliZ07b3b1t5PLLCAed4pWzsVdayOzdZEeB9JCX1CQMpP/fdq/qiDQBH8uqHu48wNca6WjvUjjLKZI+Ud9D5s7lPNqf34papGwJA6ip9X8GzTjLw1dKYNfRpMLEJY+Cs2O/swzdWWPDfjkG7VLBj9iN3CARR9QLNvL6MV1hfLGMxDVI+zmYCTo7NJnkfwJmMzILRBQ0v+VK+Ee+3Y4VNU2mOMpiUz0kkGsM839aNz690NvxEH8MBVLGVmxbtSeVZMaxL5nMmtRFgOxrW43gCxDkuOmeHH82n+Jq6UOIjf2nUIjvybHCD+tRAXZHCeuItZTfg2qPzv0yDTpimtp8x1pzstX00+4A= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: b7293f28-f3ec-471c-e0b7-08d757fddfa0 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2019 21:13:38.5150 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MSe6Ww9rwnmjn3j3eViWYzERbOxRgPFVyiD77Xhdls/pgvLoyIuEg3W8CSGVmQU0dqKpW9X07oNni2hVwngMPw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB3965 Archived-At: Subject: Re: [secdir] [nfsv4] Secdir early review of draft-ietf-nfsv4-rpc-tls-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2019 21:13:44 -0000 I'll admit I haven't read the most recent draft and haven't looked at it in detail. However, my impression is that the reviewer might be more comfortable if the draft makes it clear that "rpc-tls only" servers will not only be permitted, but encouraged. (I don't see a "http" vs "https" distinction, but extant NFSv4 servers that I am familiar with can be configured to only allow clients that use RPCSEC_GSS and I would expect that rpc-tls enabled servers could be configured the same way.) As an aside, I do plan on implementing this in Winter 2020, rick ________________________________________ From: nfsv4 on behalf of David Noveck Sent: Wednesday, October 23, 2019 6:24 AM To: Chuck Lever Cc: draft-ietf-nfsv4-rpc-tls.all@ietf.org; NFSv4; Derrell Piper; secdir@iet= f.org Subject: Re: [nfsv4] Secdir early review of draft-ietf-nfsv4-rpc-tls-03 >> This is going to have to be much more detailed to convince me that it >> does either of these things for any implementation other than DESY or >> Hammerspace, and without other reference implemenatation in the BSDs or >> a least some flavors of Linux, you can't say this broadly interoperable >> either. The document doesn't say that and there is no reason for it to do so. The = document's job is to defne a means by which better security could be achieved, when im= plementations are available. If one waits for implementations to be done before approvi= ing the specification, one is going to be waiting a long time, and NFS security wil= l remain in its current unsatisfactory state indefinitely. > We host two NFS interoperability events a year and can easily > demonstrate that we have achieved reasonable interop, if that > is required by the IESG. I don't believe it is required for a Proposed Standard. As I understand it, no actual implementations are required although the working group has decided that prototyping of extensions is desirable. Going beyond that point and requiring full implementations of protocols that have not been approved would be a mistake. >> Distributed file systems are never easy, hence DCE/AFS, so >> granted it's not an easy problem, but this is not ready to advance on >> Standards Track, unless merely being interoperable with legacy code is >> all we aspire to, and I sincerely hope it's not. I think it should be clear that Chuck's and Trond's aspirations go beyond t= his. If they didn't, there would have been no need to work on this document. The situation is similar for those who have worked on implementations. If interoperation with legacy code is all one aspires to, one could impleme= nt the security specfified in rfcs 7530 and 5661. These people and the worki= ng group clearly want something better. That being said, the ability to work with legacy implementations is, in pra= ctical terms, a requirement of this enterprise. There is no point in defining a = secure protocol island that cannot communicate with the implementations that exist= today. > > Perhaps this needle can be threaded and with appropriate configuration > > by enterprising people, TLS can be configured with DNSSEC and GSS-API i= n > > RPC and NFS and it will do something reasonable and secure, If I understand this correctly, Derrel is saying that, with the appropriate= configuration which he mentions, you would have someting "reasonanble and secure" :-) That makes it hard for me to undertstand the negative tone of this review. = In any case, I think his specific suggestions should be followed up on to get the docume= nt ready for WGLC. . > like to see at least some more comments from implementation experience > before I could recommend this advance. I think this is the wrong approach. In my experience, it is very hard to = get people to invest resources in implementing something that is not at least a Proposed = Standand, and potentially open to radical change before publication. From a return-= on-investment perspective, it doesn't make sense to invest in anytihing beyond limited pr= ototyping. The fact that so much expeimental implementation has already been done in t= his area illustrates the perceived urgency of the situation with regard to NFS secur= ity. That work will continue in any case and implemtation experience will be availabl= e but I feel it would be a mistake to hold this document up waiting for it. I thi= nk it would be best if the document is clarified and improved, go through WGLC, and be con= sidered for adoption as a Proposed Standard. That is a better way of getting reso= urces allocated to the job of improving NFS security. Of course, if anyone has an appoach to improving NFS security, that is bett= er than that in rpc-tls, the working group would intestested in earing about it. On Tue, Oct 22, 2019 at 5:21 PM Chuck Lever > wrote: Derrell, thank you for your comments. > On Oct 22, 2019, at 3:54 PM, Derrell Piper via Datatracker > wrote: > > Reviewer: Derrell Piper > Review result: Not Ready > > Reviewer: Derrell Piper > Review result: Not Ready > > I reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents entering the IESG. These comments > are directed at the security area director(s). Document editors and WG > chairs should treat these comments like any other last call comments. > > This draft is entitled, "Remote Procedure Call Encryption by Default", > except it does not define this. The document defines a mechanism to achieve this purpose. The goal is that any server administrator can deploy a certificate (or other authentication material) on her NFS server, and client implementations that comply with this document will be able to employ encryption with no additional encryption material needed. If client implementation policy requires encryption (which over time, clients should do) then encryption will be available everywhere without the need to provide special configuration on each client (unlike GSS/Kerberos). I can retitle this document "Towards Remote Procedure Call Encryption by Default". Please let me know if you have a preferred title. > It instead discusses opportunistic RPC > encryption using TLS (DTLS), encryption that might be used if the sun, > moon, and stars align, and likely only if you're running one of two NFS > implementations mentioned in this draft, which exclude most existing NFS > servers on the Internet today and is incompatible with Linux (pp. 13). > > To some extent, this draft simply defines a new enum in ONC RPC, named > AUTH_TLS. It completely handwaves all code changes in RPC and NFS to > support TLS, PKI, GSS-API, or DNSSEC. It contains no pseudocode, just > RFC2119 MUST, MAYs, and SHOULDs. I refer you to other work products of the nfsv4 working group. In them you will find no pseudo-code (except for XDR), only MUST, MAY, and SHOULD. As a protocol specification, it assumes that support for TLS, PKI, GSS-API, and/or DNSSEC is already available in an implementation where RPC-on-TLS might be added. Should the document state that? > pp. 5, Discovery > > "The mechanism described in this document interoperates fully with RPC > implementations that do not support TLS. The use of TLS is automatically > disabled in these cases." > > Hence, Not Ready. > > I have great sympathy for wanting to try to make it possible to use TLS > by default in new NFS servers that support it, however even then, I > think this draft falls short. It seems self-contradictory at times, and > seems to continue to default to off, not on, which is exactly what > RFC7258 says we ought not be doing anymore. This mechanism is the first step towards making RPC encryption the default everywhere. And, except for policy changes in NFS implementations, the only necessary coding change is support for sending and recognizing RPC_AUTH_TLS, and then performing a TLS handshake before allowing further RPC traffic on a connection. > Or maybe it doesn't intend to say this, since Token binding and TLSA are > mentioned in Security Considerations, but optional, so it kinda does. > So, defer to the ADs. > > pp. 6, Discovery > > "Once the TLS handshake is complete, the RPC client and server will have > established a secure channel for communicating. The client MUST switch > to a security flavor other than AUTH_TLS within that channel, presumably > after negotiating down redundant RPCSEC_GSS privacy and integrity > services and applying channel binding." > > What are the code changes? GSS-API is subtle, please explain. Are > there really no TLS or DTLS changes for any of this? An ALPN number is allocated. No other code changes to TLS are required. What kind of code changes do you expect, other than implementation-specific logic to interpose the TLS handshake at the proper moment? Would it be appropriate to detail those changes in a document that is suppose to be implementation- agnostic? > pp. 6, Discovery, STARTTLS discussion > > ONC RPC person needed. The AUTH_NONE and NULL RPC text is of concern. Can you be more specific? > pp. 7, Authentication > > "If authentication of either peer fails, or if authorization based on > those identities blocks access to the server, the client association > SHOULD be rejected." > > MUST be rejected. > > pp. 7, Authentication > > "Once a TLS session is established, the server MUST NOT utilize the > client peer's TLS identity for the purpose of authorizing individual RPC > requests." > > That's a curious statement to end a section on Authentication with.. At > least justify that statement. I can change this to a "MUST NOT substitute RPC_AUTH_TLS or the peer identity used for TLS authentication, for the existing forms of per-request RPC authentication specified by RFC 5531". > pp. 8, TLS Requirements > > "Support for TLS-PSK mutual authentication [RFC4279] is OPTIONAL." > > Considering this is retrofit security for a legacy UNIX UID/GID > protocol, making PSKs OPTIONAL almost seems quaint here, but okay. What is your preferred alternative? > pp. 8, TLS Requirements > > "Support for and negotiation of compression is OPTIONAL." Noted. > > pp. 9, Operation on Other Transports > > "Transports that provide intrinsic TLS-level security (e.g. QUIC) would > need to be accomodated separatey from the current document. In such > cases, use of TLS might not be opportunistic as it is for TCP or UDP." > > "opportunitic" is misspelled, and I don't know what to make of this > sentence, but I have very partisan views on QUIC, so defer to the ADs. > > I assume Section 5.1.3 is there for RDMA but it doesn't say anything. > > pp. 11, X.509 Certificates Using Fingerprints > > "Implementations MUST support SHA-1 as the hash algorithm for the > fingerprint. To prevent attacks based on hash collisions, support for a > more contemporary hash function, such as SHA-256, is RECOMMENDED." > > SHA-1's deprecated, right? So we shoudn't be mandating SHA-1 in new > RFCs, right? Defer to AD. I can change this to SHA-256, or whatever is the current preference. > pp. 11 Pre-Shared Keys > > "should be exposed" -> "SHOULD be exposed" > > pp. 12, DESY, Hammerspace, and Linux > > Why are these two implementations called out? This section does not > give me confidence that this all interoperates, is it supposed to? My understanding of the Implementation Status section is to show that there are at least two implementations of the protocol specified in the document. I was not aware that this section was supposed to make any statement about interoperability with implementations not mentioned here. In fact, that would seem to be difficult to do in a document that is fixed at publication time -- it can't refer to future implementations, of course. In any event, a Linux kernel implementation is under way, and I believe there is also interest among Solaris and FreeBSD implementers. My plan is to introduce those implementations to the list in this section as they become publicly available. I am not at liberty to announce products that are not public. > pp. 13, Security Considerations > > Since absolute compatibilty with fielded insecure NFS is stated as a > requirement, the obvious downgrade attack is not only permitted, but > required. Again, RFC7258 says that's no longer acceptable, doesn't it? > nAgain, defer to the ADs. > > "Implementations must take care to accurately represent to all RPC > consumers the level of security that is actually in effect." How? I can clarify this. > pp. 14, Security Considerations for AUTH_SYS on TLS > > "In light of the above, it is RECOMMENDED that when AUTH_SYS is used, > RPC clients present authentication material necessary for RPC servers > they contact to have a degree of trust that the clients are acting > responsibly." > > Hence, "if the sun, moon, and stars align." Again, this is not in the > spirit of RFC7258. The point of this language is to suggest a policy of requiring TLS, rather than leaving it as opportunistic. This is good implementation guidance. > And just to remind, AUTH_SYS doesn't make sense on > non-UNIX operating systems, but that perhaps is my partisan viewpoint. AUTH_SYS is the most widely deployed RPC authentication flavor by far. Addressing the security shortcomings for this flavor is a prime motivation for enabling encryption via TLS. > In closing, there's two broad questions to consider: > > 1) Does this do no harm? What exactly would demonstrate harmlessness? > 2) Does it improve security on the Internet in the spirit of RFC7258? > > This is going to have to be much more detailed to convince me that it > does either of these things for any implementation other than DESY or > Hammerspace, and without other reference implemenatation in the BSDs or > a least some flavors of Linux, you can't say this broadly interoperable > either. Simple analysis of the discovery protocol specified here shows that the mechanism can indeed detect when its peer does not support RPC_AUTH_TLS, and then not use it. We host two NFS interoperability events a year and can easily demonstrate that we have achieved reasonable interop, if that is required by the IESG. > Distributed file systems are never easy, hence DCE/AFS, so > granted it's not an easy problem, but this is not ready to advance on > Standards Track, unless merely being interoperable with legacy code is > all we aspire to, and I sincerely hope it's not. > > Perhaps this needle can be threaded and with appropriate configuration > by enterprising people, TLS can be configured with DNSSEC and GSS-API in > RPC and NFS and it will do something reasonable and secure, but I would > like to see at least some more comments from implementation experience > before I could recommend this advance. > > Derrell > > -- Chuck Lever _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www.ietf.org/mailman/listinfo/nfsv4 From nobody Thu Oct 24 06:14:10 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F402B120120; Thu, 24 Oct 2019 06:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 ImvCNrY9iuX8; Thu, 24 Oct 2019 06:14:06 -0700 (PDT) Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 680DE12010E; Thu, 24 Oct 2019 06:14:06 -0700 (PDT) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x9ODDph2109427; Thu, 24 Oct 2019 13:14:00 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2019-08-05; bh=uLP6zwvx8yX9lm64zUlNTScsAXtktlzwM451onZn6iM=; b=eFzpeaTUakVjNdTcUAswqcVTCodrzizaQOL2/YH78sHF3G+hj7gOj9hzdKBxkhQ9/r7B t34klDX7yA8OszGzbAsPYorCcU5YSsAphyLySc0L21dlfu++WFqYXKEWCQYhb7NHqy9z BbCDtDCpcVAYcNILJjgkyroisTsD9tJ87ToDtZJlVPjK9nfCuelSnbcFS0x67id06oe5 jiSwnopJI0UgBmRI8AaFGupVrMQ0csmAShQNZQGevgIxHet96e++ac02Cfr/ZxMNOtsw lyIVXuQVxy1lCJWVSyYdHQysbeKg1Sm+6EN+GqQu78uXc3qjGhlTcUQ/4TcS0nZE4kPG kQ== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 2vqteq3ht8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 24 Oct 2019 13:14:00 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x9ODDCtp092793; Thu, 24 Oct 2019 13:13:59 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3030.oracle.com with ESMTP id 2vtjkjjrxv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 24 Oct 2019 13:13:59 +0000 Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x9ODDwc4025946; Thu, 24 Oct 2019 13:13:58 GMT Received: from anon-dhcp-153.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 24 Oct 2019 06:13:58 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Chuck Lever In-Reply-To: Date: Thu, 24 Oct 2019 09:13:57 -0400 Cc: David Noveck , Derrell Piper , NFSv4 , "draft-ietf-nfsv4-rpc-tls.all@ietf.org" , "secdir@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <096259B5-3892-409E-8FE9-1920BA7175BD@oracle.com> References: <157177407766.13058.11570408881931663610@ietfa.amsl.com> <5FBB7F0B-450A-417A-AD80-B1BB2BBDE1CC@oracle.com> To: Rick Macklem X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9419 signatures=668684 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910240128 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9419 signatures=668684 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910240128 Archived-At: Subject: Re: [secdir] [nfsv4] Secdir early review of draft-ietf-nfsv4-rpc-tls-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2019 13:14:08 -0000 > On Oct 23, 2019, at 5:13 PM, Rick Macklem wrote: > > I'll admit I haven't read the most recent draft and haven't looked at it > in detail. However, my impression is that the reviewer might be more > comfortable if the draft makes it clear that "rpc-tls only" servers will > not only be permitted, but encouraged. Indeed, they are permitted. All legacy servers will take this form, and of course, if no certificate material is provided to a TLS-capable NFS server, it will act as if RPC-on-TLS is recognized but not supported. "Encouraged" is a bit strong, however. I think if we /encourage/ a behavior, it would be to encourage the use of RPC-on-TLS where it is practical. > (I don't see a "http" vs "https" distinction, but extant NFSv4 servers that > I am familiar with can be configured to only allow clients that use > RPCSEC_GSS and I would expect that rpc-tls enabled servers could be > configured the same way.) > > As an aside, I do plan on implementing this in Winter 2020, rick Thanks Rick! -- Chuck Lever From nobody Thu Oct 24 09:42:33 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9680312096D; Thu, 24 Oct 2019 09:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axFIkM6Z6g75; Thu, 24 Oct 2019 09:42:28 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 44B7612097D; Thu, 24 Oct 2019 09:42:15 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id u13so2485770ote.0; Thu, 24 Oct 2019 09:42:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RJYuInH9kyDZC5vPh0bWoSZUIWtn+n+xFNp4vSPwhm0=; b=Dqhf20EgSXVVg/wsJipoZ+Ie5mKNXLgyVDtK9cGsKzm6AXMR116Yfmn82GfES5QHLC SONHuuzao84d0KaFx/GbAU9nmoN9urC4KseCXadG/G5l/tfrBGwhwlZJaXfug4PH1yWH 1hY7/8ihREdKM5kTv6ed1M3lcwdgao9870Yj85ZL6SFS8ROMGGmzGZnqjpKnnozfp9YZ wQc5/BP8e3cypTynQdHY1vbOXtg2EIe/Jbuzgsltn4nLJaBGmSXdbNICRk/vGcJKTLrf 9jHIecYSSOrzi4GcTgiMN12HrzPSLggWeVT2jWeC8IIny7hlArRVLJqixJPOdfwdEsuS MY9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RJYuInH9kyDZC5vPh0bWoSZUIWtn+n+xFNp4vSPwhm0=; b=LwzLg9bJN6ljNxJI3tC1C+Pd+7brNPlrX2S5GfT5kh2yWc753gX58/+IrWyJ0GSaBh SnAGoa2d/kP57FVsjy2f1j16d+l072Qu4APLD+tNEm4vzRWaFOwhTZcF7WKF5t60KyQt bPsbhnBW05yk0quiTAMLhWnWQc1qD041n4xVsclFILJVJPVP2Akj8uhkYP3ld43cJamn Usi/wJw5QLmHwm9lVviFbgwNw8BxKnatg9dyfshseCneh/ZphIom8bAM1up6/aZBIWkt If7TpvhiLk9Y/rnVTnuC4wU3GY2J1zyDDK5+S5gcs7C2JkDzGu8dZZuGS+ybQn0YKKac iX7A== X-Gm-Message-State: APjAAAXNkEqPFIkwIj5ocqj0eDYl4Ijg9uUH4opfRRBrepOtHSnNAOwl fUcB+7gbZ2FjsYxQJQgYCdgiLG3TvjHcRLV7a2U= X-Google-Smtp-Source: APXvYqwSiwjKnWmYvA8ea2gcUTs9uASE9NgJJgfLupvRto+yg2M+iqKoD4uR2ku6cP2oHMQwa4SMeXlWnMMpITiK04g= X-Received: by 2002:a9d:721c:: with SMTP id u28mr12637543otj.359.1571935334416; Thu, 24 Oct 2019 09:42:14 -0700 (PDT) MIME-Version: 1.0 References: <157177407766.13058.11570408881931663610@ietfa.amsl.com> <5FBB7F0B-450A-417A-AD80-B1BB2BBDE1CC@oracle.com> <096259B5-3892-409E-8FE9-1920BA7175BD@oracle.com> In-Reply-To: <096259B5-3892-409E-8FE9-1920BA7175BD@oracle.com> From: David Noveck Date: Thu, 24 Oct 2019 12:42:03 -0400 Message-ID: To: Chuck Lever Cc: Rick Macklem , Derrell Piper , NFSv4 , "draft-ietf-nfsv4-rpc-tls.all@ietf.org" , "secdir@ietf.org" Content-Type: multipart/alternative; boundary="00000000000037c4fa0595aab739" Archived-At: Subject: Re: [secdir] [nfsv4] Secdir early review of draft-ietf-nfsv4-rpc-tls-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2019 16:42:31 -0000 --00000000000037c4fa0595aab739 Content-Type: text/plain; charset="UTF-8" > Indeed, they are permitted. Otherwise there would be no point in writing this document. > All legacy servers will take this form, What form? > and of course, ???? > if no certificate material is provided to a TLS-capable > NFS server, it will act as if RPC-on-TLS is recognized but not > supported. i don't think this right. I think encryption without authentication is of real value if you have other ways of authenticating. I think it would be reasonable for server to be configured so as not to accept use of auth_SYs fro unauthenticated clients. > "Encouraged" is a bit strong, however. It's weaker than "recommended", "required", "RECOMMENDED", and "REQUIRED". If you don't like those, you are gpoing to have to say something beyond "OPTIONAL". Even if there is no RFC21119, you could describe 9normatively) describe use of this as "valuable", "highly desirable". > I think if we /encourage/ a > behavior, it would be to encourage the use of RPC-on-TLS where it is > practical. We certainly don't want to encorage use of this where it is impractical. If we did, nobody would listen to us, anyway. Perhaps we can address this non-normatively by accurately describing the consequences of not using this. The document on NFSv4 security will probably take that approach. On Thu, Oct 24, 2019 at 9:14 AM Chuck Lever wrote: > > > On Oct 23, 2019, at 5:13 PM, Rick Macklem wrote: > > > > I'll admit I haven't read the most recent draft and haven't looked at it > > in detail. However, my impression is that the reviewer might be more > > comfortable if the draft makes it clear that "rpc-tls only" servers will > > not only be permitted, but encouraged. > > Indeed, they are permitted. All legacy servers will take this form, > and of course, if no certificate material is provided to a TLS-capable > NFS server, it will act as if RPC-on-TLS is recognized but not > supported. > > "Encouraged" is a bit strong, however. I think if we /encourage/ a > behavior, it would be to encourage the use of RPC-on-TLS where it is > practical. > > > > (I don't see a "http" vs "https" distinction, but extant NFSv4 servers > that > > I am familiar with can be configured to only allow clients that use > > RPCSEC_GSS and I would expect that rpc-tls enabled servers could be > > configured the same way.) > > > > As an aside, I do plan on implementing this in Winter 2020, rick > > Thanks Rick! > > -- > Chuck Lever > > > > --00000000000037c4fa0595aab739 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      > Indeed, they are permitted.=C2=A0

      = Otherwise there would be no point in writing this document.

      <= /div>
      > All legacy servers will take this form,

      =
      What form?

      > and of course,=C2=A0

      ????

      > if no certificate material is prov= ided to a TLS-capable
      > NFS server, it will act as if RPC-on-TLS is r= ecognized but not
      > supported.

      i don't t= hink this right.=C2=A0 =C2=A0I think encryption without authentication
      is of real value if you have other ways of authenticating.=C2=A0 =C2= =A0I think=C2=A0
      it would be reasonable for server to be configur= ed=C2=A0so as not to=C2=A0
      accept use of auth_SYs fro unauthentic= ated clients.

      > "Encouraged" is a bit strong, however.= =C2=A0

      It's weaker than "recommended"= ;, "required", "RECOMMENDED",
      and "REQUI= RED".=C2=A0 =C2=A0If you don't like those, you are gpoing to have<= /div>
      to say something beyond "OPTIONAL".=C2=A0 =C2=A0Even if= there is no
      RFC21119, you could describe 9normatively) describe = use of this=C2=A0
      as "valuable", "highly desirable= ".

      > I think if we /encourage/ a
      > b= ehavior, it would be to encourage the use of RPC-on-TLS where it is
      >= practical.

      We certainly don't want to encorag= e use of this where it is impractical.
      If we did, nobody would li= sten to us, anyway.

      Perhaps we can address this no= n-normatively by accurately describing=C2=A0
      the consequences of = not using this.=C2=A0 =C2=A0The document on NFSv4 security=C2=A0
      <= div>will probably take that approach.

      On Thu, Oct 24, 2019 at 9:14 AM = Chuck Lever <chuck.lever@oracl= e.com> wrote:

      > On Oct 23, 2019, at 5:13 PM, Rick Macklem <rmacklem@uoguelph.ca> wrote:
      >
      > I'll admit I haven't read the most recent draft and haven'= t looked at it
      > in detail. However, my impression is that the reviewer might be more > comfortable if the draft makes it clear that "rpc-tls only" = servers will
      > not only be permitted, but encouraged.

      Indeed, they are permitted. All legacy servers will take this form,
      and of course, if no certificate material is provided to a TLS-capable
      NFS server, it will act as if RPC-on-TLS is recognized but not
      supported.

      "Encouraged" is a bit strong, however. I think if we /encourage/ = a
      behavior, it would be to encourage the use of RPC-on-TLS where it is
      practical.


      > (I don't see a "http" vs "https" distinction, = but extant NFSv4 servers that
      > I am familiar with can be configured to only allow clients that use > RPCSEC_GSS and I would expect that rpc-tls enabled servers could be > configured the same way.)
      >
      > As an aside, I do plan on implementing this in Winter 2020, rick

      Thanks Rick!

      --
      Chuck Lever



      --00000000000037c4fa0595aab739-- From nobody Thu Oct 24 10:58:52 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12281200E3 for ; Thu, 24 Oct 2019 10:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.101 X-Spam-Level: *** X-Spam-Status: No, score=3.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vXYQ0y-wv03 for ; Thu, 24 Oct 2019 10:58:47 -0700 (PDT) Received: from cuda.olm1.com (cuda.olm1.com [72.236.255.32]) (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 4B8DD1200B2 for ; Thu, 24 Oct 2019 10:58:47 -0700 (PDT) X-ASG-Debug-ID: 1571938966-092fd3685c50e10001-mFDwdl Received: from host105.olm1.com (host105.olm1.com [72.236.255.15]) by cuda.olm1.com with ESMTP id YLg3myKcq6m6aiyT (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 24 Oct 2019 13:42:46 -0400 (EDT) X-Barracuda-Envelope-From: victor.demjanenko@vocal.com X-Barracuda-Apparent-Source-IP: 72.236.255.15 Received: from HERTELLT (rrcs-72-43-202-98.nys.biz.rr.com [72.43.202.98]) by host105.olm1.com (Postfix) with ESMTPSA id 87EB6B5B921; Thu, 24 Oct 2019 13:42:46 -0400 (EDT) From: To: "'Roni Even \(A\)'" , "'Benjamin Kaduk'" , "'The IESG'" , "'Catherine Meadows'" , Cc: , "'Ali Begen'" , , , "'Dave Satterlee \(Vocal\)'" , , , , "'Victor Demjanenko, Ph.D.'" References: <157007038502.8860.1558861534319247512.idtracker@ietfa.amsl.com> <001601d57af9$405efcf0$c11cf6d0$@vocal.com> <6E58094ECC8D8344914996DAD28F1CCD23D79BC0@DGGEMM506-MBX.china.huawei.com> <034a01d58a73$f4d3a1c0$de7ae540$@vocal.com> In-Reply-To: <034a01d58a73$f4d3a1c0$de7ae540$@vocal.com> Date: Thu, 24 Oct 2019 13:42:45 -0400 X-ASG-Orig-Subj: RE: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) Message-ID: <037e01d58a92$72287510$56795f30$@vocal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKF5W0DvD42FGb/qFKkK3bBTKTeXwLglFUwAo/9rkMBQrixDqXTvquw Content-Language: en-us X-Barracuda-Connect: host105.olm1.com[72.236.255.15] X-Barracuda-Start-Time: 1571938966 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://72.236.255.32:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at olm1.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.77561 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name Archived-At: Subject: Re: [secdir] Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2019 17:58:51 -0000 I forgot to address security comments in one email. The changes are: Section 8, second paragraph - Suggested edit by reviewer (was) This RTP payload format and the TSVCIS decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological data. Additionally, the RTP payload format does not contain any active content. =20 (now) This RTP payload format and the TSVCIS decoder, to the best of our knowledge, do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological data. Additionally, the RTP payload format does not contain any active content. =20 Section 8, third paragraph - Suggested edit by reviewer (was) Please see the security considerations discussed in [RFC6562] regarding VAD and its effect on bitrates. (now) Please see the security considerations discussed in [RFC6562] regarding Voice Activity Detect (VAD) and its effect on bitrates. Victor -----Original Message----- From: victor.demjanenko@vocal.com =20 Sent: Thursday, October 24, 2019 10:05 AM To: 'Roni Even (A)' ; 'Benjamin Kaduk' = ; 'The IESG' Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' = ; avtcore-chairs@ietf.org; avt@ietf.org; = 'Dave Satterlee (Vocal)' Subject: RE: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: = (with DISCUSS and COMMENT) Hi Everyone, First we want to thank everyone for their review and comments for this = draft RFC. We believe we reviewed all the comments and suggestions and = incorporated them adequately in the next draft (04). We'd like to send = out this list of exact changes in case anyone has additional comments or = thinks the clarifications are inadequate. We would be most happy to = address concerns before publishing draft 04 tomorrow. With so many emails from a half dozen or more reviewers, we apologize = that we cannot address each sender individually. We hope this detail is = sufficient for everyone. Again, many thanks to all. Victor & Dave -------------------------------------------------------------------------= --------------------- Section 1.1 - Suggested reference to RFC 8088 added. (was) Best current practices for writing an RTP payload format specification were followed [RFC2736]. (now) Best current practices for writing an RTP payload format specification were followed [RFC2736] [RFC8088]. Section 2, paragraphs 3 and 4 - Suggested edits by reviewers (was) In addition to the augmented speech data, the TSVCIS specification identifies which speech coder and framing bits are to be encrypted, and how they are protected by forward error correction (FEC) techniques (using block codes). At the RTP transport layer, only the speech coder related bits need to be considered and are conveyed in unencrypted form. In most IP-based network deployments, standard link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type 1 Ethernet encryptors) would be used to secure the RTP speech contents. Further, it is desirable to support the highest voice quality between endpoints which is only possible without the overhead of FEC. TSVCIS augmented speech data is derived from the signal processing and data already performed by the MELPe speech coder. For the purposes of this specification, only the general parameter nature of TSVCIS will be characterized. Depending on the bandwidth available (and FEC requirements), a varying number of TSVCIS specific speech coder parameters need to be transported. These are first byte-packed and then conveyed from encoder to decoder. (now) In addition to the augmented speech data, the TSVCIS specification identifies which speech coder and framing bits are to be encrypted, and how they are protected by forward error correction (FEC) techniques (using block codes). At the RTP transport layer, only the speech-coder-related bits need to be considered and are conveyed in unencrypted form. In most IP-based network deployments, standard link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type 1 Ethernet encryptors) would be used to secure the RTP speech contents. TSVCIS augmented speech data is derived from the signal processing and data already performed by the MELPe speech coder. For the purposes of this specification, only the general parameter nature of TSVCIS will be characterized. Depending on the bandwidth available (and FEC requirements), a varying number of TSVCIS-specific speech coder parameters need to be transported. These are first byte-packed and then conveyed from encoder to decoder. Section 3, last sentence paragraph 3 - Suggested edit by reviewer (was) When more than one codec data frame is present in a single RTP packet, the timestamp is, as always, that of the oldest data frame represented in the RTP packet. (now) When more than one codec data frame is present in a single RTP packet, the timestamp specified is that of the oldest data frame represented in the RTP packet. Section 3.1, last paragraph - Clarified permission for MELP 600 = end-to-end framing bit (was) It should be noted that CODB for both the 2400 and 600 bps modes MAY deviate from the values in Table 1 when bit 55 is used as an end-to- end framing bit. Frame decoding would remain distinct as CODA being zero on its own would indicate a 7-byte frame for either rate and the use of 600 bps speech coding could be deduced from the RTP timestamp (and anticipated by the SDP negotiations). (now) It should be noted that CODB for MELPe 600 bps mode MAY deviate from the value in Table 1 when bit 55 is used as an end-to-end framing bit. Frame decoding would remain distinct as CODA being zero on its own would indicate a 7-byte frame for either 2400 or 600 bps rate and the use of 600 bps speech coding could be deduced from the RTP timestamp (and anticipated by the SDP negotiations). Section 3.2, first paragraph - Clarifications requested by reviewers (was) The TSVCIS augmented speech data as packed parameters MUST be placed immediately after a corresponding MELPe 2400 bps payload in the same RTP packet. The packed parameters are counted in octets (TC). In the preferred placement, shown in Figure 6, a single trailing octet SHALL be appended to include a two-bit rate code, CODA and CODB, (both bits set to one) and a six-bit modified count (MTC). The special modified count value of all ones (representing a MTC value of 63) SHALL NOT be used for this format as it is used as the indicator for the alternate packing format shown next. In a standard implementation, the TSVCIS speech coder uses a minimum of 15 octets for parameters in octet packed form. The modified count (MTC) MUST be reduced by 15 from the full octet count (TC). Computed MTC =3D = TC- 15. This accommodates a maximum of 77 parameter octets (maximum value of MTC is 62, 77 is the sum of 62+15). =20 (now) The TSVCIS augmented speech data as packed parameters MUST be placed immediately after a corresponding MELPe 2400 bps payload in the same RTP packet. The packed parameters are counted in octets (TC). The preferred placement SHOULD be used for TSVCIS payloads with TC less than or equal to 77 octets, is shown in Figure 6. In the preferred placement, a single trailing octet SHALL be appended to include a two-bit rate code, CODA and CODB, (both bits set to one) and a six- bit modified count (MTC). The special modified count value of all ones (representing a MTC value of 63) SHALL NOT be used for this format as it is used as the indicator for the alternate packing format shown next. In a standard implementation, the TSVCIS speech coder uses a minimum of 15 octets for parameters in octet packed form. The modified count (MTC) MUST be reduced by 15 from the full octet count (TC). Computed MTC =3D TC-15. This accommodates a = maximum of 77 parameter octets (maximum value of MTC is 62, 77 is the sum of 62+15). Section 3.3, first paragraph - Suggested edit by reviewer (was) A TSVCIS RTP packet consists of zero or more TSVCIS coder frames (each consisting of MELPe and TSVCIS coder data) followed by zero or one MELPe comfort noise frame. The presence of a comfort noise frame can be determined by its rate code bits in its last octet. (now) A TSVCIS RTP packet payload consists of zero or more consecutive TSVCIS coder frames (each consisting of MELPe 2400 and TSVCIS coder data), with the oldest frame first, followed by zero or one MELPe comfort noise frame. The presence of a comfort noise frame can be determined by its rate code bits in its last octet. Section 3.3, fourth paragraph - Clarification requested by reviewers (was) TSVCIS coder frames in a single RTP packet MAY be of different coder bitrates. With the exception for the variable length TSVCIS parameter frames, the coder rate bits in the trailing byte identify the contents and length as per Table 1. (now) TSVCIS coder frames in a single RTP packet MAY have varying TSVCIS parameter octet counts. Its packed parameter octet count (length) is indicated in the trailing byte(s). All MELPe frames in a single RTP packet MUST be of the same coder bitrate. For all MELPe coder frames, the coder rate bits in the trailing byte identify the contents and length as per Table 1. Section 4.1 - Editor note removed Section 4.1 - Change controller is now (now) Change controller: IETF, contact Section 5, first paragraph - Suggested edits by reviewers (was) A primary application of TSVCIS is for radio communications of voice conversations, and discontinuous transmissions are normal. When TSVCIS is used in an IP network, TSVCIS RTP packet transmissions may cease and resume frequently. RTP synchronization source (SSRC) sequence number gaps indicate lost packets to be filled by PLC, while abrupt loss of RTP packets indicates intended discontinuous transmissions. (now) A primary application of TSVCIS is for radio communications of voice conversations, and discontinuous transmissions are normal. When TSVCIS is used in an IP network, TSVCIS RTP packet transmissions may cease and resume frequently. RTP synchronization source (SSRC) sequence number gaps indicate lost packets to be filled by Packet Loss Concealment (PLC), while abrupt loss of RTP packets indicates intended discontinuous transmissions. Resumption of voice transmission SHOULD be indicated by the RTP marker bit (M) set to 1. Section 10 - Added reference (added) [RFC8088] Westerlund, M., "How to Write an RTP Payload Format", RFC 8088, DOI 10.17487/RFC8088, May 2017,=20 . -------------------------------------------------------------------------= ------------------------ -----Original Message----- From: Roni Even (A) =20 Sent: Sunday, October 6, 2019 2:09 AM To: victor.demjanenko@vocal.com; 'Benjamin Kaduk' ; 'The = IESG' Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' = ; avtcore-chairs@ietf.org; avt@ietf.org; = 'Dave Satterlee (Vocal)' Subject: RE: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: = (with DISCUSS and COMMENT) Hi, About the reference to TSVCIS. The RTP payload is about how to encapsulate the payload in an RTP = packet. The objective is to define how an RTP stack can insert the = tsvcis frames and extract the tsvcis frames from the RTP packet. = Typically it is not required to understand the payload structure in = order to be able to perform the encapsulation. This is why the reference to the payload is Informational and we did not = require to have it publically available. If there is a need to = understand the payload itself for the encapsulating than we need more = information in the RTP payload specification and a publically available = normative reference. I think this is not the case here Roni Even=20 AVTCore co-chair (ex Payload) -----Original Message----- From: victor.demjanenko@vocal.com [mailto:victor.demjanenko@vocal.com]=20 Sent: Saturday, October 05, 2019 12:18 AM To: 'Benjamin Kaduk'; 'The IESG' Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen'; = avtcore-chairs@ietf.org; avt@ietf.org; 'Victor Demjanenko, Ph.D.'; 'Dave = Satterlee (Vocal)' Subject: RE: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: = (with DISCUSS and COMMENT) Everyone, Thanks for the comments. I think I mis-understood the ambiguity with = respect to to changing rates within a RTP packet. That was not plan. = An RTP packet must have MELP speech frames of the same rate. What is = possible is that the amount of augmented TSVCIS speech data may vary = from one speech frame to the next. This allows for a dynamic VDR as = suggested by the NRL paper. So an RTP packet may have varying TSVCIS = data but must always have MELPe 2400 data. Again backwards parsing is necessary but the timestamp uniformly = increments 22.5msec per combined MELP/TSVCIS speech frame. The NRL is a good public reference on the VDR aspects. The actual = TSVCIS spec we had was FOUO so we could not replicate its detail. (I = believe a later spec is public or at least partially public. I am = trying to get this.) The opaque data is pretty obvious with the TSVCIS = spec in hand. We will address the issues/concerns raised next week. Other business = had priority. Thank you and enjoy the weekend. Regards, Victor & Dave -----Original Message----- From: Benjamin Kaduk via Datatracker =20 Sent: Wednesday, October 2, 2019 10:40 PM To: The IESG Cc: draft-ietf-payload-tsvcis@ietf.org; Ali Begen = ; avtcore-chairs@ietf.org; = ali.begen@networked.media; avt@ietf.org Subject: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with = DISCUSS and COMMENT) Benjamin Kaduk has entered the following ballot position for draft-ietf-payload-tsvcis-03: Discuss When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-payload-tsvcis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I support Magnus' point about the time-ordering of adjacent frames in a = packet. Additionally, I am not sure that there's quite enough here to be = interoperably implementable. Specifically, we seem to be lacking a = description of how an encoder or decoder knows which TSVCIS parameters, = and in what order, to byte-pack or unpack, respectively. One might = surmise that there is a canonical listing in [TSVCIS], but this document = does not say that, and furthermore [TSVCIS] is only listed as an = informative reference. (I couldn't get my hands on my copy, at least on = short notice.) If we limited ourselves to treating the TSVCIS = parameters as an entirely opaque blob (codec, convey these N octets to = the peer with the appropriate one- or two-byte trailer for payload type = identification and framing), that would be interoperably implementable, = since the black-box bits are up to some other codec to interpret. In a similar vein, we mention but do not completely specify the = potential for using CODB as an end-to-end framing bit, in Section 3.1 = (see Comment), which is not interoperably implementable without further = details. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Where is [TSVCIS] available? Is [NRLVDR] the same as https://apps.dtic.mil/dtic/tr/fulltext/u2/a588068.pdf ? A URL in the = references would be helpful. Is additional TSVCIS data only present after 2400bps MELPe and the first = thing to get dropped under bandwidth pressure? The abstract and = introduction imply this by calling out MELPe 2400 bps speech parameters = explicitly, but Section 3 says that TSVCIS augments standard 600, 1200, = and 2400 bps MELP frames. It's helpful that Section 3.3 gives some general guidance for decoding = this payload type ("[t]he way to determine the number of TSVCIS/MELPe = frames is to identify each frame type and length"), but I think some = generic considerations would be very helpful to the reader much earlier, = along the lines of "MELPe and TSVCIS data payloads are decoded from the = end, using the CODA and CODB (and, if necessary, CODC and others) bits = to determine the type of payload. For MELPe payloads the type also = indicates the payload length, whereas for TSVCIS data an additional = length field is present, in one of two possible formats. A TSVCIS coder = frame consists of a MELPe data payload followed by zero or one TSVCIS = data payload; after the TSVCIS payload's presence/length is determined, = then the preceding MELPe payload can be determined and decoded. Per = Section 3.3, multiple TSVCIS frames can be present in a single RTP = packet." This (or something like it) would also serve to clarify the = role of the COD* bits, which is otherwise only implicitly introduced. Section 1.1 RFC 2736 is BCP 36 (but it's updated by RFC 8088 which is for some = reason an Informational document and not part of BCP 36?!). Section 2 In addition to the augmented speech data, the TSVCIS specification identifies which speech coder and framing bits are to be encrypted, and how they are protected by forward error correction (FEC) techniques (using block codes). At the RTP transport layer, only the speech coder related bits need to be considered and are conveyed in unencrypted form. In most IP-based network deployments, standard Am I reading this correctly that this text is just summarizing what's in = the TSVCIS spec in terms of what needs to be in unencrypted form, so the = "only the speech coder related bits[...]" is not new information from = this document? I'm not sure I agree with the conclusion, regardless -- = won't the (MELPe) speech coder bits be enough to convey the semantic = content of the audio stream, something that one might desire to keep = confidential? link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type 1 Ethernet encryptors) would be used to secure the RTP speech contents. Further, it is desirable to support the highest voice quality between endpoints which is only possible without the overhead of FEC. I think I'm missing a step in how this conclusion was reached. TSVCIS will be characterized. Depending on the bandwidth available (and FEC requirements), a varying number of TSVCIS specific speech coder parameters need to be transported. These are first byte-packed and then conveyed from encoder to decoder. Per the Discuss point, how do I know which parameters need to be = transported, and in what order? Byte packing of TSVCIS speech data into packed parameters is processed as per the following example: Three-bit field: bits A, B, and C (A is MSB, C is LSB) Five-bit field: bits D, E, F, G, and H (D is MSB, H is LSB) MSB LSB 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | H | G | F | E | D | C | B | A | +------+------+------+------+------+------+------+------+ This packing method places the three-bit field "first" in the lowest bits followed by the next five-bit field. Parameters may be split between octets with the most significant bits in the earlier octet. Any unfilled bits in the last octet MUST be filled with zero. I agree with Adam that this is very unclear. A is the MSB of the = three-bit field but the LSB of the octet overall? We probably need an example of splitting a parameter across octets as = well, to get the bit ordering right. Section 3.1 It should be noted that CODB for both the 2400 and 600 bps modes MAY deviate from the values in Table 1 when bit 55 is used as an end-to- end framing bit. Frame decoding would remain distinct as CODA being Where is the use of CODB as an end-to-end framing bit defined? If we're = going to provide neither a complete description of how to do it nor a = reference to a better description, we probably shouldn't mention it at = all. Section 3.2 RTP packet. The packed parameters are counted in octets (TC). In the preferred placement, shown in Figure 6, a single trailing octet SHALL be appended to include a two-bit rate code, CODA and CODB, I'd consider saying something about this being the preferred format ("placement") due to its shorter length than the alternative, and say = that it "SHOULD be used for TSVCIS payloads with TC less than or equal = to 77 octetes". Section 3.3 When a longer packetization interval is used, is that indicated by = signaling or RTP timestamps or otherwise? TSVCIS coder frames in a single RTP packet MAY be of different coder bitrates. With the exception for the variable length TSVCIS parameter frames, the coder rate bits in the trailing byte identify the contents and length as per Table 1. Maybe also note that the penultimate octet gives the length there? Information describing the number of frames contained in an RTP packet is not transmitted as part of the RTP payload. The way to determine the number of TSVCIS/MELPe frames is to identify each frame type and length thereby counting the total number of octets within the RTP packet. terminology nit: if a frame is the combination of MELPe and TSVCIS = payload data units then there are two layres of decoding to get a length = for the frame, since we have to get the TSVCIS length and then the MELPe = length. Section 4.2 Parameter "ptime" cannot be used for the purpose of specifying the nit: missing article ("The parameter") will be impossible to distinguish which mode is about to be used (e.g., when ptime=3D68, it would be impossible to distinguish if the packet is carrying one frame of 67.5 ms or three frames of 22.5 ms). So how is the operating mode determined, then? (I think this is the same question I asked above) Section 4.4 For example, if offerer bitrates are "2400,600" and answer bitrates are "600,2400", the initial bitrate is 600. If other bitrates are provided by the answerer, any common bitrate between the offer and answer MAY be used at any time in the future. Activation of these other common bitrates is beyond the scope of this document. It seems important to specify whether this requires a new O/A exchange = or can be done "spontaneously" by just encoding different frame types. (It seems like the latter is possible, on first glance, and this is = implied by Section 3.3's discussion of mixing them in a single packet.) Section 5 Please expand PLC at first use (not second). Section 6 I don't understand the PLC usage. Is the idea that a receiver, on = seeing an SSRC gap, constructs fictitious PLC frames to "fill the gap" and passes the resulting stream to the decoder? Section 8 and important considerations in [RFC7201]. Applications SHOULD use one or more appropriate strong security mechanisms. The rest of this section discusses the security-impacting properties of the payload format itself. I thought we described TSVCIS itself (much earlier in the document) as = requiring encryption for some data; wouldn't that translate to a "MUST" here and not a "SHOULD"? From nobody Fri Oct 25 05:52:09 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 324EE1200B5 for ; Fri, 25 Oct 2019 05:52:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <157200792813.4509.4514879593897788951.idtracker@ietfa.amsl.com> Date: Fri, 25 Oct 2019 05:52:08 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 12:52:08 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-10-31 Reviewer LC end Draft Yoav Nir R2019-10-09 draft-ietf-ace-cwt-proof-of-possession-09 For telechat 2019-12-05 Reviewer LC end Draft Takeshi Takahashi 2019-11-04 draft-ietf-netmod-yang-data-ext-04 Last calls: Reviewer LC end Draft Derek Atkins 2019-11-05 draft-ietf-mpls-rmr-12 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Daniel Gillmor 2018-03-19 draft-gutmann-scep-14 Leif Johansson 2019-09-02 draft-ietf-tls-sni-encryption-08 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Sandra Murphy 2019-07-08 draft-ietf-i2nsf-applicability-18 Yoav Nir R2019-10-09 draft-ietf-ace-cwt-proof-of-possession-09 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Stefan Santesson 2019-10-10 draft-ietf-payload-rtp-ttml-04 Melinda Shore 2019-11-07 draft-thaler-iftype-reg-05 Valery Smyslov R2019-11-07 draft-ietf-cellar-ebml-13 Takeshi Takahashi 2019-11-04 draft-ietf-netmod-yang-data-ext-04 Sean Turner 2019-11-07 draft-ietf-ospf-ospfv2-hbit-10 Carl Wallace 2019-11-07 draft-ietf-pim-drlb-13 David Waltermire 2019-08-07 draft-ietf-oauth-jwt-introspection-response-08 Christopher Wood 2019-11-06 draft-ietf-dtn-tcpclv4-15 Paul Wouters 2019-11-06 draft-ietf-ippm-initial-registry-12 Liang Xia 2019-11-06 draft-ietf-ippm-metric-registry-20 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Tim Polk 2019-10-04 draft-ietf-lwig-curve-representations-08 Next in the reviewer rotation: John Bradley Nancy Cam-Winget Shaun Cooley Roman Danyliw Alan DeKok Linda Dunbar Donald Eastlake Shawn Emery Stephen Farrell Daniel Franke From nobody Fri Oct 25 20:07:29 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7835E120026; Fri, 25 Oct 2019 20:07:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Melinda Shore via Datatracker To: Cc: last-call@ietf.org, draft-thaler-iftype-reg.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Melinda Shore Message-ID: <157205924739.2732.16069605902643848050@ietfa.amsl.com> Date: Fri, 25 Oct 2019 20:07:27 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-thaler-iftype-reg-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2019 03:07:27 -0000 Reviewer: Melinda Shore Review result: Has Issues This document is an update to RFC 2863, providing revised guidelines for the definition of new interface types and tunnel types. In doing so it introduces some guidance for the development of YANG ifType and tunnelType modules, which was not previously covered elsewhere. To be honest I found the writing occasionally difficult to follow, as the text was not as well-structured as we usually see in mature IETF documents. Even the abstract doesn't really get to the point until the last sentence. Similarly, section 7 opens with a comment on some misguidance on request submission in the MIB module, while I think it would be much clearer to say "Requests may be submitted to IANA via email at iana@iana.org, or via a web form at https://www.iana.org/form/iftype" followed by some text pointing out the misguidance. The request to IANA to update the MIB module could be dropped down into IANA considerations (section 8). Nit: In section 7 "iana&iana.org" should be "iana@iana.org." Security considerations: It might be reasonable to argue that a document providing guidelines for registering a new MIB or YANG interface type module has no security considerations, but it's worth noting that other documents do include some text. See, for example, RFC 6117 on the registration of ENUM services, which does provide guidance on security considerations to authors of new Enumservice Types), and RFC 8436, on DSCP Pool 3 IANA registration procedures, points authors to the documents defining new DSCP values. Sections 6.3.1 and 6.3.2 could/should provide some broad guidance on writing security considerations for new ifType and tunnelType modules. So, I think there's a bit more to say there but ultimately this one would be up to the OPS ADs. From nobody Mon Oct 28 20:17:57 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07525120047; Mon, 28 Oct 2019 20:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0Ebb-AM_PHl; Mon, 28 Oct 2019 20:17:48 -0700 (PDT) Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 E6BB8120046; Mon, 28 Oct 2019 20:17:44 -0700 (PDT) Received: by mail-yb1-xb2a.google.com with SMTP id h202so4874658ybg.13; Mon, 28 Oct 2019 20:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0SqsQqGhJSXSYi9gr3RIuFwq9w7blgEQRYYkvWBjIxQ=; b=HJ7EeUxe4IGB78EEEraxCjHglw8Zxf2v2LYwaVRtQbV4x9WDCijkF40+KXAaIWlYx5 WnJ/0OaTVWkrYSzYCRQvQ9B1NFlf5uD1N4onukFSpqL5m4IJgrQbK/Yq9IcTjRZDlLbi rwsr3p/epTgUloNHQAL9HqBq5txmck4+ZCfJc4uvzPQ3zj39rReR+2IxGG8+/YeI3/YJ GqY/DMGRH6Lb7WyP5JAwFbJgTgyKuQERe2hGGcsvbWFnlGNSckjInBuWCfTh/mQx1+x2 zC3ZY0gU9ASmsaEtAP/1qs9RTDobx+aBQ0x0HeWUbb8t5SmghYP6jdg3DvHG0tBFvu3y llHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0SqsQqGhJSXSYi9gr3RIuFwq9w7blgEQRYYkvWBjIxQ=; b=Wdgs/twuji6fSjSrlnfF0LTS2FbZy160PSYQ+TDnb0I2glMX9B6ajC8OKNh1jWJkpA mv4B66zTs4g0NhyCNaAmUup6VKOD0j0GIC74GJ1bmFObjWH3cllvWt5Lkrrd9Jrz6LRx rsZ1We9G/oRYwkMHqtSyJfMlBdNx/6BdgoIpo2K7CxrR3Rhvsr4UxF+AUkk3PQbd+2dn HvLQFtWTW1uN/hvlVrIX8nXjPp7XD/45VPpMXzSv4yJ2IYLRTtH6vp+v/W7aX1xQJRY+ Bi103d86t0DAJD9hcqbhBBsWmKaPt94gNqGIiVT00FGCQLTxWRhosi3o696o1+PScLAd w01Q== X-Gm-Message-State: APjAAAVBt5Nnx/NI2SkyyMB3uJSk/aNtq2CdM3xoQk0iW39Zsq6I41gM dwdQyS/7BGvGDPYuGo5ESJ6mD0sr X-Google-Smtp-Source: APXvYqxQdngGwSBabcArW/bAJG6dJshRlUED5FaKJ1//6JejmQUyNrRpnHlGl6VrrBrh70KBf3Xetw== X-Received: by 2002:a25:b845:: with SMTP id b5mr6139494ybm.288.1572319063879; Mon, 28 Oct 2019 20:17:43 -0700 (PDT) Received: from [10.0.0.2] (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id q2sm3449936ywd.12.2019.10.28.20.17.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Oct 2019 20:17:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Suresh Krishnan In-Reply-To: <157205924739.2732.16069605902643848050@ietfa.amsl.com> Date: Mon, 28 Oct 2019 23:17:42 -0400 Cc: secdir@ietf.org, last-call@ietf.org, draft-thaler-iftype-reg.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <79B1F77E-EE3F-43D9-9FB4-2C548C64D8CC@gmail.com> References: <157205924739.2732.16069605902643848050@ietfa.amsl.com> To: Melinda Shore X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-thaler-iftype-reg-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2019 03:17:50 -0000 Thanks a lot for your review Melinda! Authors, will you get a chance to = look at this before the submission deadline? Regards Suresh > On Oct 25, 2019, at 11:07 PM, Melinda Shore via Datatracker = wrote: >=20 > Reviewer: Melinda Shore > Review result: Has Issues >=20 > This document is an update to RFC 2863, providing revised > guidelines for the definition of new interface types and > tunnel types. In doing so it introduces some guidance for > the development of YANG ifType and tunnelType modules,=20 > which was not previously covered elsewhere. >=20 > To be honest I found the writing occasionally difficult > to follow, as the text was not as well-structured as we > usually see in mature IETF documents. Even the abstract > doesn't really get to the point until the last sentence. > Similarly, section 7 opens with a comment on some misguidance > on request submission in the MIB module, while I > think it would be much clearer to say "Requests may be > submitted to IANA via email at iana@iana.org, or via > a web form at https://www.iana.org/form/iftype" followed > by some text pointing out the misguidance. The=20 > request to IANA to update the MIB module could be dropped > down into IANA considerations (section 8). >=20 > Nit: In section 7 "iana&iana.org" should be "iana@iana.org." >=20 > Security considerations: It might be reasonable to argue > that a document providing guidelines for registering a=20 > new MIB or YANG interface type module has no security considerations, > but it's worth noting that other documents do include some text. =20 > See, for example, RFC 6117 on the registration of ENUM services, > which does provide guidance on security considerations to authors=20 > of new Enumservice Types), and RFC 8436, on DSCP Pool 3 IANA > registration procedures, points authors to the documents > defining new DSCP values. Sections 6.3.1 and 6.3.2 could/should > provide some broad guidance on writing security considerations > for new ifType and tunnelType modules. >=20 > So, I think there's a bit more to say there but ultimately this one=20 > would be up to the OPS ADs. >=20 > --=20 > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call From nobody Tue Oct 29 11:26:28 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808FC120B66; Tue, 29 Oct 2019 11:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.6 X-Spam-Level: *** X-Spam-Status: No, score=3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, GB_SUMOF=5, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfS_UKpOqmDN; Tue, 29 Oct 2019 11:26:23 -0700 (PDT) Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) (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 E4D97120B61; Tue, 29 Oct 2019 11:26:21 -0700 (PDT) Received: by mail-io1-f66.google.com with SMTP id s17so8750548iol.12; Tue, 29 Oct 2019 11:26:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ND5VM80o5JwjIStlFvnDAX7TSBnjTJyz9AD5f6CK5fE=; b=U/ivGC7B0r4+r1zXs1TZFfzrsFotYHmnl6i4+uo5pIafRIDeN8znhotra+p452oFeB HrV22Ma2bqsAXr7IPVIgWINZO+GGJgH2HQ44scYXPmbkDgtPwm9uXR1jxjZWqdl3SPuZ Jg1JH2rgO/fdfjsf6Rah9W9VG4o2fHMkzqeSV6wwX1em4uA1V9SjKHB4VmVuQ0fex2hl UXd8RCY9IoiMmfS4fRgHhosE33o9ywfPb4L5wRRWbf154vmDtMJXkyhspP+HX+rLaaxM p6DvoUOUbgV8wbhusMwNMXS+uJKbJ4dHVqyZsD169BTlIQrI4S3OZOCvqbCSM2aKbmBR OkBQ== X-Gm-Message-State: APjAAAXzUKO+xkgrhZ9gABIDV2Xum/U1R2DsgLSA0sGqd+/RvQ91Mx9h PCKZwEjMsUZHTLF45ILlCGwg4IHPRemh3FM6lcE= X-Google-Smtp-Source: APXvYqwAslAmslScpMg/q8GKlebdldCo62dIXblyWwvuuPTMHh6ckl8oimbLJQdgnCVB5t9EIWxx3YvcW2foICm6fF4= X-Received: by 2002:a02:3849:: with SMTP id v9mr3986055jae.70.1572373580627; Tue, 29 Oct 2019 11:26:20 -0700 (PDT) MIME-Version: 1.0 References: <157007038502.8860.1558861534319247512.idtracker@ietfa.amsl.com> <001601d57af9$405efcf0$c11cf6d0$@vocal.com> <6E58094ECC8D8344914996DAD28F1CCD23D79BC0@DGGEMM506-MBX.china.huawei.com> <034a01d58a73$f4d3a1c0$de7ae540$@vocal.com> <037e01d58a92$72287510$56795f30$@vocal.com> In-Reply-To: <037e01d58a92$72287510$56795f30$@vocal.com> From: Barry Leiba Date: Tue, 29 Oct 2019 14:26:09 -0400 Message-ID: To: victor.demjanenko@vocal.com Cc: "Roni Even (A)" , Benjamin Kaduk , The IESG , Catherine Meadows , IETF SecDir , draft-ietf-payload-tsvcis@ietf.org, Ali Begen , avtcore-chairs@ietf.org, avt@ietf.org, "Dave Satterlee (Vocal)" , IETF discussion list , draft-ietf-payload-tsvcis.all@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2019 18:26:26 -0000 Ben, does the -04 version address everything? Barry On Thu, Oct 24, 2019 at 1:42 PM wrote: > > I forgot to address security comments in one email. The changes are: > > Section 8, second paragraph - Suggested edit by reviewer > > (was) > This RTP payload format and the TSVCIS decoder do not exhibit any > significant non-uniformity in the receiver-side computational > complexity for packet processing and thus are unlikely to pose a > denial-of-service threat due to the receipt of pathological data. > Additionally, the RTP payload format does not contain any active > content. > > (now) > This RTP payload format and the TSVCIS decoder, to the best of our > knowledge, do not exhibit any significant non-uniformity in the > receiver-side computational complexity for packet processing and thus > are unlikely to pose a denial-of-service threat due to the receipt of > pathological data. Additionally, the RTP payload format does not > contain any active content. > > > Section 8, third paragraph - Suggested edit by reviewer > > (was) > Please see the security considerations discussed in [RFC6562] > regarding VAD and its effect on bitrates. > > (now) > Please see the security considerations discussed in [RFC6562] > regarding Voice Activity Detect (VAD) and its effect on bitrates. > > Victor > > -----Original Message----- > From: victor.demjanenko@vocal.com > Sent: Thursday, October 24, 2019 10:05 AM > To: 'Roni Even (A)' ; 'Benjamin Kaduk' ; 'The IESG' > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' ; avtcore-chairs@ietf.org; avt@ietf.org; 'Dave Satterlee (Vocal)' > Subject: RE: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (w= ith DISCUSS and COMMENT) > > Hi Everyone, > > First we want to thank everyone for their review and comments for this dr= aft RFC. We believe we reviewed all the comments and suggestions and incor= porated them adequately in the next draft (04). We'd like to send out this= list of exact changes in case anyone has additional comments or thinks the= clarifications are inadequate. We would be most happy to address concerns= before publishing draft 04 tomorrow. > > With so many emails from a half dozen or more reviewers, we apologize tha= t we cannot address each sender individually. We hope this detail is suffi= cient for everyone. > > Again, many thanks to all. > > Victor & Dave > > -------------------------------------------------------------------------= --------------------- > > Section 1.1 - Suggested reference to RFC 8088 added. > > (was) > Best current practices for writing an RTP payload format > specification were followed [RFC2736]. > > (now) > Best current practices for writing an RTP payload format > specification were followed [RFC2736] [RFC8088]. > > > Section 2, paragraphs 3 and 4 - Suggested edits by reviewers > > (was) > In addition to the augmented speech data, the TSVCIS specification > identifies which speech coder and framing bits are to be encrypted, > and how they are protected by forward error correction (FEC) > techniques (using block codes). At the RTP transport layer, only the > speech coder related bits need to be considered and are conveyed in > unencrypted form. In most IP-based network deployments, standard > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type > 1 Ethernet encryptors) would be used to secure the RTP speech > contents. Further, it is desirable to support the highest voice > quality between endpoints which is only possible without the overhead > of FEC. > > TSVCIS augmented speech data is derived from the signal processing > and data already performed by the MELPe speech coder. For the > purposes of this specification, only the general parameter nature of > TSVCIS will be characterized. Depending on the bandwidth available > (and FEC requirements), a varying number of TSVCIS specific speech > coder parameters need to be transported. These are first byte-packed > and then conveyed from encoder to decoder. > > (now) > In addition to the augmented speech data, the TSVCIS specification > identifies which speech coder and framing bits are to be encrypted, > and how they are protected by forward error correction (FEC) > techniques (using block codes). At the RTP transport layer, only the > speech-coder-related bits need to be considered and are conveyed in > unencrypted form. In most IP-based network deployments, standard > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type > 1 Ethernet encryptors) would be used to secure the RTP speech > contents. > > TSVCIS augmented speech data is derived from the signal processing > and data already performed by the MELPe speech coder. For the > purposes of this specification, only the general parameter nature of > TSVCIS will be characterized. Depending on the bandwidth available > (and FEC requirements), a varying number of TSVCIS-specific speech > coder parameters need to be transported. These are first byte-packed > and then conveyed from encoder to decoder. > > > Section 3, last sentence paragraph 3 - Suggested edit by reviewer > > (was) > When more than one codec data frame is > present in a single RTP packet, the timestamp is, as always, that of > the oldest data frame represented in the RTP packet. > > (now) > When more than one codec data frame is > present in a single RTP packet, the timestamp specified is that of > the oldest data frame represented in the RTP packet. > > > Section 3.1, last paragraph - Clarified permission for MELP 600 end-to-en= d framing bit > > (was) > It should be noted that CODB for both the 2400 and 600 bps modes MAY > deviate from the values in Table 1 when bit 55 is used as an end-to- > end framing bit. Frame decoding would remain distinct as CODA being > zero on its own would indicate a 7-byte frame for either rate and the > use of 600 bps speech coding could be deduced from the RTP timestamp > (and anticipated by the SDP negotiations). > > (now) > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > the value in Table 1 when bit 55 is used as an end-to-end framing > bit. Frame decoding would remain distinct as CODA being zero on its > own would indicate a 7-byte frame for either 2400 or 600 bps rate and > the use of 600 bps speech coding could be deduced from the RTP > timestamp (and anticipated by the SDP negotiations). > > > Section 3.2, first paragraph - Clarifications requested by reviewers > > (was) > The TSVCIS augmented speech data as packed parameters MUST be placed > immediately after a corresponding MELPe 2400 bps payload in the same > RTP packet. The packed parameters are counted in octets (TC). In > the preferred placement, shown in Figure 6, a single trailing octet > SHALL be appended to include a two-bit rate code, CODA and CODB, > (both bits set to one) and a six-bit modified count (MTC). The > special modified count value of all ones (representing a MTC value of > 63) SHALL NOT be used for this format as it is used as the indicator > for the alternate packing format shown next. In a standard > implementation, the TSVCIS speech coder uses a minimum of 15 octets > for parameters in octet packed form. The modified count (MTC) MUST > be reduced by 15 from the full octet count (TC). Computed MTC =3D TC- > 15. This accommodates a maximum of 77 parameter octets (maximum > value of MTC is 62, 77 is the sum of 62+15). > > (now) > The TSVCIS augmented speech data as packed parameters MUST be placed > immediately after a corresponding MELPe 2400 bps payload in the same > RTP packet. The packed parameters are counted in octets (TC). The > preferred placement SHOULD be used for TSVCIS payloads with TC less > than or equal to 77 octets, is shown in Figure 6. In the preferred > placement, a single trailing octet SHALL be appended to include a > two-bit rate code, CODA and CODB, (both bits set to one) and a six- > bit modified count (MTC). The special modified count value of all > ones (representing a MTC value of 63) SHALL NOT be used for this > format as it is used as the indicator for the alternate packing > format shown next. In a standard implementation, the TSVCIS speech > coder uses a minimum of 15 octets for parameters in octet packed > form. The modified count (MTC) MUST be reduced by 15 from the full > octet count (TC). Computed MTC =3D TC-15. This accommodates a maximu= m > of 77 parameter octets (maximum value of MTC is 62, 77 is the sum of > 62+15). > > > Section 3.3, first paragraph - Suggested edit by reviewer > > (was) > A TSVCIS RTP packet consists of zero or more TSVCIS coder frames > (each consisting of MELPe and TSVCIS coder data) followed by zero or > one MELPe comfort noise frame. The presence of a comfort noise frame > can be determined by its rate code bits in its last octet. > > (now) > A TSVCIS RTP packet payload consists of zero or more consecutive > TSVCIS coder frames (each consisting of MELPe 2400 and TSVCIS coder > data), with the oldest frame first, followed by zero or one MELPe > comfort noise frame. The presence of a comfort noise frame can be > determined by its rate code bits in its last octet. > > > Section 3.3, fourth paragraph - Clarification requested by reviewers > > (was) > TSVCIS coder frames in a single RTP packet MAY be of different coder > bitrates. With the exception for the variable length TSVCIS > parameter frames, the coder rate bits in the trailing byte identify > the contents and length as per Table 1. > > (now) > TSVCIS coder frames in a single RTP packet MAY have varying TSVCIS > parameter octet counts. Its packed parameter octet count (length) is > indicated in the trailing byte(s). All MELPe frames in a single RTP > packet MUST be of the same coder bitrate. For all MELPe coder > frames, the coder rate bits in the trailing byte identify the > contents and length as per Table 1. > > > Section 4.1 - Editor note removed > > > Section 4.1 - Change controller is now > > (now) > Change controller: IETF, contact > > > Section 5, first paragraph - Suggested edits by reviewers > > (was) > A primary application of TSVCIS is for radio communications of voice > conversations, and discontinuous transmissions are normal. When > TSVCIS is used in an IP network, TSVCIS RTP packet transmissions may > cease and resume frequently. RTP synchronization source (SSRC) > sequence number gaps indicate lost packets to be filled by PLC, while > abrupt loss of RTP packets indicates intended discontinuous > transmissions. > > (now) > A primary application of TSVCIS is for radio communications of voice > conversations, and discontinuous transmissions are normal. When > TSVCIS is used in an IP network, TSVCIS RTP packet transmissions may > cease and resume frequently. RTP synchronization source (SSRC) > sequence number gaps indicate lost packets to be filled by Packet > Loss Concealment (PLC), while abrupt loss of RTP packets indicates > intended discontinuous transmissions. Resumption of voice > transmission SHOULD be indicated by the RTP marker bit (M) set to 1. > > > Section 10 - Added reference > > (added) > [RFC8088] Westerlund, M., "How to Write an RTP Payload Format", > RFC 8088, DOI 10.17487/RFC8088, May 2017, > . > > -------------------------------------------------------------------------= ------------------------ > > > -----Original Message----- > From: Roni Even (A) > Sent: Sunday, October 6, 2019 2:09 AM > To: victor.demjanenko@vocal.com; 'Benjamin Kaduk' ; 'The I= ESG' > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' ; avtcore-chairs@ietf.org; avt@ietf.org; 'Dave Satterlee (Vocal)' > Subject: RE: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (w= ith DISCUSS and COMMENT) > > Hi, > About the reference to TSVCIS. > The RTP payload is about how to encapsulate the payload in an RTP packet.= The objective is to define how an RTP stack can insert the tsvcis frames a= nd extract the tsvcis frames from the RTP packet. Typically it is not requ= ired to understand the payload structure in order to be able to perform the= encapsulation. > This is why the reference to the payload is Informational and we did not = require to have it publically available. If there is a need to understand = the payload itself for the encapsulating than we need more information in t= he RTP payload specification and a publically available normative reference= . I think this is not the case here > > Roni Even > > AVTCore co-chair (ex Payload) > > -----Original Message----- > From: victor.demjanenko@vocal.com [mailto:victor.demjanenko@vocal.com] > Sent: Saturday, October 05, 2019 12:18 AM > To: 'Benjamin Kaduk'; 'The IESG' > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen'; avtcore-chairs@ietf.= org; avt@ietf.org; 'Victor Demjanenko, Ph.D.'; 'Dave Satterlee (Vocal)' > Subject: RE: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (w= ith DISCUSS and COMMENT) > > Everyone, > > Thanks for the comments. I think I mis-understood the ambiguity with res= pect to to changing rates within a RTP packet. That was not plan. An RTP = packet must have MELP speech frames of the same rate. What is possible is = that the amount of augmented TSVCIS speech data may vary from one speech fr= ame to the next. This allows for a dynamic VDR as suggested by the NRL pap= er. So an RTP packet may have varying TSVCIS data but must always have MEL= Pe 2400 data. > > Again backwards parsing is necessary but the timestamp uniformly incremen= ts 22.5msec per combined MELP/TSVCIS speech frame. > > The NRL is a good public reference on the VDR aspects. The actual TSVCIS= spec we had was FOUO so we could not replicate its detail. (I believe a l= ater spec is public or at least partially public. I am trying to get this.= ) The opaque data is pretty obvious with the TSVCIS spec in hand. > > We will address the issues/concerns raised next week. Other business had= priority. > > Thank you and enjoy the weekend. > > Regards, > > Victor & Dave > > -----Original Message----- > From: Benjamin Kaduk via Datatracker > Sent: Wednesday, October 2, 2019 10:40 PM > To: The IESG > Cc: draft-ietf-payload-tsvcis@ietf.org; Ali Begen ; avtcore-chairs@ietf.org; ali.begen@networked.media; avt@ietf.org > Subject: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with = DISCUSS and COMMENT) > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-payload-tsvcis-03: Discuss > > When responding, please keep the subject line intact and reply to all ema= il addresses included in the To and CC lines. (Feel free to cut this introd= uctory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-payload-tsvcis/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I support Magnus' point about the time-ordering of adjacent frames in a p= acket. > > Additionally, I am not sure that there's quite enough here to be interope= rably implementable. Specifically, we seem to be lacking a description of = how an encoder or decoder knows which TSVCIS parameters, and in what order,= to byte-pack or unpack, respectively. One might surmise that there is a c= anonical listing in [TSVCIS], but this document does not say that, and furt= hermore [TSVCIS] is only listed as an informative reference. (I couldn't g= et my hands on my copy, at least on short notice.) If we limited ourselves= to treating the TSVCIS parameters as an entirely opaque blob (codec, conve= y these N octets to the peer with the appropriate one- or two-byte trailer = for payload type identification and framing), that would be interoperably i= mplementable, since the black-box bits are up to some other codec to interp= ret. > > In a similar vein, we mention but do not completely specify the potential= for using CODB as an end-to-end framing bit, in Section 3.1 (see Comment),= which is not interoperably implementable without further details. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Where is [TSVCIS] available? > > Is [NRLVDR] the same as > https://apps.dtic.mil/dtic/tr/fulltext/u2/a588068.pdf ? A URL in the ref= erences would be helpful. > > Is additional TSVCIS data only present after 2400bps MELPe and the first = thing to get dropped under bandwidth pressure? The abstract and introducti= on imply this by calling out MELPe 2400 bps speech parameters explicitly, b= ut Section 3 says that TSVCIS augments standard 600, 1200, and 2400 bps MEL= P frames. > > It's helpful that Section 3.3 gives some general guidance for decoding th= is payload type ("[t]he way to determine the number of TSVCIS/MELPe frames = is to identify each frame type and length"), but I think some generic consi= derations would be very helpful to the reader much earlier, along the lines= of "MELPe and TSVCIS data payloads are decoded from the end, using the COD= A and CODB (and, if necessary, CODC and others) bits to determine the type = of payload. For MELPe payloads the type also indicates the payload length,= whereas for TSVCIS data an additional length field is present, in one of t= wo possible formats. A TSVCIS coder frame consists of a MELPe data payload= followed by zero or one TSVCIS data payload; after the TSVCIS payload's pr= esence/length is determined, then the preceding MELPe payload can be determ= ined and decoded. Per Section 3.3, multiple TSVCIS frames can be present i= n a single RTP packet." This (or something like it) would also serve to cl= arify the role of the COD* bits, which is otherwise only implicitly introdu= ced. > > Section 1.1 > > RFC 2736 is BCP 36 (but it's updated by RFC 8088 which is for some reason= an Informational document and not part of BCP 36?!). > > Section 2 > > In addition to the augmented speech data, the TSVCIS specification > identifies which speech coder and framing bits are to be encrypted, > and how they are protected by forward error correction (FEC) > techniques (using block codes). At the RTP transport layer, only the > speech coder related bits need to be considered and are conveyed in > unencrypted form. In most IP-based network deployments, standard > > Am I reading this correctly that this text is just summarizing what's in = the TSVCIS spec in terms of what needs to be in unencrypted form, so the "o= nly the speech coder related bits[...]" is not new information from this do= cument? I'm not sure I agree with the conclusion, regardless -- won't the = (MELPe) speech coder bits be enough to convey the semantic content of the a= udio stream, something that one might desire to keep confidential? > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type > 1 Ethernet encryptors) would be used to secure the RTP speech > contents. Further, it is desirable to support the highest voice > quality between endpoints which is only possible without the overhead > of FEC. > > I think I'm missing a step in how this conclusion was reached. > > TSVCIS will be characterized. Depending on the bandwidth available > (and FEC requirements), a varying number of TSVCIS specific speech > coder parameters need to be transported. These are first byte-packed > and then conveyed from encoder to decoder. > > Per the Discuss point, how do I know which parameters need to be transpor= ted, and in what order? > > Byte packing of TSVCIS speech data into packed parameters is > processed as per the following example: > > Three-bit field: bits A, B, and C (A is MSB, C is LSB) > Five-bit field: bits D, E, F, G, and H (D is MSB, H is LSB) > > MSB LSB > 0 1 2 3 4 5 6 7 > +------+------+------+------+------+------+------+------+ > | H | G | F | E | D | C | B | A | > +------+------+------+------+------+------+------+------+ > > This packing method places the three-bit field "first" in the lowest > bits followed by the next five-bit field. Parameters may be split > between octets with the most significant bits in the earlier octet. > Any unfilled bits in the last octet MUST be filled with zero. > > I agree with Adam that this is very unclear. A is the MSB of the three-b= it field but the LSB of the octet overall? > We probably need an example of splitting a parameter across octets as wel= l, to get the bit ordering right. > > Section 3.1 > > It should be noted that CODB for both the 2400 and 600 bps modes MAY > deviate from the values in Table 1 when bit 55 is used as an end-to- > end framing bit. Frame decoding would remain distinct as CODA being > > Where is the use of CODB as an end-to-end framing bit defined? If we're = going to provide neither a complete description of how to do it nor a refer= ence to a better description, we probably shouldn't mention it at all. > > Section 3.2 > > RTP packet. The packed parameters are counted in octets (TC). In > the preferred placement, shown in Figure 6, a single trailing octet > SHALL be appended to include a two-bit rate code, CODA and CODB, > > I'd consider saying something about this being the preferred format > ("placement") due to its shorter length than the alternative, and say tha= t it "SHOULD be used for TSVCIS payloads with TC less than or equal to 77 o= ctetes". > > Section 3.3 > > When a longer packetization interval is used, is that indicated by signal= ing or RTP timestamps or otherwise? > > TSVCIS coder frames in a single RTP packet MAY be of different coder > bitrates. With the exception for the variable length TSVCIS > parameter frames, the coder rate bits in the trailing byte identify > the contents and length as per Table 1. > > Maybe also note that the penultimate octet gives the length there? > > Information describing the number of frames contained in an RTP > packet is not transmitted as part of the RTP payload. The way to > determine the number of TSVCIS/MELPe frames is to identify each frame > type and length thereby counting the total number of octets within > the RTP packet. > > terminology nit: if a frame is the combination of MELPe and TSVCIS payloa= d data units then there are two layres of decoding to get a length for the = frame, since we have to get the TSVCIS length and then the MELPe length. > > Section 4.2 > > Parameter "ptime" cannot be used for the purpose of specifying the > > nit: missing article ("The parameter") > > will be impossible to distinguish which mode is about to be used > (e.g., when ptime=3D68, it would be impossible to distinguish if the > packet is carrying one frame of 67.5 ms or three frames of 22.5 ms). > > So how is the operating mode determined, then? > (I think this is the same question I asked above) > > Section 4.4 > > For example, if offerer bitrates are "2400,600" and answer bitrates > are "600,2400", the initial bitrate is 600. If other bitrates are > provided by the answerer, any common bitrate between the offer and > answer MAY be used at any time in the future. Activation of these > other common bitrates is beyond the scope of this document. > > It seems important to specify whether this requires a new O/A exchange or= can be done "spontaneously" by just encoding different frame types. > (It seems like the latter is possible, on first glance, and this is impli= ed by Section 3.3's discussion of mixing them in a single packet.) > > Section 5 > > Please expand PLC at first use (not second). > > Section 6 > > I don't understand the PLC usage. Is the idea that a receiver, on seeing= an SSRC gap, constructs fictitious PLC frames to "fill the gap" > and passes the resulting stream to the decoder? > > Section 8 > > and important considerations in [RFC7201]. Applications SHOULD use > one or more appropriate strong security mechanisms. The rest of this > section discusses the security-impacting properties of the payload > format itself. > > I thought we described TSVCIS itself (much earlier in the document) as re= quiring encryption for some data; wouldn't that translate to a "MUST" > here and not a "SHOULD"? > > > From nobody Thu Oct 31 01:09:46 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D8A120839; Thu, 31 Oct 2019 01:09:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Valery Smyslov via Datatracker To: Cc: last-call@ietf.org, cellar@ietf.org, draft-ietf-cellar-ebml.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Valery Smyslov Message-ID: <157250938001.30360.4800852999851408878@ietfa.amsl.com> Date: Thu, 31 Oct 2019 01:09:40 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-cellar-ebml-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2019 08:09:40 -0000 Reviewer: Valery Smyslov Review result: Ready Reviewer: Valery Smyslov Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The draft describes an Extensible Binary Meta Language (EBML) format, that is a generalized file format for any type of data. As such the EBML itself doesn't include any mechanisms providing security services, besides marginal integrity check via crc32, that is optional and limited in use. The EBML relies on external mechanisms that would provide security services. The Security Considerations section describes various issues that the EBML implementations should take into consideration even in the presence of external cryptographic protection. The list of issues seems to be quite exhaustive for the EBML. I previously reviewed the -09 version of the draft. Comparing with the -09 version the Security Considerations section in the -13 version is expanded a bit, making the described security issues more clear. From nobody Thu Oct 31 12:00:17 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7974120974 for ; Thu, 31 Oct 2019 12:00:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <157254841074.30400.12778031111630323487.idtracker@ietfa.amsl.com> Date: Thu, 31 Oct 2019 12:00:10 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2019 19:00:16 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-10-31 Reviewer LC end Draft Yoav Nir R2019-10-09 draft-ietf-ace-cwt-proof-of-possession-11 For telechat 2019-12-05 Reviewer LC end Draft Takeshi Takahashi 2019-11-04 draft-ietf-netmod-yang-data-ext-04 Last calls: Reviewer LC end Draft Derek Atkins 2019-11-05 draft-ietf-mpls-rmr-12 John Bradley 2019-11-22 draft-schaad-cbor-content-01 Shaun Cooley 2019-11-12 draft-ietf-regext-login-security-05 Roman Danyliw 2019-11-12 draft-ietf-dtn-bpbis-17 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Daniel Gillmor 2018-03-19 draft-gutmann-scep-14 Dan Harkins R2019-10-03 draft-ietf-dtn-bpsec-12 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Sandra Murphy 2019-07-08 draft-ietf-i2nsf-applicability-18 Yoav Nir R2019-10-09 draft-ietf-ace-cwt-proof-of-possession-11 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Stefan Santesson 2019-10-10 draft-ietf-payload-rtp-ttml-05 Takeshi Takahashi 2019-11-04 draft-ietf-netmod-yang-data-ext-04 Sean Turner 2019-11-07 draft-ietf-ospf-ospfv2-hbit-10 Carl Wallace 2019-11-07 draft-ietf-pim-drlb-13 David Waltermire R2019-11-14 draft-ietf-hip-dex-11 David Waltermire 2019-08-07 draft-ietf-oauth-jwt-introspection-response-08 Christopher Wood 2019-11-06 draft-ietf-dtn-tcpclv4-15 Paul Wouters 2019-11-06 draft-ietf-ippm-initial-registry-12 Liang Xia 2019-11-06 draft-ietf-ippm-metric-registry-20 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Tim Polk 2019-10-04 draft-ietf-lwig-curve-representations-08 Next in the reviewer rotation: Alan DeKok Linda Dunbar Donald Eastlake Shawn Emery Stephen Farrell Daniel Franke Daniel Gillmor Tobias Gondrom Ólafur Guðmundsson Phillip Hallam-Baker From nobody Thu Oct 31 17:12:25 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848B81200EF; Thu, 31 Oct 2019 17:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z61JBh0yAYdy; Thu, 31 Oct 2019 17:12:10 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 69BAC120106; Thu, 31 Oct 2019 17:12:10 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xA10BsbU026582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Oct 2019 20:11:56 -0400 Date: Thu, 31 Oct 2019 17:11:53 -0700 From: Benjamin Kaduk To: Barry Leiba Cc: victor.demjanenko@vocal.com, "Roni Even (A)" , The IESG , Catherine Meadows , IETF SecDir , draft-ietf-payload-tsvcis@ietf.org, Ali Begen , avtcore-chairs@ietf.org, avt@ietf.org, "Dave Satterlee (Vocal)" , IETF discussion list , draft-ietf-payload-tsvcis.all@ietf.org Message-ID: <20191101001153.GQ88302@kduck.mit.edu> References: <157007038502.8860.1558861534319247512.idtracker@ietfa.amsl.com> <001601d57af9$405efcf0$c11cf6d0$@vocal.com> <6E58094ECC8D8344914996DAD28F1CCD23D79BC0@DGGEMM506-MBX.china.huawei.com> <034a01d58a73$f4d3a1c0$de7ae540$@vocal.com> <037e01d58a92$72287510$56795f30$@vocal.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 00:12:16 -0000 I don't think so, unfortunately. I do see the clarification about CODB's potential for deviation from Table 1, that only the 600 bps MELPe is allowed to deviate, and that CODA gets us to "it's one of 2400 or 600 bps" and the RTP timestamp disambiguates that 600 bps is in use. But, it seems that this means that the recipient in general should not rely on CODB to differentiate 600 from 2400 bps, and instead is more robustly implemented by *always* using the RTP timestamp to detect 600 bps, since that will always work and CODB will sometimes not work under conditions not fully specified here. So, if we are unwilling or unable to clarify what those conditions are (e.g., whether at a minimum mutual agreement is required), then I think we need to describe this procedure of consulting the RTP timestamp as the default behavior and avoid giving the impression that CODB should be used to do so. Additionally, I don't see anything to address my concern about TSVCIS parameter decoding. To be clear, the procedure I see this document describing is that: - TSVCIS gives parameters (and their lengths in bits) to the codec described in this document - this document specifies how to densely encode those parameters into a byetstream - RTP transmits that encoded bytestream to the peer - the codec specified by this is responsible for turning that encoded bystream back into a list of TSVCIS parameters (and their length in bits) I don't see how that last step is attainable with only the information provided by this document. I *assume* that one of the TSVCIS specifications has a canonical (ordered) listing of parameters, and that the list of parmeters given to this codec in the first step will always be an initial prefix of that list, but that's just me guessing at how to make sense of the stated procedure given insufficient information. I don't think it's appropriate to make the reader of an RFC guess at what to do; we need to either say how to do it or give a pointer to an external reference that does. -Ben On Tue, Oct 29, 2019 at 02:26:09PM -0400, Barry Leiba wrote: > Ben, does the -04 version address everything? >=20 > Barry >=20 > On Thu, Oct 24, 2019 at 1:42 PM wrote: > > > > I forgot to address security comments in one email. The changes are: > > > > Section 8, second paragraph - Suggested edit by reviewer > > > > (was) > > This RTP payload format and the TSVCIS decoder do not exhibit any > > significant non-uniformity in the receiver-side computational > > complexity for packet processing and thus are unlikely to pose a > > denial-of-service threat due to the receipt of pathological data. > > Additionally, the RTP payload format does not contain any active > > content. > > > > (now) > > This RTP payload format and the TSVCIS decoder, to the best of our > > knowledge, do not exhibit any significant non-uniformity in the > > receiver-side computational complexity for packet processing and thus > > are unlikely to pose a denial-of-service threat due to the receipt of > > pathological data. Additionally, the RTP payload format does not > > contain any active content. > > > > > > Section 8, third paragraph - Suggested edit by reviewer > > > > (was) > > Please see the security considerations discussed in [RFC6562] > > regarding VAD and its effect on bitrates. > > > > (now) > > Please see the security considerations discussed in [RFC6562] > > regarding Voice Activity Detect (VAD) and its effect on bitrates. > > > > Victor > > > > -----Original Message----- > > From: victor.demjanenko@vocal.com > > Sent: Thursday, October 24, 2019 10:05 AM > > To: 'Roni Even (A)' ; 'Benjamin Kaduk' ; 'The IESG' > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' ; avtcore-chairs@ietf.org; avt@ietf.org; 'Dave Satterlee (Vocal)' <= Dave.Satterlee@vocal.com> > > Subject: RE: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: = (with DISCUSS and COMMENT) > > > > Hi Everyone, > > > > First we want to thank everyone for their review and comments for this = draft RFC. We believe we reviewed all the comments and suggestions and inc= orporated them adequately in the next draft (04). We'd like to send out th= is list of exact changes in case anyone has additional comments or thinks t= he clarifications are inadequate. We would be most happy to address concer= ns before publishing draft 04 tomorrow. > > > > With so many emails from a half dozen or more reviewers, we apologize t= hat we cannot address each sender individually. We hope this detail is suf= ficient for everyone. > > > > Again, many thanks to all. > > > > Victor & Dave > > > > -----------------------------------------------------------------------= ----------------------- > > > > Section 1.1 - Suggested reference to RFC 8088 added. > > > > (was) > > Best current practices for writing an RTP payload format > > specification were followed [RFC2736]. > > > > (now) > > Best current practices for writing an RTP payload format > > specification were followed [RFC2736] [RFC8088]. > > > > > > Section 2, paragraphs 3 and 4 - Suggested edits by reviewers > > > > (was) > > In addition to the augmented speech data, the TSVCIS specification > > identifies which speech coder and framing bits are to be encrypted, > > and how they are protected by forward error correction (FEC) > > techniques (using block codes). At the RTP transport layer, only the > > speech coder related bits need to be considered and are conveyed in > > unencrypted form. In most IP-based network deployments, standard > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type > > 1 Ethernet encryptors) would be used to secure the RTP speech > > contents. Further, it is desirable to support the highest voice > > quality between endpoints which is only possible without the overhead > > of FEC. > > > > TSVCIS augmented speech data is derived from the signal processing > > and data already performed by the MELPe speech coder. For the > > purposes of this specification, only the general parameter nature of > > TSVCIS will be characterized. Depending on the bandwidth available > > (and FEC requirements), a varying number of TSVCIS specific speech > > coder parameters need to be transported. These are first byte-packed > > and then conveyed from encoder to decoder. > > > > (now) > > In addition to the augmented speech data, the TSVCIS specification > > identifies which speech coder and framing bits are to be encrypted, > > and how they are protected by forward error correction (FEC) > > techniques (using block codes). At the RTP transport layer, only the > > speech-coder-related bits need to be considered and are conveyed in > > unencrypted form. In most IP-based network deployments, standard > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type > > 1 Ethernet encryptors) would be used to secure the RTP speech > > contents. > > > > TSVCIS augmented speech data is derived from the signal processing > > and data already performed by the MELPe speech coder. For the > > purposes of this specification, only the general parameter nature of > > TSVCIS will be characterized. Depending on the bandwidth available > > (and FEC requirements), a varying number of TSVCIS-specific speech > > coder parameters need to be transported. These are first byte-packed > > and then conveyed from encoder to decoder. > > > > > > Section 3, last sentence paragraph 3 - Suggested edit by reviewer > > > > (was) > > When more than one codec data frame is > > present in a single RTP packet, the timestamp is, as always, that of > > the oldest data frame represented in the RTP packet. > > > > (now) > > When more than one codec data frame is > > present in a single RTP packet, the timestamp specified is that of > > the oldest data frame represented in the RTP packet. > > > > > > Section 3.1, last paragraph - Clarified permission for MELP 600 end-to-= end framing bit > > > > (was) > > It should be noted that CODB for both the 2400 and 600 bps modes MAY > > deviate from the values in Table 1 when bit 55 is used as an end-to- > > end framing bit. Frame decoding would remain distinct as CODA being > > zero on its own would indicate a 7-byte frame for either rate and the > > use of 600 bps speech coding could be deduced from the RTP timestamp > > (and anticipated by the SDP negotiations). > > > > (now) > > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > > the value in Table 1 when bit 55 is used as an end-to-end framing > > bit. Frame decoding would remain distinct as CODA being zero on its > > own would indicate a 7-byte frame for either 2400 or 600 bps rate and > > the use of 600 bps speech coding could be deduced from the RTP > > timestamp (and anticipated by the SDP negotiations). > > > > > > Section 3.2, first paragraph - Clarifications requested by reviewers > > > > (was) > > The TSVCIS augmented speech data as packed parameters MUST be placed > > immediately after a corresponding MELPe 2400 bps payload in the same > > RTP packet. The packed parameters are counted in octets (TC). In > > the preferred placement, shown in Figure 6, a single trailing octet > > SHALL be appended to include a two-bit rate code, CODA and CODB, > > (both bits set to one) and a six-bit modified count (MTC). The > > special modified count value of all ones (representing a MTC value of > > 63) SHALL NOT be used for this format as it is used as the indicator > > for the alternate packing format shown next. In a standard > > implementation, the TSVCIS speech coder uses a minimum of 15 octets > > for parameters in octet packed form. The modified count (MTC) MUST > > be reduced by 15 from the full octet count (TC). Computed MTC =3D T= C- > > 15. This accommodates a maximum of 77 parameter octets (maximum > > value of MTC is 62, 77 is the sum of 62+15). > > > > (now) > > The TSVCIS augmented speech data as packed parameters MUST be placed > > immediately after a corresponding MELPe 2400 bps payload in the same > > RTP packet. The packed parameters are counted in octets (TC). The > > preferred placement SHOULD be used for TSVCIS payloads with TC less > > than or equal to 77 octets, is shown in Figure 6. In the preferred > > placement, a single trailing octet SHALL be appended to include a > > two-bit rate code, CODA and CODB, (both bits set to one) and a six- > > bit modified count (MTC). The special modified count value of all > > ones (representing a MTC value of 63) SHALL NOT be used for this > > format as it is used as the indicator for the alternate packing > > format shown next. In a standard implementation, the TSVCIS speech > > coder uses a minimum of 15 octets for parameters in octet packed > > form. The modified count (MTC) MUST be reduced by 15 from the full > > octet count (TC). Computed MTC =3D TC-15. This accommodates a maxi= mum > > of 77 parameter octets (maximum value of MTC is 62, 77 is the sum of > > 62+15). > > > > > > Section 3.3, first paragraph - Suggested edit by reviewer > > > > (was) > > A TSVCIS RTP packet consists of zero or more TSVCIS coder frames > > (each consisting of MELPe and TSVCIS coder data) followed by zero or > > one MELPe comfort noise frame. The presence of a comfort noise frame > > can be determined by its rate code bits in its last octet. > > > > (now) > > A TSVCIS RTP packet payload consists of zero or more consecutive > > TSVCIS coder frames (each consisting of MELPe 2400 and TSVCIS coder > > data), with the oldest frame first, followed by zero or one MELPe > > comfort noise frame. The presence of a comfort noise frame can be > > determined by its rate code bits in its last octet. > > > > > > Section 3.3, fourth paragraph - Clarification requested by reviewers > > > > (was) > > TSVCIS coder frames in a single RTP packet MAY be of different coder > > bitrates. With the exception for the variable length TSVCIS > > parameter frames, the coder rate bits in the trailing byte identify > > the contents and length as per Table 1. > > > > (now) > > TSVCIS coder frames in a single RTP packet MAY have varying TSVCIS > > parameter octet counts. Its packed parameter octet count (length) is > > indicated in the trailing byte(s). All MELPe frames in a single RTP > > packet MUST be of the same coder bitrate. For all MELPe coder > > frames, the coder rate bits in the trailing byte identify the > > contents and length as per Table 1. > > > > > > Section 4.1 - Editor note removed > > > > > > Section 4.1 - Change controller is now > > > > (now) > > Change controller: IETF, contact > > > > > > Section 5, first paragraph - Suggested edits by reviewers > > > > (was) > > A primary application of TSVCIS is for radio communications of voice > > conversations, and discontinuous transmissions are normal. When > > TSVCIS is used in an IP network, TSVCIS RTP packet transmissions may > > cease and resume frequently. RTP synchronization source (SSRC) > > sequence number gaps indicate lost packets to be filled by PLC, while > > abrupt loss of RTP packets indicates intended discontinuous > > transmissions. > > > > (now) > > A primary application of TSVCIS is for radio communications of voice > > conversations, and discontinuous transmissions are normal. When > > TSVCIS is used in an IP network, TSVCIS RTP packet transmissions may > > cease and resume frequently. RTP synchronization source (SSRC) > > sequence number gaps indicate lost packets to be filled by Packet > > Loss Concealment (PLC), while abrupt loss of RTP packets indicates > > intended discontinuous transmissions. Resumption of voice > > transmission SHOULD be indicated by the RTP marker bit (M) set to 1. > > > > > > Section 10 - Added reference > > > > (added) > > [RFC8088] Westerlund, M., "How to Write an RTP Payload Format", > > RFC 8088, DOI 10.17487/RFC8088, May 2017, > > . > > > > -----------------------------------------------------------------------= -------------------------- > > > > > > -----Original Message----- > > From: Roni Even (A) > > Sent: Sunday, October 6, 2019 2:09 AM > > To: victor.demjanenko@vocal.com; 'Benjamin Kaduk' ; 'The= IESG' > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' ; avtcore-chairs@ietf.org; avt@ietf.org; 'Dave Satterlee (Vocal)' <= Dave.Satterlee@vocal.com> > > Subject: RE: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: = (with DISCUSS and COMMENT) > > > > Hi, > > About the reference to TSVCIS. > > The RTP payload is about how to encapsulate the payload in an RTP packe= t. The objective is to define how an RTP stack can insert the tsvcis frames= and extract the tsvcis frames from the RTP packet. Typically it is not re= quired to understand the payload structure in order to be able to perform t= he encapsulation. > > This is why the reference to the payload is Informational and we did no= t require to have it publically available. If there is a need to understan= d the payload itself for the encapsulating than we need more information in= the RTP payload specification and a publically available normative referen= ce. I think this is not the case here > > > > Roni Even > > > > AVTCore co-chair (ex Payload) > > > > -----Original Message----- > > From: victor.demjanenko@vocal.com [mailto:victor.demjanenko@vocal.com] > > Sent: Saturday, October 05, 2019 12:18 AM > > To: 'Benjamin Kaduk'; 'The IESG' > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen'; avtcore-chairs@iet= f.org; avt@ietf.org; 'Victor Demjanenko, Ph.D.'; 'Dave Satterlee (Vocal)' > > Subject: RE: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: = (with DISCUSS and COMMENT) > > > > Everyone, > > > > Thanks for the comments. I think I mis-understood the ambiguity with r= espect to to changing rates within a RTP packet. That was not plan. An RT= P packet must have MELP speech frames of the same rate. What is possible i= s that the amount of augmented TSVCIS speech data may vary from one speech = frame to the next. This allows for a dynamic VDR as suggested by the NRL p= aper. So an RTP packet may have varying TSVCIS data but must always have M= ELPe 2400 data. > > > > Again backwards parsing is necessary but the timestamp uniformly increm= ents 22.5msec per combined MELP/TSVCIS speech frame. > > > > The NRL is a good public reference on the VDR aspects. The actual TSVC= IS spec we had was FOUO so we could not replicate its detail. (I believe a= later spec is public or at least partially public. I am trying to get thi= s.) The opaque data is pretty obvious with the TSVCIS spec in hand. > > > > We will address the issues/concerns raised next week. Other business h= ad priority. > > > > Thank you and enjoy the weekend. > > > > Regards, > > > > Victor & Dave > > > > -----Original Message----- > > From: Benjamin Kaduk via Datatracker > > Sent: Wednesday, October 2, 2019 10:40 PM > > To: The IESG > > Cc: draft-ietf-payload-tsvcis@ietf.org; Ali Begen ; avtcore-chairs@ietf.org; ali.begen@networked.media; avt@ietf.org > > Subject: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (wit= h DISCUSS and COMMENT) > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-payload-tsvcis-03: Discuss > > > > When responding, please keep the subject line intact and reply to all e= mail addresses included in the To and CC lines. (Feel free to cut this intr= oductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-payload-tsvcis/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I support Magnus' point about the time-ordering of adjacent frames in a= packet. > > > > Additionally, I am not sure that there's quite enough here to be intero= perably implementable. Specifically, we seem to be lacking a description o= f how an encoder or decoder knows which TSVCIS parameters, and in what orde= r, to byte-pack or unpack, respectively. One might surmise that there is a= canonical listing in [TSVCIS], but this document does not say that, and fu= rthermore [TSVCIS] is only listed as an informative reference. (I couldn't= get my hands on my copy, at least on short notice.) If we limited ourselv= es to treating the TSVCIS parameters as an entirely opaque blob (codec, con= vey these N octets to the peer with the appropriate one- or two-byte traile= r for payload type identification and framing), that would be interoperably= implementable, since the black-box bits are up to some other codec to inte= rpret. > > > > In a similar vein, we mention but do not completely specify the potenti= al for using CODB as an end-to-end framing bit, in Section 3.1 (see Comment= ), which is not interoperably implementable without further details. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Where is [TSVCIS] available? > > > > Is [NRLVDR] the same as > > https://apps.dtic.mil/dtic/tr/fulltext/u2/a588068.pdf ? A URL in the r= eferences would be helpful. > > > > Is additional TSVCIS data only present after 2400bps MELPe and the firs= t thing to get dropped under bandwidth pressure? The abstract and introduc= tion imply this by calling out MELPe 2400 bps speech parameters explicitly,= but Section 3 says that TSVCIS augments standard 600, 1200, and 2400 bps M= ELP frames. > > > > It's helpful that Section 3.3 gives some general guidance for decoding = this payload type ("[t]he way to determine the number of TSVCIS/MELPe frame= s is to identify each frame type and length"), but I think some generic con= siderations would be very helpful to the reader much earlier, along the lin= es of "MELPe and TSVCIS data payloads are decoded from the end, using the C= ODA and CODB (and, if necessary, CODC and others) bits to determine the typ= e of payload. For MELPe payloads the type also indicates the payload lengt= h, whereas for TSVCIS data an additional length field is present, in one of= two possible formats. A TSVCIS coder frame consists of a MELPe data paylo= ad followed by zero or one TSVCIS data payload; after the TSVCIS payload's = presence/length is determined, then the preceding MELPe payload can be dete= rmined and decoded. Per Section 3.3, multiple TSVCIS frames can be present= in a single RTP packet." This (or something like it) would also serve to = clarify the role of the COD* bits, which is otherwise only implicitly intro= duced. > > > > Section 1.1 > > > > RFC 2736 is BCP 36 (but it's updated by RFC 8088 which is for some reas= on an Informational document and not part of BCP 36?!). > > > > Section 2 > > > > In addition to the augmented speech data, the TSVCIS specification > > identifies which speech coder and framing bits are to be encrypted, > > and how they are protected by forward error correction (FEC) > > techniques (using block codes). At the RTP transport layer, only the > > speech coder related bits need to be considered and are conveyed in > > unencrypted form. In most IP-based network deployments, standard > > > > Am I reading this correctly that this text is just summarizing what's i= n the TSVCIS spec in terms of what needs to be in unencrypted form, so the = "only the speech coder related bits[...]" is not new information from this = document? I'm not sure I agree with the conclusion, regardless -- won't th= e (MELPe) speech coder bits be enough to convey the semantic content of the= audio stream, something that one might desire to keep confidential? > > > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type > > 1 Ethernet encryptors) would be used to secure the RTP speech > > contents. Further, it is desirable to support the highest voice > > quality between endpoints which is only possible without the overhead > > of FEC. > > > > I think I'm missing a step in how this conclusion was reached. > > > > TSVCIS will be characterized. Depending on the bandwidth available > > (and FEC requirements), a varying number of TSVCIS specific speech > > coder parameters need to be transported. These are first byte-packed > > and then conveyed from encoder to decoder. > > > > Per the Discuss point, how do I know which parameters need to be transp= orted, and in what order? > > > > Byte packing of TSVCIS speech data into packed parameters is > > processed as per the following example: > > > > Three-bit field: bits A, B, and C (A is MSB, C is LSB) > > Five-bit field: bits D, E, F, G, and H (D is MSB, H is LSB) > > > > MSB LSB > > 0 1 2 3 4 5 6 7 > > +------+------+------+------+------+------+------+------+ > > | H | G | F | E | D | C | B | A | > > +------+------+------+------+------+------+------+------+ > > > > This packing method places the three-bit field "first" in the lowest > > bits followed by the next five-bit field. Parameters may be split > > between octets with the most significant bits in the earlier octet. > > Any unfilled bits in the last octet MUST be filled with zero. > > > > I agree with Adam that this is very unclear. A is the MSB of the three= -bit field but the LSB of the octet overall? > > We probably need an example of splitting a parameter across octets as w= ell, to get the bit ordering right. > > > > Section 3.1 > > > > It should be noted that CODB for both the 2400 and 600 bps modes MAY > > deviate from the values in Table 1 when bit 55 is used as an end-to- > > end framing bit. Frame decoding would remain distinct as CODA being > > > > Where is the use of CODB as an end-to-end framing bit defined? If we'r= e going to provide neither a complete description of how to do it nor a ref= erence to a better description, we probably shouldn't mention it at all. > > > > Section 3.2 > > > > RTP packet. The packed parameters are counted in octets (TC). In > > the preferred placement, shown in Figure 6, a single trailing octet > > SHALL be appended to include a two-bit rate code, CODA and CODB, > > > > I'd consider saying something about this being the preferred format > > ("placement") due to its shorter length than the alternative, and say t= hat it "SHOULD be used for TSVCIS payloads with TC less than or equal to 77= octetes". > > > > Section 3.3 > > > > When a longer packetization interval is used, is that indicated by sign= aling or RTP timestamps or otherwise? > > > > TSVCIS coder frames in a single RTP packet MAY be of different coder > > bitrates. With the exception for the variable length TSVCIS > > parameter frames, the coder rate bits in the trailing byte identify > > the contents and length as per Table 1. > > > > Maybe also note that the penultimate octet gives the length there? > > > > Information describing the number of frames contained in an RTP > > packet is not transmitted as part of the RTP payload. The way to > > determine the number of TSVCIS/MELPe frames is to identify each frame > > type and length thereby counting the total number of octets within > > the RTP packet. > > > > terminology nit: if a frame is the combination of MELPe and TSVCIS payl= oad data units then there are two layres of decoding to get a length for th= e frame, since we have to get the TSVCIS length and then the MELPe length. > > > > Section 4.2 > > > > Parameter "ptime" cannot be used for the purpose of specifying the > > > > nit: missing article ("The parameter") > > > > will be impossible to distinguish which mode is about to be used > > (e.g., when ptime=3D68, it would be impossible to distinguish if the > > packet is carrying one frame of 67.5 ms or three frames of 22.5 ms). > > > > So how is the operating mode determined, then? > > (I think this is the same question I asked above) > > > > Section 4.4 > > > > For example, if offerer bitrates are "2400,600" and answer bitrates > > are "600,2400", the initial bitrate is 600. If other bitrates are > > provided by the answerer, any common bitrate between the offer and > > answer MAY be used at any time in the future. Activation of these > > other common bitrates is beyond the scope of this document. > > > > It seems important to specify whether this requires a new O/A exchange = or can be done "spontaneously" by just encoding different frame types. > > (It seems like the latter is possible, on first glance, and this is imp= lied by Section 3.3's discussion of mixing them in a single packet.) > > > > Section 5 > > > > Please expand PLC at first use (not second). > > > > Section 6 > > > > I don't understand the PLC usage. Is the idea that a receiver, on seei= ng an SSRC gap, constructs fictitious PLC frames to "fill the gap" > > and passes the resulting stream to the decoder? > > > > Section 8 > > > > and important considerations in [RFC7201]. Applications SHOULD use > > one or more appropriate strong security mechanisms. The rest of this > > section discusses the security-impacting properties of the payload > > format itself. > > > > I thought we described TSVCIS itself (much earlier in the document) as = requiring encryption for some data; wouldn't that translate to a "MUST" > > here and not a "SHOULD"? > > > > > >