From nobody Tue May 2 10:32:31 2017 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 0C051129422; Tue, 2 May 2017 10:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.645 X-Spam-Level: *** X-Spam-Status: No, score=3.645 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845] 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 v0wkr5-7d44V; Tue, 2 May 2017 10:32:27 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 AE3E7129B62; Tue, 2 May 2017 10:29:50 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.10.118; From: "Susan Hares" To: "'Derek Atkins'" , , Cc: , , , , , References: In-Reply-To: Date: Tue, 2 May 2017 13:23:58 -0400 Message-ID: <040d01d2c368$e281d3e0$a7857ba0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHq5flN5MHN2CksilV0i54d1XYwXqGw+CTQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [secdir] sec-dir review of draft-ietf-i2nsf-problem-and-use-cases-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 17:32:30 -0000 Derek: I apologize for the delay in responding to you. I will check to make sure these are fixed in version 16. Sue Hares -----Original Message----- From: Derek Atkins [mailto:derek@ihtfp.com] Sent: Tuesday, April 25, 2017 1:34 PM To: iesg@ietf.org; secdir@ietf.org Cc: i2nsf-chairs@ietf.org; pauljeong@skku.edu; rkkumar@juniper.net; Christian.jacquenet@orange.com; myo@varmour.com; diego.r.lopez@telefonica.com; shares@ndzh.com Subject: sec-dir review of draft-ietf-i2nsf-problem-and-use-cases-12 Hi, 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 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. Summary: Ready to publish with small edits. Details: This document doesn't specify any protocols. There appears to be a missing word in the end of the Security Considerations section which says: It is important to proper AAA [RFC2904] to authorize access to the network and access to the I2NSF management stream. I'm not sure if this is missing "proper AAA [something] [RFC2904] to authorize" or if there is a different phrasing. I'm not sure what is trying to be said about AAA, but this sentence is clearly missing an article (as "proper AAA" by itself is not a noun"). -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed May 3 08:49:21 2017 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 2FF521293DB; Sat, 22 Apr 2017 19:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1492916307; bh=RpFB1aYGSN8BJLsvNo7BojCN++shFFI7MVJkoIKaMaE=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=dr2F878xBeE5KFVlV2Es3+JdwqkbihgiXJ5rYYkaafNvAZWTa6MCtYmCYVq8lGKoW b3k0cpq3YM4wAXSpwqa5HWiXowC5Dq+TQEtoxl3O1Hc29zrOLZLSz4yFk7B4Ptc9CK +c2RvtTAaT9jgmFdIQ+2a83VrTuCeTDdRAld7F04= 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 373481293DB for ; Sat, 22 Apr 2017 19:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1XjzSKBRTNd for ; Sat, 22 Apr 2017 19:58:23 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (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 5A7FF126B6D for ; Sat, 22 Apr 2017 19:58:23 -0700 (PDT) Received: from moon.w3.org ([128.30.55.110] helo=[10.87.51.5]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1d27jA-0007DV-By for new-work@ietf.org; Sun, 23 Apr 2017 02:58:20 +0000 From: Coralie Mercier Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <47D88438-F2B6-4CD7-8744-443E10E3AD30@w3.org> Date: Sun, 23 Apr 2017 10:58:11 +0800 To: new-work@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.22 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Wed, 03 May 2017 08:49:16 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Media and Entertainment Interest Group (until 2017-05-26) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 02:58:27 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review a draft charter for the Media and Entertainment Interest Group: https://www.w3.org/2017/03/webtv-charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2017-05-26 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [1], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Kazuyuki Ashimura, Team Contact . Thank you, Coralie Mercier, Head of W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Marketing & Communications - https://www.w3.org mailto:coralie@w3.org +336 4322 0001 https://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Thu May 4 02:46:25 2017 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 34828129B97 for ; Thu, 4 May 2017 02:46:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <149389118421.4942.13737253496312801399.idtracker@ietfa.amsl.com> Date: Thu, 04 May 2017 02:46:24 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 09:46:24 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-05-11 Reviewer LC end Draft John Bradley 2017-05-04 draft-ietf-manet-olsrv2-multipath-12 Ben Laurie 2017-03-02 draft-ietf-dprive-dtls-and-tls-profiles-09 For telechat 2017-05-25 Reviewer LC end Draft Shawn Emery 2017-05-16 draft-ietf-nfsv4-xattrs-05 Ólafur Guðmundsson 2017-05-12 draft-ietf-nfsv4-versioning-09 Phillip Hallam-Baker 2017-05-12 draft-ietf-nfsv4-umask-03 Dan Harkins 2017-05-12 draft-ietf-mpls-tp-shared-ring-protection-05 David Waltermire 2017-05-17 draft-ietf-isis-l2bundles-04 For telechat 2017-06-08 Reviewer LC end Draft Tom Yu 2017-05-02 draft-ietf-bmwg-ipv6-tran-tech-benchmarking-07 Last calls: Reviewer LC end Draft Derek Atkins 2017-05-04 draft-ietf-spring-ipv6-use-cases-10 Alan DeKok 2017-05-26 draft-nottingham-rfc5988bis-05 Donald Eastlake 2017-05-16 draft-ietf-oauth-native-apps-10 Daniel Franke 2017-05-15 draft-ietf-bmwg-vswitch-opnfv-03 Daniel Gillmor 2017-05-14 draft-ietf-netmod-yang-model-classification-06 Tobias Gondrom 2017-05-14 draft-ietf-calext-caldav-attachments-02 Melinda Shore 2017-04-09 draft-ietf-core-coap-tcp-tls-08 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-08 Dacheng Zhang 2017-05-04 draft-ietf-spring-resiliency-use-cases-09 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Next in the reviewer rotation: Paul Hoffman Russ Housley Christian Huitema Leif Johansson Benjamin Kaduk Charlie Kaufman Scott Kelly Stephen Kent Tero Kivinen Watson Ladd From nobody Thu May 4 04:12:15 2017 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 3C96F12EA7F for ; Thu, 4 May 2017 04:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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=google.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 S0jxGYjcEOcH for ; Thu, 4 May 2017 04:12:07 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 49E8A12EA56 for ; Thu, 4 May 2017 04:12:01 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id y190so5192406vkc.1 for ; Thu, 04 May 2017 04:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=yKl2JcjKMnF7ZcO6iG5vHE6B6vvo9oSMWGvAPrQs5ZA=; b=C7ANdOdZBJ202oVutfxJwnS3VL8fRrfLuYhzfGT5Geh4W+lL8x3ygWKWP1vjq3lHvI 1fHjKY1mLV8NXwRTkWT1CdSPPDY1ANc2KV5oo0BzZP1lq5w1muKVTFX18iogvymYKMVm QasVrDQ2+6O/L0neyPM2iJOyFlM8YM+NE2U56EaT5TyGQPOlEfkCbEUQo3pAz1YfxJNG Q7Fy6IZ2JXeMrW8b9y11a9TD39EAeCjIjCyLE4l5hWCZNDVgQpuFL3hGebCuJTgnv8Sf tNiBCyw/TwQo54iI1raO+XvwhXDidF5h3tNZKG5ggDGtU1GXAQnG0tYf73+0KExpksLU 5E8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yKl2JcjKMnF7ZcO6iG5vHE6B6vvo9oSMWGvAPrQs5ZA=; b=Y4bALc4NFZ+irxWWOwEB+SuDHjCdzZmfq7Z66QlVmNMFUlFDPjMSGjuUsow6Fpi63+ oY8CVHnTasar1mZN2QuFxpVtXZ4opKzmhIDYFDIvvoLrsWKItduHfq7Iwo5q3YZUetOW QiMILwjj76gUd/x/JnQ607ciYXI40pEMx/WXdVOyMHP+Ybx2deATzATaelAmaQI4UOJ1 1LA9b1oUUAF1HksNCxechYdXoyXqBxde3qmr2GClnTfwSXQIffIXy3oZstvxTzUYLpFp zReigZTAAobo4sFMmX8C4EmCfUecFeZ7C38UIWLxI1KT27O+X6ZCgSXM2++OECsijO/A KYuQ== X-Gm-Message-State: AN3rC/5GHgn0Eyqr2Azzpbc/jUUk7SbmZW4XUT1rmNTK1x+qauideVxj GoYce28BXlCo++N92KzF6bHGimrDsHncrZFUDw== X-Received: by 10.31.79.66 with SMTP id d63mr5409786vkb.117.1493896320188; Thu, 04 May 2017 04:12:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.170.150 with HTTP; Thu, 4 May 2017 04:11:59 -0700 (PDT) From: Ben Laurie Date: Thu, 4 May 2017 12:11:59 +0100 Message-ID: To: The IESG , "secdir@ietf.org" , draft-ietf-dprive-dtls-and-tls-profiles.all@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] Security review of draft-ietf-dprive-dtls-and-tls-profiles-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 11:12:08 -0000 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. Status: not ready. I am a little puzzled by this I-D. The title is "Authentication and (D)TLS Profile for DNS-over-(D)TLS" and the intro says it specifies profiles which "which define the security properties a user should expect when using that profile to connect to the available DNS servers", however, as far as I can see, no properties other than server authentication are defined. The document also appears to claim that a connection that is authenticated and encrypted is "private" - that seems to stretch the meaning of "private" quite considerably. Other considerations surely exist, such as resistance against traffic analysis, key sizes, algorithm choice. As a result, claims like "Strict Privacy provides the strongest privacy guarantees" are just plain wrong. Given these large holes in scope, I have not attempted a more detailed analysis. From nobody Fri May 5 08:20:22 2017 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 A7A6012945E; Fri, 5 May 2017 08:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.71 X-Spam-Level: X-Spam-Status: No, score=0.71 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.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 8-3EZzslBRQR; Fri, 5 May 2017 08:20:13 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:470:e448:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66D781294B8; Fri, 5 May 2017 08:20:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 86D85E2045; Fri, 5 May 2017 11:20:11 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 08332-07; Fri, 5 May 2017 11:20:10 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id DC027E203A; Fri, 5 May 2017 11:20:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1493997609; bh=Iy66Em4V2cMHGbO1dKiDEbrGV4G8i9WggP2gusABPOU=; h=From:To:Cc:Subject:Date; b=AGNvrsjetaWjvJMrsQIjnYRtu2ydQYu2H2sch4FGE+oEvuaebX0xgUqf/ZVpyONGK Cawtzxb/dVgWpqZbajBmFcuTYg4hHltZPfOtGhuVKio1xQeUjK0UrzhTesayetgsa3 2hWz7BWtQAvq3XekYVz1lQzty3tsXVFB/DtkHHUI= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id v45FK8Ni020192; Fri, 5 May 2017 11:20:08 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Cc: spring-chairs@ietf.org, townsley@cisco.com, robmgl@cisco.com, cfilsfil@cisco.com, John_Leddy@cable.comcast.com, john_brzozowski@cable.comcast.com Date: Fri, 05 May 2017 11:20:08 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: [secdir] sec-dir review of draft-ietf-spring-ipv6-use-cases-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 15:20:15 -0000 Hi, 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 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. Summary: Ready to publish. Details: I have no comments. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Sun May 7 12:57:47 2017 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 4D88B1286CA; Sun, 7 May 2017 12:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRQ7jG4bK-fJ; Sun, 7 May 2017 12:57:45 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 C66D01200C5; Sun, 7 May 2017 12:57:44 -0700 (PDT) X-AuditID: 12074423-5b5ff70000003850-bb-590f7c359764 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 84.CC.14416.53C7F095; Sun, 7 May 2017 15:57:43 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v47Jvfrf026021; Sun, 7 May 2017 15:57:41 -0400 Received: from localhost (nyc-02.triskelion.com [162.243.175.178]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v47JvdH6007383; Sun, 7 May 2017 15:57:40 -0400 From: Taylor Yu To: iesg@ietf.org, secdir@ietf.org, draft-ietf-bmwg-ipv6-tran-tech-benchmarking.all@ietf.org Date: Sun, 07 May 2017 19:57:38 +0000 Message-ID: Lines: 39 MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPIsWRmVeSWpSXmKPExsUixG6nrmtewx9pMH+ujMWPOVNZLGb8mchs 8WHhQxYHZo8lS34yBTBGcdmkpOZklqUW6dslcGX8nHiSsWATb0Xr/s3sDYy/uLoYOTkkBEwk uqbfZ+pi5OIQEljMJHHux21WCGcDo8TE3qcsEM5XRok/h+cDORwcbAJyEpdvBYOYIgKpEt9O VYIMEhYIk+g69oIRxGYRUJX4c2AjE4jNK2Aj0TT9EAuIzSPAKdE5sYsdIi4ocXLmE7A4s4CE xMEXL5gnMPLMQpKahSS1gJFpFaNsSm6Vbm5iZk5xarJucXJiXl5qka6ZXm5miV5qSukmRnC4 uCjvYHzZ532IUYCDUYmHN6GYP1KINbGsuDL3EKMkB5OSKO8mPaAQX1J+SmVGYnFGfFFpTmrx IUYJDmYlEd45kUA53pTEyqrUonyYlDQHi5I4r7hGY4SQQHpiSWp2ampBahFMVoaDQ0mCd18V UKNgUWp6akVaZk4JQpqJgxNkOA/Q8GUgNbzFBYm5xZnpEPlTjIpS4rzPQBICIImM0jy4XlA8 L/q8ftMrRnGgV4R5X4BU8QBTAVz3K6DBTECDo0V5QAaXJCKkpBoYrcVND/oti5c3U9PdnyMj 2BHj/PHM6o13b8lrvefI+By76sqRxHM8/0MbgzgZ9D5Fc4qvaSu5JVvx4dS3n2bnZR9/vqH8 ziW+9me139lXcTzro+VjJGTZP+7LYmjkibYWfrxmT/UGK/6qrfUxvluiZGIabi1w/hbcwvXs aoXI2eVnjZL9GycpsRRnJBpqMRcVJwIA+4hC9sICAAA= Archived-At: Subject: [secdir] secdir last call review of draft-ietf-bmwg-ipv6-tran-tech-benchmarking-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 19:57:46 -0000 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: Ready with nits The "SHOULD" in the following sentence doesn't seem like a valid RFC 2119 keyword usage to me. "Any implications for network security arising from the DUT/SUT SHOULD be identical in the lab and in production networks." Please consider replacing it with lowercase "should". (I read it as predicting a correlation between the network security properties of the DUT in the lab environment and its behavior in a production environment, not as a guideline for implementors.) Comments: I'm not sure if you would consider this to be in scope, but might it be useful to instrument implementations being benchmarked with runtime error or anomaly detection? (This would be in addition to the uninstrumented "black-box" measurements.) This could lead to detecting security-relevant bounds checking or memory management errors induced by aggressive benchmarking workloads, possibly identifying vulnerabilities early enough to fix them before they're exploited. Some kinds of instrumentation could have a substantial performance impact, so it might be best to start testing well below the limits of uninstrumented performance of the devices/systems under test. Editorial: Section 13 (Security Considerations) uses "SUT" without a prior expansion. Presumably it means "System Under Test" or "Software Under Test"? From nobody Sun May 7 13:42:36 2017 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 7A04B127601; Sun, 7 May 2017 13:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 GfF9aVP0on67; Sun, 7 May 2017 13:42:22 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 CB88F124B0A; Sun, 7 May 2017 13:42:22 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v47KZD7I009623; Sun, 7 May 2017 16:42:20 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049459.ppops.net-00191d01. with ESMTP id 2a9fjhr2vh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 07 May 2017 16:42:19 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v47KgI4B018415; Sun, 7 May 2017 16:42:19 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v47KgDT6018380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 7 May 2017 16:42:15 -0400 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Sun, 7 May 2017 20:41:59 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v47KfxhN014123; Sun, 7 May 2017 15:41:59 -0500 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v47Kfs5I013967; Sun, 7 May 2017 15:41:54 -0500 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-blue.research.att.com (Postfix) with ESMTP id E6FEBF046A; Sun, 7 May 2017 16:41:53 -0400 (EDT) Received: from njmtexg4.research.att.com ([fe80::8cd:baa3:219e:5bd4]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Sun, 7 May 2017 16:41:53 -0400 From: "MORTON, ALFRED C (AL)" To: Taylor Yu , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-bmwg-ipv6-tran-tech-benchmarking.all@ietf.org" Thread-Topic: secdir last call review of draft-ietf-bmwg-ipv6-tran-tech-benchmarking-07.txt Thread-Index: AQHSx2w2rHMSiqlIEE6+AQ7I+c+lNaHpU2ng Date: Sun, 7 May 2017 20:41:52 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF25F96C2C@njmtexg4.research.att.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.217.209] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-07_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705070145 Archived-At: Subject: Re: [secdir] secdir last call review of draft-ietf-bmwg-ipv6-tran-tech-benchmarking-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 20:42:25 -0000 Hi Taylor, you wrote: > Please consider replacing it with lowercase "should". (I read it as > predicting a correlation between the network security properties of the > DUT in the lab environment and its behavior in a production environment, > not as a guideline for implementors.) This *is* a guideline to implementors, who are part of the intended audience. We don't want testers to waste time benchmarking=20 implementations that are for the lab-only; it is recommended to test the systems intended for production (and such testing will be safer in the isolated lab, of course). Also, if implementations have run-time error instrumentation, so be it, but collecting this info is normally beyond the scope of the blackbox lab texting of external phenomena. hope this helps, Al > -----Original Message----- > From: Taylor Yu [mailto:tlyu@mit.edu] > Sent: Sunday, May 07, 2017 3:58 PM > To: iesg@ietf.org; secdir@ietf.org; draft-ietf-bmwg-ipv6-tran-tech- > benchmarking.all@ietf.org > Subject: secdir last call review of draft-ietf-bmwg-ipv6-tran-tech- > benchmarking-07.txt >=20 > 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. >=20 > Summary: Ready with nits >=20 > The "SHOULD" in the following sentence doesn't seem like a valid RFC > 2119 keyword usage to me. >=20 > "Any implications for network security arising > from the DUT/SUT SHOULD be identical in the lab and in production > networks." >=20 > Please consider replacing it with lowercase "should". (I read it as > predicting a correlation between the network security properties of the > DUT in the lab environment and its behavior in a production environment, > not as a guideline for implementors.) >=20 > Comments: >=20 > I'm not sure if you would consider this to be in scope, but might it be > useful to instrument implementations being benchmarked with runtime > error or anomaly detection? (This would be in addition to the > uninstrumented "black-box" measurements.) This could lead to detecting > security-relevant bounds checking or memory management errors induced by > aggressive benchmarking workloads, possibly identifying vulnerabilities > early enough to fix them before they're exploited. >=20 > Some kinds of instrumentation could have a substantial performance > impact, so it might be best to start testing well below the limits of > uninstrumented performance of the devices/systems under test. >=20 > Editorial: >=20 > Section 13 (Security Considerations) uses "SUT" without a prior > expansion. Presumably it means "System Under Test" or "Software Under > Test"? From nobody Sun May 7 13:51:14 2017 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 3A6C41279E5 for ; Sun, 7 May 2017 13:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 GftIxsuvsY-o for ; Sun, 7 May 2017 13:51:12 -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 1C9761293F9 for ; Sun, 7 May 2017 13:51:12 -0700 (PDT) Received: from [169.254.166.155] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v47Kolsw000600 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 7 May 2017 13:50:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [169.254.166.155] From: "Paul Hoffman" To: secdir Date: Sun, 07 May 2017 13:51:10 -0700 Message-ID: <9CA99216-D160-4E7C-ABB3-EE4A625C67C0@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: [secdir] Secdir review of draft-ietf-mpls-tp-shared-ring-protection X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 20:51:13 -0000 This document describes MPLS-TP Shared Ring Protection (MSRP), an extension to MPLS-TP. It doesn't need any more or less security than MPLS-TE itself. The Security Considerations say: The RPS protocol defined in this document is carried in the G-ACh [RFC5586], which is a generalization of the Associated Channel defined in [RFC4385]. The security considerations specified in these documents apply to the proposed RPS mechanism. That seems sufficient for this document. --Paul Hoffman From nobody Sun May 7 18:34:16 2017 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 0ED18128A32; Sun, 7 May 2017 18:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUCPfAIQ5wAJ; Sun, 7 May 2017 18:34:07 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 82DC2127333; Sun, 7 May 2017 18:34:07 -0700 (PDT) X-AuditID: 1209190f-ce9ff70000004ab2-3d-590fcb0d2fe0 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id E3.32.19122.D0BCF095; Sun, 7 May 2017 21:34:06 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v481Y4Lo020873; Sun, 7 May 2017 21:34:05 -0400 Received: from localhost (nyc-02.triskelion.com [162.243.175.178]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v481Y2oP020669; Sun, 7 May 2017 21:34:03 -0400 From: Taylor Yu To: "MORTON\, ALFRED C \(AL\)" Cc: "iesg\@ietf.org" , "secdir\@ietf.org" , "draft-ietf-bmwg-ipv6-tran-tech-benchmarking.all\@ietf.org" References: <4D7F4AD313D3FC43A053B309F97543CF25F96C2C@njmtexg4.research.att.com> Date: Mon, 08 May 2017 01:34:02 +0000 In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF25F96C2C@njmtexg4.research.att.com> (ALFRED C. MORTON's message of "Sun, 7 May 2017 20:41:52 +0000") Message-ID: Lines: 30 MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPIsWRmVeSWpSXmKPExsUixG6nost3mj/S4G2PiMXWYxMZLX7Mmcpi MePPRGaLDwsfsjiweLzsn8PosWTJT6YApigum5TUnMyy1CJ9uwSujEObDjIV7OKp6Jk/m62B cQZXFyMnh4SAicSkfRPZuhi5OIQEFjNJ/N41jQnC2cAo8XD/YRYI5yujxKK989m7GDk42ATk JC7fCgbpFhEwlJg18QILiM0scJpRYv81KRBbWCBKYtmVTVBTmxklHu/vYwTpZRFQlTj42xgk zikwhVFi2a1WVpAGXgEbiY+Lv7GB2DwCnBKPzl5mgogLSpyc+QRqgYTEwRcvmCcw8s9CkpqF JLWAkWkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrolebmaJXmpK6SZGUDhySvLvYJzT4H2IUYCD UYmHN6GYP1KINbGsuDL3EKMkB5OSKO+h+UAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrznjwLl eFMSK6tSi/JhUtIcLErivOIajRFCAumJJanZqakFqUUwWRkODiUJ3kkngRoFi1LTUyvSMnNK ENJMHJwgw3mAhj8DqeEtLkjMLc5Mh8ifYlSUEudddQIoIQCSyCjNg+sFpYtFn9dvesUoDvSK MG8iSDsPMNXAdb8CGswENDhalAdkcEkiQkqqgbFx97Gj9U/sJglt+HxKvMlU86vkovxl7rsX pvK7tjnd/tvFt/Sy29xoll49piUuL2XVNlu0cv8NZFv86N5sg4s+X6rvtK6ZHSi/hEu0wLoj bIf1qhcLH88Ner1lYdQz276oN86rCwyaJiSwGDOt2x8RxrBOYgnTtpLZIo4vT+X6PUyc0b2p qF6JpTgj0VCLuag4EQDkwtPx8gIAAA== Archived-At: Subject: Re: [secdir] secdir last call review of draft-ietf-bmwg-ipv6-tran-tech-benchmarking-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 01:34:09 -0000 "MORTON, ALFRED C (AL)" writes: > you wrote: >> Please consider replacing it with lowercase "should". (I read it as >> predicting a correlation between the network security properties of the >> DUT in the lab environment and its behavior in a production environment, >> not as a guideline for implementors.) > > This *is* a guideline to implementors, who are part of the intended > audience. We don't want testers to waste time benchmarking > implementations that are for the lab-only; it is recommended > to test the systems intended for production (and such testing > will be safer in the isolated lab, of course). I'm sorry, I guess I misinterpreted, then. Do you mean that the implementations tested in the benchmarking lab should not materially differ from ones intended for production? As in the tested implementations should be have neither stronger nor weaker security properties than their deployed counterparts? I might be able to suggest improved wording if I understand your intentions correctly. > Also, if implementations have run-time error instrumentation, > so be it, but collecting this info is normally beyond the scope > of the blackbox lab texting of external phenomena. I think there is an opportunity here to use instrumented versions of implementations to detect security-relevant errors and anomalies as they operate near their performance limits. I also concede that sort of work might be outside the scope of this document. (I can envision a related document that would cover such security-related topics.) From nobody Mon May 8 00:44:56 2017 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 86234120724; Mon, 8 May 2017 00:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] 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 2COJOi9Brh3e; Mon, 8 May 2017 00:44:53 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [46.235.227.24]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C6861243FE; Mon, 8 May 2017 00:44:53 -0700 (PDT) Received: from [2a02:8010:6126:0:a50b:3fa2:10d3:edf3] (port=50834) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1d7dLe-0004Tk-UN; Mon, 08 May 2017 08:44:51 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sara Dickinson In-Reply-To: Date: Mon, 8 May 2017 08:44:46 +0100 Cc: The IESG , "secdir@ietf.org" , draft-ietf-dprive-dtls-and-tls-profiles.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ben Laurie X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: Re: [secdir] Security review of draft-ietf-dprive-dtls-and-tls-profiles-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 07:44:55 -0000 > On 4 May 2017, at 12:11, Ben Laurie wrote: >=20 > 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. >=20 Hi Ben,=20 Thanks for the review.=20 > Status: not ready. >=20 > I am a little puzzled by this I-D. The title is "Authentication and > (D)TLS Profile for DNS-over-(D)TLS" and the intro says it specifies > profiles which "which define the security properties a user should > expect when using that profile to connect to the available DNS > servers", however, as far as I can see, no properties other than > server authentication are defined. Section 5 is really the part of the draft intended to address this by = outlining in detail the security properties a user should expect when = using either a Strict or Opportunistic Profile to connect to the = available DNS servers. So by security properties we really mean = mitigation against passive attack (via encryption alone) or active = attack (by using encryption in combination with authentication). In developing the draft we found widespread uncertainly among the DNS = community as to precisely what Opportunistic Security was and how it = differed from Strict. For example it became apparent that many DNS folks = didn=E2=80=99t realise that Opportunistic could include falling back to = clear text thus providing no security guarentees. That is why the table = in Section 5 is provided to (hopefully) clarify these concepts and = expectations. It might seem overkill to those with a strong security = background but we had enough iterations on this during working group = review that it really did seem necessary. Would re-wording the introduction text to say something like=20 =E2=80=9CThis document specifies two Usage Profiles (Strict and = Opportunistic) for DTLS [RFC6347] and TLS [RFC5246] which provide = different levels of attack mitigation over using only clear text DNS.=E2=80= =9D be a start in addressing this? >=20 > The document also appears to claim that a connection that is > authenticated and encrypted is "private" - that seems to stretch the > meaning of "private" quite considerably. It wasn=E2=80=99t the intent to claim complete privacy via these = Profiles. I _thought_ we had been quite careful in always using a phrase = such as =E2=80=9CThis profile provides strong privacy guarantees to the = client.=E2=80=9D rather than saying =E2=80=99This provides a private = connection=E2=80=9D but perhaps I missed something? This seems to go = back to the same issue of wording and so I wonder that if we had used a = phrase like =E2=80=98attack mitigation=E2=80=99 throughout instead of = 'privacy guarantees=E2=80=99 it would read more clearly? >=20 > Other considerations surely exist, such as resistance against traffic > analysis, key sizes, algorithm choice. We do attempt to address these issues separately in later sections, = specifically: - Section 11 =E2=80=98Counter measures to DNS Traffic Analysis=E2=80=99 = recommending padding SHOULD be done by both client and server and=20 - Section 9 '(D)TLS Protocol Profile' where rather than making specific = recommendations for DNS we state that client and servers MUST adhere to = RFC7275 and MUST use TLS 1.2 or later, etc.=20 >=20 > As a result, claims like "Strict Privacy provides the strongest > privacy guarantees" are just plain wrong. Better written as =E2=80=9CStrict Privacy provides the strongest privacy = guarantees of the two Profiles described here=E2=80=9D? Again, the = intention isn=E2=80=99t to portray Strict Privacy as some sort of = =E2=80=98perfect privacy=E2=80=99 just as the =E2=80=98best privacy = available=E2=80=99. I=E2=80=99m hoping this is a general problem generated by the use of a = handful of phrases in the document that I now realise could be read with = a different context. If you also think this is the fundamental issue = then I would suggest the authors take a pass over the document to try to = address this by either changing this wording or carefully defining what = these terms mean in the context of this document.=20 Regards Sara.=20 From nobody Tue May 9 01:38:15 2017 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 95C9A129B41; Tue, 9 May 2017 01:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rcs-rds.ro 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 aWf7_e6S4VAJ; Tue, 9 May 2017 01:38:10 -0700 (PDT) Received: from mailproxy3.rcs-rds.ro (mailproxy3.rcs-rds.ro [212.54.120.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2726B129B40; Tue, 9 May 2017 01:38:09 -0700 (PDT) Received: from [10.172.5.198] (unknown [10.172.5.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailproxy3.rcs-rds.ro (Postfix) with ESMTPSA id 5AF1A1BD5D2; Tue, 9 May 2017 11:38:06 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rcs-rds.ro; s=MailProxy; t=1494319086; bh=1NF1zCXib75HPQZK74ajehi5X+OLFNbQOpQAfQHBCFA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=O34qxJPKnOZuP90ltWYTscSCt8m8zB9EJwZIBNCNaA1mndLhZsXk/WPELM+BGCLGo MAqSyrEzYPb1vur54ktOVi+uTF/SEXLMdHM5zv8j8b+PELbDP2oGkQVLV92dqL5qCe wOznBMuU1RyF5AMEQuubwFhxxMPBMLnpKld7yvQA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Marius Georgescu In-Reply-To: Date: Tue, 9 May 2017 11:38:04 +0300 Cc: Alfred C Morton , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-bmwg-ipv6-tran-tech-benchmarking.all@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3AF9B659-1229-43F8-BA74-1B5526277391@rcs-rds.ro> References: <4D7F4AD313D3FC43A053B309F97543CF25F96C2C@njmtexg4.research.att.com> To: Taylor Yu X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] secdir last call review of draft-ietf-bmwg-ipv6-tran-tech-benchmarking-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 08:38:13 -0000 Hello Taylor, Thank you very much for reviewing the document. Please find my comments inline. > On May 8, 2017, at 4:34 AM, Taylor Yu wrote: >=20 > "MORTON, ALFRED C (AL)" writes: >=20 >> you wrote: >>> Please consider replacing it with lowercase "should". (I read it as >>> predicting a correlation between the network security properties of = the >>> DUT in the lab environment and its behavior in a production = environment, >>> not as a guideline for implementors.) >>=20 >> This *is* a guideline to implementors, who are part of the intended >> audience. We don't want testers to waste time benchmarking=20 >> implementations that are for the lab-only; it is recommended >> to test the systems intended for production (and such testing >> will be safer in the isolated lab, of course). >=20 > I'm sorry, I guess I misinterpreted, then. Do you mean that the > implementations tested in the benchmarking lab should not materially > differ from ones intended for production? As in the tested > implementations should be have neither stronger nor weaker security > properties than their deployed counterparts? I might be able to = suggest > improved wording if I understand your intentions correctly. Indeed, we meant that the implementations tested in the lab should not = differ from the ones intended for production. >=20 >> Also, if implementations have run-time error instrumentation, >> so be it, but collecting this info is normally beyond the scope >> of the blackbox lab texting of external phenomena. >=20 > I think there is an opportunity here to use instrumented versions of > implementations to detect security-relevant errors and anomalies as = they > operate near their performance limits. I also concede that sort of = work > might be outside the scope of this document. (I can envision a = related > document that would cover such security-related topics.) This sounds like an interesting benchmarking subject. However, I think = it's outside the scope of this document and should remain that way. Maybe a specific document dedicated to this subject is a better idea. Best regards, Marius=20 From nobody Thu May 11 03:54:44 2017 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 5BB65128D40 for ; Thu, 11 May 2017 03:54:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <149450008229.16624.10076721726559554201.idtracker@ietfa.amsl.com> Date: Thu, 11 May 2017 03:54:42 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 10:54:42 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-05-11 Reviewer LC end Draft John Bradley 2017-05-04 draft-ietf-manet-olsrv2-multipath-13 Melinda Shore 2017-04-09 draft-ietf-core-coap-tcp-tls-08 For telechat 2017-05-25 Reviewer LC end Draft Donald Eastlake 2017-05-16 draft-ietf-oauth-native-apps-10 Shawn Emery 2017-05-16 draft-ietf-nfsv4-xattrs-05 Tobias Gondrom 2017-05-14 draft-ietf-calext-caldav-attachments-02 Ólafur Guðmundsson 2017-05-12 draft-ietf-nfsv4-versioning-09 Phillip Hallam-Baker 2017-05-12 draft-ietf-nfsv4-umask-03 Russ Housley 2017-05-19 draft-ietf-pals-vpls-pim-snooping-05 Christian Huitema 2017-05-19 draft-ietf-mpls-tp-aps-updates-03 Leif Johansson 2017-05-19 draft-ietf-idr-shutdown-08 Benjamin Kaduk 2017-05-18 draft-ietf-tls-ecdhe-psk-aead-03 David Waltermire 2017-05-17 draft-ietf-isis-l2bundles-05 For telechat 2017-06-08 Reviewer LC end Draft Alan DeKok 2017-05-26 draft-nottingham-rfc5988bis-05 Takeshi Takahashi R2017-05-02 draft-ietf-grow-bgp-reject-07 Last calls: Reviewer LC end Draft Daniel Franke 2017-05-15 draft-ietf-bmwg-vswitch-opnfv-03 Daniel Gillmor 2017-05-14 draft-ietf-netmod-yang-model-classification-06 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-08 Dacheng Zhang 2017-05-04 draft-ietf-spring-resiliency-use-cases-10 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Next in the reviewer rotation: Charlie Kaufman Scott Kelly Stephen Kent Tero Kivinen Watson Ladd Ben Laurie Barry Leiba Chris Lonvick David Mandelberg Catherine Meadows From nobody Thu May 11 15:33:22 2017 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 116DC1292AE; Thu, 11 May 2017 15:33:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley To: Cc: draft-ietf-pals-vpls-pim-snooping.all@ietf.org, ietf@ietf.org, pals@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149454198305.16624.16060763979327626869@ietfa.amsl.com> Date: Thu, 11 May 2017 15:33:03 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-pals-vpls-pim-snooping-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 22:33:03 -0000 Reviewer: Russ Housley Review result: Has Nits 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-pals-vpls-pim-snooping-05 Reviewer: Russ Housley Review Date: 2016-05-11 IETF LC End Date: 2017-05-19 IESG Telechat date: Unknown Summary: Has Nits I did not review the state machines in detail. I assume that others that are far more familiar with PIM have done s detailed review of them. No Major Concerns Minor Concerns Section 1 says: In that case, the PW related concept/procedures are not applicable and that's all. I am not sure what you are trying to tell the implementer. Please clarify. Section 1.3 includes: "rpt : Rendezvous Point", and Section 2.3 includes: "Rendezvous Points (RP)". Please pick one and use it throughout. In Section 2.2, please add a reference for the "split-horizon rule for mesh PWs" or add a pointer to the section where it is discussed further in this document. A better heading for Section 2.3.2 would be "IPv4 and IPv6". Nits Please change the language that makes reference to other "draft", such as: "As stated in the VPLS Multicast Requirements draft ...". This wording leads to changes by the RFC Editor, so it is better to use a word like "document". Please change "J/P messages" to "Join/Prune messages" throughout the document. The document uses both "learned" and "learnt". If there is a difference to the reader, it was too subtle for me to figure out. If they are the same, please pick one. In Section 1.1, rewording would add clarity: Depending on how the control messages are handled (transparently flooded, selectively forwarded, aggregated), the procedure/process may be called Snooping or proxy in different contexts. I suggest: Depending on whether the control messages are transparently flooded, selectively forwarded, or aggregated, the processing may be called Snooping or proxy in different contexts. Section 2.3 says: However, the PE does not need to have any routing tables like as required in PIM multicast routing. Please correct. I think you are trying to say: However, the PE does not need any routing tables like those required in PIM multicast routing. Section 4.2.1 says: Note that the differences apply only to PIM Join/Prune messages. PIM Hello messages are snooped and flooded in all cases. Wouldn't it be more clear to consume the same number of lines and add this information to the table. In Section 2.7 the document uses PIM-BIDIR and BIDIR-PIM, and they seem have the same meaning. Please pick one. From nobody Thu May 11 16:00:03 2017 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 CFBED12EC60; Thu, 11 May 2017 15:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 RBtbRjIa70eG; Thu, 11 May 2017 15:59:52 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 B4961129454; Thu, 11 May 2017 15:55:25 -0700 (PDT) X-AuditID: 1209190d-669ff70000001eeb-b5-5914ebdba30f Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 13.CF.07915.BDBE4195; Thu, 11 May 2017 18:55:24 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v4BMtMRR016181; Thu, 11 May 2017 18:55:22 -0400 Received: from localhost (nyc-02.triskelion.com [162.243.175.178]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v4BMtJcG024560; Thu, 11 May 2017 18:55:20 -0400 From: Taylor Yu To: Marius Georgescu Cc: Alfred C Morton , "iesg\@ietf.org" , "secdir\@ietf.org" , "draft-ietf-bmwg-ipv6-tran-tech-benchmarking.all\@ietf.org" References: <4D7F4AD313D3FC43A053B309F97543CF25F96C2C@njmtexg4.research.att.com> <3AF9B659-1229-43F8-BA74-1B5526277391@rcs-rds.ro> Date: Thu, 11 May 2017 22:55:19 +0000 In-Reply-To: <3AF9B659-1229-43F8-BA74-1B5526277391@rcs-rds.ro> (Marius Georgescu's message of "Tue, 9 May 2017 11:38:04 +0300") Message-ID: Lines: 37 MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJIsWRmVeSWpSXmKPExsUixCmqrHvntUikwa5uUYutxyYyWvyYM5XF YsaficwWz6/eY7L4sPAhiwOrx8v+OYweS5b8ZPJYdmQBcwBzFJdNSmpOZllqkb5dAlfGwQ8T WAru81T8nFrSwDiHq4uRk0NCwERi79mprF2MXBxCAouZJPrW7mOGcDYyStyd844dwvnGKHH7 4gOWLkYODjYBOYnLt4JBukUEjCT2/F/KDGIzC/xglHjSKARiCwtESSy7sokNovcVo8SCj8/Y QRIsAqoSJ07uYQJJcAo0Mkr8ODwJrJtXwEbi66FJjCA2jwCnxPfPM1gg4oISJ2c+YYHYICFx 8MUL5gmM/LOQpGYhSS1gZFrFKJuSW6Wbm5iZU5yarFucnJiXl1qka6SXm1mil5pSuokRHKKS vDsY/931OsQowMGoxMN7oFwkUog1say4MvcQoyQHk5IoL+NEoBBfUn5KZUZicUZ8UWlOavEh RgkOZiURXulXQDnelMTKqtSifJiUNAeLkjivuEZjhJBAemJJanZqakFqEUxWhoNDSYJ3F0ij YFFqempFWmZOCUKaiYMTZDgP0HAhsOHFBYm5xZnpEPlTjIpS4rz8IAkBkERGaR5cLyiFLPq8 ftMrRnGgV4R5xYAJRYgHmH7guoERAPSRCG//H2GQwSWJCCmpBkbXnuXXGv1y/Q7xPhLJ+b7n 9CSep0cLPgeHOGecZKqO/MgRsD5mctSCFcF3eb98XO+6g+ncu44di6pCCoJ3PntY4pQr/XCj w74zhdfvfl5YcPTCgppFkVrTn4d+WLUtkuVPgkCJWEAYt2i77J6awugEnhoZdgHv7CeFJcpC 22sWqV/nsrBaqa7EUpyRaKjFXFScCADwH8BT/AIAAA== Archived-At: Subject: Re: [secdir] secdir last call review of draft-ietf-bmwg-ipv6-tran-tech-benchmarking-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 22:59:54 -0000 Marius Georgescu writes: >> On May 8, 2017, at 4:34 AM, Taylor Yu wrote: >> I'm sorry, I guess I misinterpreted, then. Do you mean that the >> implementations tested in the benchmarking lab should not materially >> differ from ones intended for production? As in the tested >> implementations should be have neither stronger nor weaker security >> properties than their deployed counterparts? I might be able to suggest >> improved wording if I understand your intentions correctly. > Indeed, we meant that the implementations tested in the lab should not > differ from the ones intended for production. In that case, what do you think of the following change? OLD Further, benchmarking is performed on a "black-box" basis, relying solely on measurements observable external to the DUT/SUT. Special capabilities SHOULD NOT exist in the DUT/SUT specifically for benchmarking purposes. Any implications for network security arising from the DUT/SUT SHOULD be identical in the lab and in production networks. NEW Further, benchmarking is performed on a "black-box" basis, relying solely on measurements observable external to the DUT. Special capabilities SHOULD NOT exist in the DUT specifically for benchmarking purposes. Testers and implementors SHOULD ensure that the DUT has identical security properties to its production version. For example, any security hardening or instrumentation present on the DUT SHOULD also be present in the production version, and vice versa. Best regards, -Taylor From nobody Thu May 11 16:26:29 2017 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 A7917129BB8; Thu, 11 May 2017 16:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 XAfIumiyn6zb; Thu, 11 May 2017 16:26:20 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 1BFB212ECA4; Thu, 11 May 2017 16:21:49 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v4BNGWjD006735; Thu, 11 May 2017 19:21:46 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 2ad0a7spxt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 May 2017 19:21:45 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v4BNLiAl013894; Thu, 11 May 2017 19:21:45 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v4BNLZ3s013549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 May 2017 19:21:37 -0400 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Thu, 11 May 2017 23:21:20 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v4BNLKXN024885; Thu, 11 May 2017 18:21:20 -0500 Received: from mail-azure.research.att.com (mail-azure.research.att.com [135.207.255.18]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v4BNLCVb024518; Thu, 11 May 2017 18:21:13 -0500 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-azure.research.att.com (Postfix) with ESMTP id 7FB4AE08BB; Thu, 11 May 2017 19:21:12 -0400 (EDT) Received: from njmtexg4.research.att.com ([fe80::8cd:baa3:219e:5bd4]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Thu, 11 May 2017 19:21:12 -0400 From: "MORTON, ALFRED C (AL)" To: Taylor Yu , Marius Georgescu CC: "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-bmwg-ipv6-tran-tech-benchmarking.all@ietf.org" Thread-Topic: secdir last call review of draft-ietf-bmwg-ipv6-tran-tech-benchmarking-07.txt Thread-Index: AQHSyqmprHMSiqlIEE6+AQ7I+c+lNaHvv3Hg Date: Thu, 11 May 2017 23:21:10 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF25F9B349@njmtexg4.research.att.com> References: <4D7F4AD313D3FC43A053B309F97543CF25F96C2C@njmtexg4.research.att.com> <3AF9B659-1229-43F8-BA74-1B5526277391@rcs-rds.ro> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.214.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-11_19:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705110159 Archived-At: Subject: Re: [secdir] secdir last call review of draft-ietf-bmwg-ipv6-tran-tech-benchmarking-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 23:26:22 -0000 Hi Taylor, please see in-line reply, thanks, Al > -----Original Message----- > From: Taylor Yu [mailto:tlyu@mit.edu] > Sent: Thursday, May 11, 2017 6:55 PM > To: Marius Georgescu > Cc: MORTON, ALFRED C (AL); iesg@ietf.org; secdir@ietf.org; draft-ietf- > bmwg-ipv6-tran-tech-benchmarking.all@ietf.org > Subject: Re: secdir last call review of draft-ietf-bmwg-ipv6-tran-tech- > benchmarking-07.txt >=20 > Marius Georgescu writes: >=20 > >> On May 8, 2017, at 4:34 AM, Taylor Yu wrote: >=20 > >> I'm sorry, I guess I misinterpreted, then. Do you mean that the > >> implementations tested in the benchmarking lab should not materially > >> differ from ones intended for production? As in the tested > >> implementations should be have neither stronger nor weaker security > >> properties than their deployed counterparts? I might be able to > suggest > >> improved wording if I understand your intentions correctly. >=20 > > Indeed, we meant that the implementations tested in the lab should not > > differ from the ones intended for production. >=20 > In that case, what do you think of the following change? >=20 > OLD >=20 > Further, benchmarking is performed on a "black-box" basis, relying > solely on measurements observable external to the DUT/SUT. Special > capabilities SHOULD NOT exist in the DUT/SUT specifically for > benchmarking purposes. Any implications for network security arising > from the DUT/SUT SHOULD be identical in the lab and in production > networks. >=20 > NEW >=20 > Further, benchmarking is performed on a "black-box" basis, relying > solely on measurements observable external to the DUT. Special > capabilities SHOULD NOT exist in the DUT specifically for > benchmarking purposes. Testers and implementors SHOULD ensure that > the DUT has identical security properties to its production version. [ACM]=20 This new sentence has redundant effect with second sentence (unchanged). Furthermore, Testing personnel have no means to ensure the identical=20 properties, and implementers may not yet have a production version availabl= e (Benchmarking often takes place with very early products, whose non-tested aspects may change before reaching production). > For example, any security hardening or instrumentation present on the > DUT SHOULD also be present in the production version, and vice versa. [ACM]=20 Again, this cannot be ensured when it is not a tested feature,=20 and there may be *many* (later) production releases that differ=20 from the DUT. The example goes too far. At this point, I feel it is appropriate to point out that BMWG has=20 used the original wording of the paragraphs in this section for years (~10), and their intent has been sufficiently clear to the community. >=20 > Best regards, > -Taylor From nobody Fri May 12 12:47:19 2017 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 752FD12EB55 for ; Fri, 12 May 2017 12:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, RP_MATCHES_RCVD=-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=google.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 1Q64bFFOiXLJ for ; Fri, 12 May 2017 12:47:16 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E19F12EC0E for ; Fri, 12 May 2017 12:42:51 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id j17so52470920uag.3 for ; Fri, 12 May 2017 12:42:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Q0u54JhcezyvtG+8A/gDTM3J0AF9AEqYNSRSRAEjC08=; b=QaOHecRP+3DzYnOQYMPhtDabWVr5H8hgDauA4JZhOpDGAfhxI8rPiGtoDJ+XGgl/Op aimD8Im9ECWv7dYomE//QfSUYWqRA6zUFmH+PpoyCD/nz5PB/dgXz/p24aFUKZctqJTs cVC6o9zf81q/pkOksjMuHtGcC0ejA7y/9DLdaEbzg3V1ny5qfmfo3zMTj8COfTZsN3N9 0HySeaSDlYPhic6T69Kw4RcCmhVVFELqMK/PY1uIzyNr8mnGEgvoDypE6WCidJsg2jWo +j/Ur/4+3xS4kOPEA9sB8BOyKtUgtB8E/mDqXxSrkgZ/omSZJ604ZE41VUpcOrRJRZUz XFJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Q0u54JhcezyvtG+8A/gDTM3J0AF9AEqYNSRSRAEjC08=; b=s/A7Ty1G1lxME2D/uuJvsQ0fr4rq2VVpzwbkX2Sh/KaUgSmvmcf3sLrJAvGu0DLlGY uNpYcDsPZrjcQNoEHcS5+nVEJTH/9B2ik7fJjG/WUmRj1x3ySsbcmN03AmLXzmoVQH55 Z6W+kABFRuYxN7N3Y2UpQD7/TTefh9+qHQyrSid/VAvc4aYxP9s+udJjRm9utVBBAisV hvFUovFSFemIuuqfFyu+XFCNs4ADlQ8+dy+nDVrB0DP/at6vuVsPS/w3/TpTI/FaPaqE eOnYkXTN3D9PrXajcakhhHaa43MT3UMUH8K1mChyjJ8O6q5Vm4iNcxp7+TwkJqlfp4QP J1Lw== X-Gm-Message-State: AODbwcDwztRM9CwwqJjODP2KUnk1Cb3I67fnpUwWAWnemnmeyh5k5glC IQf8mW2mpNVgl/fsK8giJ+PcbSg+AU5B X-Received: by 10.176.85.145 with SMTP id v17mr3046197uaa.148.1494618168626; Fri, 12 May 2017 12:42:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.167.21 with HTTP; Fri, 12 May 2017 12:42:47 -0700 (PDT) In-Reply-To: References: From: Ben Laurie Date: Fri, 12 May 2017 20:42:47 +0100 Message-ID: To: Sara Dickinson Cc: The IESG , "secdir@ietf.org" , draft-ietf-dprive-dtls-and-tls-profiles.all@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] Security review of draft-ietf-dprive-dtls-and-tls-profiles-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 19:47:19 -0000 On 8 May 2017 at 08:44, Sara Dickinson wrote: > >> On 4 May 2017, at 12:11, Ben Laurie 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. >> > > Hi Ben, > > Thanks for the review. > >> Status: not ready. >> >> I am a little puzzled by this I-D. The title is "Authentication and >> (D)TLS Profile for DNS-over-(D)TLS" and the intro says it specifies >> profiles which "which define the security properties a user should >> expect when using that profile to connect to the available DNS >> servers", however, as far as I can see, no properties other than >> server authentication are defined. > > Section 5 is really the part of the draft intended to address this by out= lining in detail the security properties a user should expect when using ei= ther a Strict or Opportunistic Profile to connect to the available DNS serv= ers. So by security properties we really mean mitigation against passive at= tack (via encryption alone) or active attack (by using encryption in combin= ation with authentication). OK, so what you're really aiming at is mitigation of trivial MitM attacks on the underlying crypto. So how about making the title (and summary) be "Avoiding Trivial MitM Attacks on DNS-over-(D)TLS"? > > In developing the draft we found widespread uncertainly among the DNS com= munity as to precisely what Opportunistic Security was and how it differed = from Strict. For example it became apparent that many DNS folks didn=E2=80= =99t realise that Opportunistic could include falling back to clear text th= us providing no security guarentees. That is why the table in Section 5 is= provided to (hopefully) clarify these concepts and expectations. It might = seem overkill to those with a strong security background but we had enough = iterations on this during working group review that it really did seem nece= ssary. > > Would re-wording the introduction text to say something like > > =E2=80=9CThis document specifies two Usage Profiles (Strict and Opportuni= stic) for DTLS [RFC6347] and TLS [RFC5246] which provide different levels o= f attack mitigation over using only clear text DNS.=E2=80=9D > > be a start in addressing this? A start, but it leaves entirely vague what attack you might be mitigating. I guess the core problem is I don't see a clear articulation of the threat model. I'd hazard a guess from the above that it's essentially: "there should be no man in the middle who can trivially get plaintext". If the claim is you mitigate that threat with "Strict" then I would then only have to argue about how authentication occurs, rather than how all "security properties" occur. >> The document also appears to claim that a connection that is >> authenticated and encrypted is "private" - that seems to stretch the >> meaning of "private" quite considerably. > > It wasn=E2=80=99t the intent to claim complete privacy via these Profiles= . I _thought_ we had been quite careful in always using a phrase such as = =E2=80=9CThis profile provides strong privacy guarantees to the client.=E2= =80=9D rather than saying =E2=80=99This provides a private connection=E2=80= =9D but perhaps I missed something? I think that most users have no idea what the difference is between those two statements. > This seems to go back to the same issue of wording and so I wonder that i= f we had used a phrase like =E2=80=98attack mitigation=E2=80=99 throughout = instead of 'privacy guarantees=E2=80=99 it would read more clearly? Yes. And you need to say what attack you mitigate. :-) >> Other considerations surely exist, such as resistance against traffic >> analysis, key sizes, algorithm choice. > > We do attempt to address these issues separately in later sections, speci= fically: > - Section 11 =E2=80=98Counter measures to DNS Traffic Analysis=E2=80=99 = recommending padding SHOULD be done by both client and server and > - Section 9 '(D)TLS Protocol Profile' where rather than making specific = recommendations for DNS we state that client and servers MUST adhere to RFC= 7275 and MUST use TLS 1.2 or later, etc. > >> >> As a result, claims like "Strict Privacy provides the strongest >> privacy guarantees" are just plain wrong. > > Better written as =E2=80=9CStrict Privacy provides the strongest privacy = guarantees of the two Profiles described here=E2=80=9D? Technically, I think you can only claim it is at least as strong. Unless you have a magic authentication story. :-) > Again, the intention isn=E2=80=99t to portray Strict Privacy as some sort= of =E2=80=98perfect privacy=E2=80=99 just as the =E2=80=98best privacy ava= ilable=E2=80=99. > > I=E2=80=99m hoping this is a general problem generated by the use of a ha= ndful of phrases in the document that I now realise could be read with a di= fferent context. If you also think this is the fundamental issue then I wou= ld suggest the authors take a pass over the document to try to address this= by either changing this wording or carefully defining what these terms mea= n in the context of this document. > > Regards > > Sara. > From nobody Mon May 15 23:37:22 2017 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 66D1D12EB5B; Mon, 15 May 2017 23:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fFGe3KOTwkH; Mon, 15 May 2017 23:37:11 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40C17129B16; Mon, 15 May 2017 23:34:07 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id h4so13566805oib.3; Mon, 15 May 2017 23:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y+sMk1WeIPkGlEWtiLenezqkzrtjt+ltbLeQWGFNyvE=; b=HwabV3LAsS/u8Kyxonye4aKd5doQ1eh/OWe44+FJTMugNtIchvcCJIfh8Am9Sj/YDy ObiKwGiclwntItL8f1b0kHDoo/bS7WI1eD54hvCna6+9p4TvqS10e9JihSMRyldtT1B+ 24xLxJhFAKPky9ZgvdeuP5eQEctg8wLw9Zdn+pG4fJXnNg3cLo+nP5PxgtpXsNsWesSl 99OkJj5YisjZEyU5uLeY+E32PRx/nZJcA63wSx7DLjNDrj7k03+cmrxAVL6F75QOa2Pn 68WAUpxye5aepbMFH2I4eUQZ8I86YQeU3rChGRuXxlDFT434+B/CLBUo3uesT7KszF/v aB/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Y+sMk1WeIPkGlEWtiLenezqkzrtjt+ltbLeQWGFNyvE=; b=of2fm8VJ998qV7mBhAbr+upBuRiJ6wLMzuFMOBmgTZ3qPP+euqMOxTNwnn69kGhnch fVa0dHsVFOyKvRUlF5dzG8BVXUsOFq1mCHK+pB+I4dg1T8n6HtFaFQpdOx7qE+XUThLj sgv1GooxvKlsZFrdghJBz8Uk3efyWdYpjnIwdkf65qDDiAktNdw+WWT+iZMzQQV4oc6b iku8HvOZ/dtsYOLt3s/BSkAycYcu4XcoNgA+/jfPI/gHlF4lw6pbxjeqBMXJnT6NuN3g jIyjGUMMmeihp10PecbIoIf4iDu+K0wU8wXvzKpx0yWnBMSrK41mN9SiXcJ1SMpQQsP6 IpXg== X-Gm-Message-State: AODbwcAZG+ct3n7O4Ar7L9XttgVxFiETR7LURUOzwv1lGckw06Uy77Bs ZLAVSPMbz5+yrUdSmFyZpTUWXErnLg== X-Received: by 10.202.77.73 with SMTP id a70mr934615oib.126.1494916446681; Mon, 15 May 2017 23:34:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.132 with HTTP; Mon, 15 May 2017 23:33:46 -0700 (PDT) In-Reply-To: <149454198305.16624.16060763979327626869@ietfa.amsl.com> References: <149454198305.16624.16060763979327626869@ietfa.amsl.com> From: "Andrew G. Malis" Date: Tue, 16 May 2017 14:33:46 +0800 Message-ID: To: Russ Housley Cc: secdir@ietf.org, draft-ietf-pals-vpls-pim-snooping.all@ietf.org, IETF Discussion , "pals@ietf.org" Content-Type: multipart/alternative; boundary="001a11c17d42c60417054f9e5b66" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-pals-vpls-pim-snooping-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 06:37:13 -0000 --001a11c17d42c60417054f9e5b66 Content-Type: text/plain; charset="UTF-8" Russ, Thanks for your review! Cheers, Andy On Fri, May 12, 2017 at 6:33 AM, Russ Housley wrote: > Reviewer: Russ Housley > Review result: Has Nits > > 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-pals-vpls-pim-snooping-05 > Reviewer: Russ Housley > Review Date: 2016-05-11 > IETF LC End Date: 2017-05-19 > IESG Telechat date: Unknown > > Summary: Has Nits > > I did not review the state machines in detail. I assume that others > that are far more familiar with PIM have done s detailed review of > them. > > > No Major Concerns > > > Minor Concerns > > Section 1 says: > > In that case, the PW related concept/procedures are not > applicable and that's all. > > I am not sure what you are trying to tell the implementer. > Please clarify. > > Section 1.3 includes: "rpt : Rendezvous Point", and Section 2.3 > includes: "Rendezvous Points (RP)". Please pick one and use it > throughout. > > In Section 2.2, please add a reference for the "split-horizon rule > for mesh PWs" or add a pointer to the section where it is discussed > further in this document. > > A better heading for Section 2.3.2 would be "IPv4 and IPv6". > > > Nits > > Please change the language that makes reference to other "draft", > such > as: "As stated in the VPLS Multicast Requirements draft ...". This > wording leads to changes by the RFC Editor, so it is better to use a > word like "document". > > Please change "J/P messages" to "Join/Prune messages" throughout the > document. > > The document uses both "learned" and "learnt". If there is a > difference > to the reader, it was too subtle for me to figure out. If they are > the > same, please pick one. > > In Section 1.1, rewording would add clarity: > > Depending on how the control messages are handled > (transparently flooded, selectively forwarded, aggregated), the > procedure/process may be called Snooping or proxy in different > contexts. > > I suggest: > > Depending on whether the control messages are > transparently flooded, selectively forwarded, or aggregated, the > processing may be called Snooping or proxy in different contexts. > > Section 2.3 says: > > However, the PE does not need to have any routing tables like as > required in PIM multicast routing. > > Please correct. I think you are trying to say: > > However, the PE does not need any routing tables like those > required in PIM multicast routing. > > Section 4.2.1 says: > > Note that the differences apply only to PIM Join/Prune messages. > PIM > Hello messages are snooped and flooded in all cases. > > Wouldn't it be more clear to consume the same number of lines and add > this information to the table. > > In Section 2.7 the document uses PIM-BIDIR and BIDIR-PIM, and they > seem > have the same meaning. Please pick one. > > > --001a11c17d42c60417054f9e5b66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Russ,

Thanks for your review!

Cheers,
Andy

On Fri, May 12, 2017 at 6:33 AM, Russ Hous= ley <housley@vigilsec.com> wrote:
Reviewer: Russ Housley
Review result: Has Nits

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.=C2=A0 Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments.

Document: draft-ietf-pals-vpls-pim-snooping-05
Reviewer: Russ Housley
Review Date: 2016-05-11
IETF LC End Date: 2017-05-19
IESG Telechat date: Unknown

Summary: Has Nits

I did not review the state machines in detail.=C2=A0 I assume that others that are far more familiar with PIM have done s detailed review of
them.


No Major Concerns


Minor Concerns

Section 1 says:

=C2=A0 =C2=A0In that case, the PW related concept/procedures are not
=C2=A0 =C2=A0applicable and that's all.

I am not sure what you are trying to tell the implementer.
Please clarify.

Section 1.3 includes: "rpt : Rendezvous Point", and Section 2.3 includes: "Rendezvous Points (RP)".=C2=A0 Please pick one and use= it
throughout.

In Section 2.2, please add a reference for the "split-horizon rule
for mesh PWs" or add a pointer to the section where it is discussed further in this document.

A better heading for Section 2.3.2 would be "IPv4 and IPv6".


Nits

Please change the language that makes reference to other "draft",=
such
as: "As stated in the VPLS Multicast Requirements draft ...".=C2= =A0 This
wording leads to changes by the RFC Editor, so it is better to use a
word like "document".

Please change "J/P messages" to "Join/Prune messages" t= hroughout the
document.

The document uses both "learned" and "learnt".=C2=A0 If= there is a
difference
to the reader, it was too subtle for me to figure out.=C2=A0 If they are the
same, please pick one.

In Section 1.1, rewording would add clarity:

=C2=A0 =C2=A0Depending on how the control messages are handled
=C2=A0 =C2=A0(transparently flooded, selectively forwarded, aggregated), th= e
=C2=A0 =C2=A0procedure/process may be called Snooping or proxy in different=
=C2=A0 =C2=A0contexts.

I suggest:

=C2=A0 =C2=A0Depending on whether the control messages are
=C2=A0 =C2=A0transparently flooded, selectively forwarded, or aggregated, t= he
=C2=A0 =C2=A0processing may be called Snooping or proxy in different contex= ts.

Section 2.3 says:

=C2=A0 =C2=A0However, the PE does not need to have any routing tables like = as
=C2=A0 =C2=A0required in PIM multicast routing.

Please correct.=C2=A0 I think you are trying to say:

=C2=A0 =C2=A0However, the PE does not need any routing tables like those =C2=A0 =C2=A0required in PIM multicast routing.

Section 4.2.1 says:

=C2=A0 =C2=A0Note that the differences apply only to PIM Join/Prune message= s.
PIM
=C2=A0 =C2=A0Hello messages are snooped and flooded in all cases.

Wouldn't it be more clear to consume the same number of lines and add this information to the table.

In Section 2.7 the document uses PIM-BIDIR and BIDIR-PIM, and they
seem
have the same meaning.=C2=A0 Please pick one.



--001a11c17d42c60417054f9e5b66-- From nobody Tue May 16 18:02:59 2017 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 0045213147C; Tue, 16 May 2017 18:02:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Huitema To: Cc: mpls@ietf.org, draft-ietf-mpls-tp-aps-updates.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149498296095.6616.14922755167741082096@ietfa.amsl.com> Date: Tue, 16 May 2017 18:02:40 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-mpls-tp-aps-updates-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 01:02:41 -0000 Reviewer: Christian Huitema 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. This document, draft-ietf-mpls-tp-aps-updates-03, describes a set of fixes to the MPLS Transport Profile (MPLS-TP) Linear Protection defined in RFC 6378. Linear Protection is meant to provide rapid and simple protection switching. MPLS-TP allows end-points in a "protected domain" to coordinate when the traffic shall be sent on the normal path, or switched to the pre-established protection path. The protocol was updated in RFC 7271. The current document updates RFC 7271. It adds a better definition for the initialization of the protocol state, and defines a limited set of changes in the state machine. The security sections states that "No specific security issue is raised in addition to those ones already documented in [RFC7271]. It may be noted that tightening the description of initializing behavior may help to protect networks from re-start attack." I agree with that assessment. From nobody Thu May 18 04:50:12 2017 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 DF5DE12EB4B for ; Thu, 18 May 2017 04:50:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <149510821082.6616.1242087504875029079.idtracker@ietfa.amsl.com> Date: Thu, 18 May 2017 04:50:10 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 11:50:11 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-05-25 Reviewer LC end Draft Donald Eastlake 2017-05-16 draft-ietf-oauth-native-apps-10 Shawn Emery 2017-05-16 draft-ietf-nfsv4-xattrs-05 Tobias Gondrom 2017-05-14 draft-ietf-calext-caldav-attachments-02 Ólafur Guðmundsson 2017-05-12 draft-ietf-nfsv4-versioning-09 Phillip Hallam-Baker 2017-05-12 draft-ietf-nfsv4-umask-03 Leif Johansson 2017-05-19 draft-ietf-idr-shutdown-08 Benjamin Kaduk 2017-05-18 draft-ietf-tls-ecdhe-psk-aead-03 David Waltermire 2017-05-17 draft-ietf-isis-l2bundles-05 For telechat 2017-06-08 Reviewer LC end Draft Alan DeKok 2017-05-26 draft-nottingham-rfc5988bis-05 Takeshi Takahashi R2017-05-02 draft-ietf-grow-bgp-reject-07 Last calls: Reviewer LC end Draft Daniel Franke 2017-05-15 draft-ietf-bmwg-vswitch-opnfv-03 Daniel Gillmor 2017-05-14 draft-ietf-netmod-yang-model-classification-07 Charlie Kaufman 2017-05-28 draft-ietf-curdle-cms-ecdh-new-curves-07 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-08 Dacheng Zhang 2017-05-04 draft-ietf-spring-resiliency-use-cases-10 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Next in the reviewer rotation: Scott Kelly Stephen Kent Tero Kivinen Watson Ladd Ben Laurie Barry Leiba Chris Lonvick David Mandelberg Catherine Meadows Alexey Melnikov From nobody Thu May 18 09:15:34 2017 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 F22D212AF77; Thu, 18 May 2017 09:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O_KNYoNl0MAl; Thu, 18 May 2017 09:15:19 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A712129AF1; Thu, 18 May 2017 09:10:03 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id b204so60209487oii.1; Thu, 18 May 2017 09:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=xMSMYPjx9hnV07u+1cxjiqByA+D/cXAoGT3KL2CFMMg=; b=LdO5nTp/zUxAo2MVsA2uLRgV2/a6UJG/oB7sWcdOneAamKGNM96zeCWDZwMwEde9Sr 4T/TnxnhcbMYFbnoPx99TCPKgFlISfXc6C+XTU+pcb9UdgNQ6jNAT7v6Htq1NyYqGcUX BLcgx0Xh+UkIgiQ1iJgmdN/hVLYVSPa5nUIJ87Vkx08XGawE/FPduqThJadzo2Az2ONK 0iiD0KwvwdpZBs+9VTnX4bW6RmqFHTL5A6PKS7qOvqQvmTeb/YNYq9MCS88Oq4Sd2Rbp 3zSsIiBPTUiRd1b1M5RFrfRoIyhXj8q0aKWFPZsA0kUvQJYamWaHnqRaDnfKfshTPOmi 1Pfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=xMSMYPjx9hnV07u+1cxjiqByA+D/cXAoGT3KL2CFMMg=; b=CvpQAdgT7tw6GeFypIc0XJ+6rmUFhWRpDwwbuIvqXpG2vz81sBenCcspEo+aOGyecT clqoab8+xpBbEkr8PzIKVp924EYWN+DhMn25JyLHIP7Gij8iWkiEjwr3CxNN9IMM6pCf EZkaOVcZs2Tr+hw0oW2iJkTmTDlAW+K7Y6pcv3xJQ8awrsLp6UIjYVJhluRgKc1nRCWk 106mvYCFLVR2QKttOopU/uEkF7pvtw0LUW0teewE8dJKZ/AidZ3rURQTCHJXb4Ed9Myi hwKVsYF5+uLNpOxhwLQWLa84KhMzaFtUITxYJFqDvy5S7mb3rfw9X+RZ7P1lnc82vpaB yfqA== X-Gm-Message-State: AODbwcAcfGdIOysaaBt5pcUspACT6SGhP+XF7ovIYokH79Zk/BbCIKYo r479vSBS80D36JZ0g0drOUNstbFapwiA X-Received: by 10.157.25.25 with SMTP id j25mr2908327ota.112.1495123802441; Thu, 18 May 2017 09:10:02 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.17.34 with HTTP; Thu, 18 May 2017 09:10:01 -0700 (PDT) From: Phillip Hallam-Baker Date: Thu, 18 May 2017 12:10:01 -0400 X-Google-Sender-Auth: qyYwXBZ4yh373lKGMsoFIZLSomY Message-ID: To: "secdir@ietf.org" , draft-ietf-nfsv4-umask.all@ietf.org, IETF Discussion Mailing List Content-Type: multipart/alternative; boundary="f4030435b94823ce08054fcea385" Archived-At: Subject: [secdir] SECDIR Review of draft-ietf-nfsv4-umask-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 16:15:22 -0000 --f4030435b94823ce08054fcea385 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Reviewer: =E2=80=8BPhillip Hallam-Baker Review result: =E2=80=8BOK but...=E2=80=8B 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: Review of draft-ietf-nfsv4-umask-03 Reviewer: =E2=80=8BPhillip Hallam-Baker Review result: =E2=80=8BOK but...=E2=80=8B This particular draft looks OK to me. Aligning the semantics of NFS with the semantics of the file system seems to me to be absolutely the way to go forward. I am not sufficiently experienced in the semantics of NFS or Unix as deployed to be able to offer an opinion on whether the draft achieves that. However it appears that the author does. =E2=80=8BWhat is problematic here is that the Security Considerations in th= e draft are essentially relying on those in rfc7530 which are woefully inadequate given the critical role of NFS in Internet security. They are not so much a security plan as a collection of random thoughts jotted down in haphazard fashion.=E2=80=8B There is clearly no coherent model of what NFS security should achieve, what the threats are, what controls are deployed to control them. Also note that the main reason this review is late is that I have been dealing with issues arising from WannaCry which used an SMB:1 exploit. Re-reading RFC7530 in the light of that experience gives me grave concern. --f4030435b94823ce08054fcea385 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Reviewer:=C2=A0=E2=80=8BPhillip Hallam-= Baker

= Review result:=C2=A0
=E2=80=8BOK but...=E2=80=8B


= I reviewed this document as part of the Security Directorate'songoing
effort to = review all IETF documents being processed by the IESG.
These
comments were written pr= imarily for the benefit of the Security Area
Directors.=C2=A0 Document authors, = document editors, and WG chairs should
treat these comments just like any other = IETF Last Call comments.

Document:=C2=A0Review of= draft-ietf-nfsv4-umask-03
Reviewer:
=E2=80=8BPhillip Hallam-Baker



Review result:=C2=A0=E2=80=8BOK but...=E2=80= =8B
Thi= s particular draft looks OK to me. Aligning the semantics of NFS with the s= emantics of the file system seems to me to be absolutely the way to go forw= ard. I am not sufficiently experienced in the semantics of NFS or Unix as d= eployed to be able to offer an opinion on whether the draft achieves that. = However it appears that the author does.

=E2=80=8BWhat is problematic here is t= hat the Security Considerations in the draft are essentially relying on tho= se in rfc7530 which are woefully inadequate given the critical role of NFS = in Internet security. They are not so much a security plan as a collection = of random thoughts jotted down in haphazard fashion.=E2=80=8B

There is clear= ly no coherent model of what NFS security should achieve, what the threats = are, what controls are deployed to control them. Also note that the main re= ason this review is late is that I have been dealing with issues arising fr= om WannaCry which used an SMB:1 exploit. Re-reading RFC7530 in the light of= that experience gives me grave concern.

--f4030435b94823ce08054fcea385-- From nobody Thu May 18 21:43:40 2017 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 70A81129C6E; Thu, 18 May 2017 21:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdrSVNrUSx8o; Thu, 18 May 2017 21:43:21 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 DBABA129C13; Thu, 18 May 2017 21:38:35 -0700 (PDT) X-AuditID: 1209190f-db7ff70000005284-13-591e76c97452 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 4E.26.21124.9C67E195; Fri, 19 May 2017 00:38:34 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v4J4cWgl014307; Fri, 19 May 2017 00:38:33 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v4J4cRQa011042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 May 2017 00:38:31 -0400 Date: Thu, 18 May 2017 23:38:27 -0500 From: Benjamin Kaduk To: iesg@ietf.org, secdir@ietf.org, draft-ietf-tls-ecdhe-psk-aead.all@ietf.org Cc: tls@ietf.org, ietf@ietf.org Message-ID: <20170519043827.GL39245@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDIsWRmVeSWpSXmKPExsUixG6nrnuqTC7SYP57GYs3yzYxWcz4M5HZ 4tnG+SwWHxY+ZLH4dL6L0YHVY8mSn0wBjFFcNimpOZllqUX6dglcGT0P9rAWfJapWPr7P2MD 41bxLkYODgkBE4lLb1y7GLk4hAQWM0mc3vWUHcLZyCjx4m4rK4RzlUniZNdJIIeTg0VAVWLV 4WvsIDabgIpEQ/dlZhBbRMBPYt2P90wgNrOAvMSidzfBaoQFrCR+bvwDFucF2vZpRRcbhC0o cXLmExaIei2JG/9eMoFcxCwgLbH8HwdIWFRAWeLv4XssExj5ZiHpmIWkYxZCxwJG5lWMsim5 Vbq5iZk5xanJusXJiXl5qUW6Jnq5mSV6qSmlmxhBgcgpyb+DcU6D9yFGAQ5GJR7eBytkI4VY E8uKK3MPMUpyMCmJ8s4IkIsU4kvKT6nMSCzOiC8qzUktPsQowcGsJMIrLgaU401JrKxKLcqH SUlzsCiJ84prNEYICaQnlqRmp6YWpBbBZGU4OJQkeJeVAjUKFqWmp1akZeaUIKSZODhBhvMA Dc8HqeEtLkjMLc5Mh8ifYlSUEue1KAFKCIAkMkrz4HpBiUIie3/NK0ZxoFeEeb1B2nmASQau +xXQYCagwc0PpEEGlyQipKQaGB1b8nfVilR23Fh8536vG9fSB1ev3/FOM/Tvi/9bf+exkMXs F+6TV/FeWuVulP3j4d830Ys3hhuu2/tobdPl2PPSLp0KSs8v2+/6KnBPZHvHlaU3wto23q0K WXRz6pLyd7xn3K5ML5dMWLJpQqx1HZPjA3fu3yx2S5b5mQUm/hNaN43xy+nF254qsRRnJBpq MRcVJwIA6NGlB+8CAAA= Archived-At: Subject: [secdir] secdir review of draft-ietf-tls-ecdhe-psk-aead-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 04:43:23 -0000 Hi all, 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 with nits. Essentially, we are filling in a gap in the TLS (< 1.3) ciphersuite space, thought of as a cross product of key exchange and cipher+mac/AEAD -- we have some of the combinations (PSK with ECDHE but no AES-[GC]CM, PSK with AES-GCM but only non-EC DH, etc.) but not quite this one. That said, it seems a little silly to only partially fill the gap (by omitting the AES_256_CCM* cipher suites), even though there is not currently demand for them. This document is just assembling pieces that were already specified elsewhere, so it need not contain much detail itself, which is fine. That said, I think section 3 should probably state explicitly which pieces it uses, instead of a vague reference of being "based on RFC 4279". So, "The ServerKeyExchange and ClientKeyExchange messages from RFC 5489 for ECDHE_PSK are used, and the premaster secret is computed in the same manner as for ECDHE_PSK key exchange in RFC 5489." (I am not sure why RFC 4279 is cited in the current text; it does not cover ECDHE_PSK.) The premaster_secret structure so used basically ends up putting the ECDH output first followed by the static PSK; with the pre-TLS 1.2 PRF, that would give the ECDH shared secret to md5 and the PSK to sha1, which is perhaps another reason to not use these with pre-1.2 worth mentioning (in addition to the AEAD availability). The security considerations largely refer to those of the other documents providing the pieces that are combined together here; those referenced security considerations sections are more than adequate here, as this document itself does not really do anything particularly novel. That said, if we are going to reiterate the entropy requirement for PSKs inline, we probably ought to also reiterate the nonce-reuse considerations for GCM and CCM. The relevant constructions help, but there are still ways to mess up and reuse a nonce when doing crypto in parallel, if I remember the GCM/TLS document's security considerations correctly. Some other editorial nits follow. I see we're already discussing "perfect forward secrecy" vs. "forward secrecy"; my preference is for just "forward secrecy" (and I may have been one of the more active voices in causing TLS 1.3 to switch), but in the grand scheme of things it doesn't really matter. In section 2, the RFC 7525 reference that "AEAD algorithms [...] are strongly recommended" is scoped to just (D)TLS, so the text here should probably also list that qualification. In section 4, "... make use of the authenticated encryption with additional data (AEAD) defined in TLS 1.2" seems to make AEAD into something of a unique object, as opposed to a class of things with multiple possible instantiations. I would consider something like "... (AEAD) concept". In section 4, "these cipher suites MUST NOT be negotiated in TLS versions prior to 1.2" should probably clarify that "these" cipher suites are the new ones specified by this document. s/Servers,\nwhich/Servers\nthat/ Does the last paragraph of section 5 want a note "RFC Editor please remove this paragraph"? Section 6, third paragraph, s/by using short PSK/by using a short PSK/. Also, s/by a human and thus/by a human which thus/, maybe? Last paragraph page 4, comma after "i.e.". -Ben From nobody Fri May 19 00:22:11 2017 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 918EA129ADA; Fri, 19 May 2017 00:21:52 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8ieFsHbj3_R; Fri, 19 May 2017 00:21:51 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ACF0127A91; Fri, 19 May 2017 00:16:36 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id c13so51911702qtc.1; Fri, 19 May 2017 00:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=1l6wwkBmmZlH9uo3WF1lXR/upb5w3DhmVxp3H96FKuE=; b=CFImJbKua/vDQNK96rHApq84iAOeHIUZnaZcwkHkBj14ZqF8y5wUjljxV4GhebYG4u Y2mD095XN+5VHGPymg1T/Y59+ErQuJKUvdDc9JdtiHkRe2oNxXiW7gBTlP04G6iCVAXw GyxkheQyUBqWkZvqWEX/zy2Vb/kjsxTqy/k94BCJstWCzSAAceKLoZYYhjZ2kKdP4RSb GtbFPGTP8CBi9UxOrgBbgErHc21RqarB/LyVGjAoCUqQEmFqMjkDcN153HNCQ2EpdR5n alkbnvU6z+hSEbkYM7gEy/RWYew37WVDNg3Y1y2Fxja2wrc41Ub+tbXva7pXQ7Bw07wn ry0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=1l6wwkBmmZlH9uo3WF1lXR/upb5w3DhmVxp3H96FKuE=; b=iAyoaT7C+wAskUFNVLQJZJxw9SFTICp4NV4RcMkZE8+w8SObNW1B9YPPHECwfqus9f h5xS67so4uRBozDGHZBaBTM2Wa2lInLfsGnaYRYtXlJIdK8e1H36pONcOuaCuIjYim9W i2vdh+pNz72MeG1+ilekDAKpqO96+c0Wal5eZ7Z1IAWQsh5p37r4NHKGSJoQkYrLROiP oQ4uYqunQItjMGe547yI4kQAsTTzUd2baBXZzURPEVJ8vM51ZHqOZKvQz2fXgSfH2WCT XN8YkPo3Ql2Ea3WwrGSpb5OGp4AbtH7zv/XpoHkJ/bQaN65/XAF1+BoxFKWVN4eogpXv vrqA== X-Gm-Message-State: AODbwcCzJz/ZSNp/ezDRdOCVUE3hGnarFT8+qvE+GSsA3Ug7fPUroj1W NzQK/92nM/OhOA2oOrk= X-Received: by 10.200.56.243 with SMTP id g48mr8729225qtc.79.1495178195474; Fri, 19 May 2017 00:16:35 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-36-197.phlapa.fios.verizon.net. [71.185.36.197]) by smtp.gmail.com with ESMTPSA id o13sm5426365qke.30.2017.05.19.00.16.34 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 19 May 2017 00:16:34 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Fri, 19 May 2017 03:16:32 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) Cc: Benjamin Kaduk , iesg@ietf.org, secdir@ietf.org, draft-ietf-tls-ecdhe-psk-aead.all@ietf.org, ietf@ietf.org References: <20170519043827.GL39245@kduck.kaduk.org> In-Reply-To: <20170519043827.GL39245@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201705190316.33316.davemgarrett@gmail.com> Archived-At: Subject: Re: [secdir] [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 07:21:53 -0000 On Friday, May 19, 2017 12:38:27 am Benjamin Kaduk wrote: > In section 4, "these cipher suites MUST NOT be negotiated in TLS > versions prior to 1.2" should probably clarify that "these" cipher > suites are the new ones specified by this document. Probably should be: "the cipher suites defined in this document MUST NOT be negotiated for any version of TLS other than 1.2." The sentence mentioning TLS 1.3+ could be moved up to right after and just say: "TLS version 1.3 and later negotiate these features in a different manner." Dave From nobody Fri May 19 01:19:59 2017 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 34D2312943E; Fri, 19 May 2017 01:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 GGX8qoZE6mX7; Fri, 19 May 2017 01:19:37 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30117.outbound.protection.outlook.com [40.107.3.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F788128768; Fri, 19 May 2017 01:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=X5PHhpcT6uhInZibK/hwAM47U7E/ajDSSeyvu5WY7AU=; b=r2wK6O/vglCtj2xKOkjHiQ9cvUXrB2zAWyFHhDc8oB70iLdVPz9ZRl+lzv1C8QElteEuGEoM7F1AIswvYwdknCsyQNpJ0DMbsB8OXqqCSIcnn+FFk/qjd+bKPvjLrllLlb/f4zTca4s14iD1K1HzQC6D87TEPcNFExO36BtU6Gs= Received: from VI1PR07CA0163.eurprd07.prod.outlook.com (10.166.77.11) by DB3PR07MB0586.eurprd07.prod.outlook.com (10.160.46.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Fri, 19 May 2017 08:13:55 +0000 Received: from VE1EUR03FT035.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e09::200) by VI1PR07CA0163.outlook.office365.com (2603:10a6:802:3e::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.5 via Frontend Transport; Fri, 19 May 2017 08:13:55 +0000 Authentication-Results: spf=pass (sender IP is 135.245.241.12) smtp.mailfrom=nokia.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=nokia.com; Received-SPF: Pass (protection.outlook.com: domain of nokia.com designates 135.245.241.12 as permitted sender) receiver=protection.outlook.com; client-ip=135.245.241.12; helo=fr711usmtp1-o.zeu.alcatel-lucent.com; Received: from fr711usmtp1-o.zeu.alcatel-lucent.com (135.245.241.12) by VE1EUR03FT035.mail.protection.outlook.com (10.152.18.110) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1075.5 via Frontend Transport; Fri, 19 May 2017 08:13:54 +0000 Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1-o.zeu.alcatel-lucent.com [135.239.2.135]) by fr711usmtp1-o.zeu.alcatel-lucent.com (GMO-o) with ESMTP id v4J8DiS1004594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 19 May 2017 08:13:46 GMT Received: from princess.be.alcatel-lucent.com (bt9870.be.alcatel-lucent.com [138.203.16.150]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id v4J8DLHH004562; Fri, 19 May 2017 08:13:27 GMT Received: from [138.203.14.165] (cplab165 [138.203.14.165]) by princess.be.alcatel-lucent.com (Postfix) with ESMTP id DE40C1045CB; Fri, 19 May 2017 10:13:20 +0200 (CEST) Message-ID: <591EA920.5000808@nokia.com> Date: Fri, 19 May 2017 10:13:20 +0200 From: Olivier Dornon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Russ Housley , CC: , , References: <149454198305.16624.16060763979327626869@ietfa.amsl.com> In-Reply-To: <149454198305.16624.16060763979327626869@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:135.245.241.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39850400002)(39410400002)(39860400002)(39450400003)(39400400002)(2980300002)(438002)(377454003)(43784003)(24454002)(51914003)(377424004)(9170700003)(50986999)(356003)(23676002)(230700001)(87266999)(76176999)(54356999)(305945005)(65816999)(2950100002)(64126003)(4001350100001)(86362001)(5660300001)(6706004)(33656002)(106466001)(478600001)(38730400002)(230783001)(36756003)(4326008)(50466002)(54906002)(53936002)(80316001)(53546009)(229853002)(83506001)(81166006)(6266002)(8676002)(189998001)(8936002)(6246003)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB0586; H:fr711usmtp1-o.zeu.alcatel-lucent.com; FPR:; SPF:Pass; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; VE1EUR03FT035; 1:hJEZSfEjkC+GxNeP+JssmiCz2cRJBM+7UljWJSEMggukTc3F+n14wNevo4a4cIoibLz4brEFE78dlvu8IGl+bMHfUqxfo3BzoRnBA7yqWeuxtuFTbpqPi9vZyPQWPGjoEH5fWw/KiU8vy+M7KXkHpafW7aUzJz6vgBeZugQFBLR1O1xG0fVvTslnVRY9/p40pEFDH7FlES4ZMEbAmeqwMds74pdDazuNLR0y0yyySsvfuhgePqCGhde8koHw10HAzjfEHJAdi+bAssU7uXZ6uGbtLkPt0qILeJO2tO0lKtQS1heJ1raIp9fDGMcjexfM6i+UC2wS38O6ED/QPi528CQ/X7ehjfGrW0gGf9JH3V02eBWgmUoHzXoVWoFbcYFuAbra4OpXJ2msAZTt4QzZKf5evoYkWu/QLE3aUcRW5nMYZsr5qWSEvnQoLzgUqB3ps6a/X7KzDy1ZjqfIEvJlM8lKtxrBeGhWGhkMuukhq/WV4i3cqaZOaNLHEdMISDjXeQuWtK5JSJYVIEyeoY/Ak6QUxsAWW97sarPr3SvI5wM= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 37f1e689-948f-4b5f-4d29-08d49e8efe21 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002)(2017030254075)(201703131423075)(201703031133081); SRVR:DB3PR07MB0586; X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB0586; 3:A36qeFhWKRP3Dr8nEJ/P0bBRqj9qfbbMp6G/e+2hn9eAA3RrTtuQy6YW9Tz8oZ4egE1QOhgk1f2DOuwJkzDplj86EMlkLa/zMliouAU8Jh7Avfr1Cn10TFViysSEphSF35hAp3l24xye9aXRJHcOabOYleH2jMF8ER6O5mSzH0rcDmIk13D2CkyWZ8wodrADnQJOYh5E+zXjbff+KTxBZQL5WoTgK/+pc4Of8FywTXiNfgh41Es7FQ2Qo62EA9ulJddQRJjQloYr8CTZY2N+4Crf576YRCl4kZ7e4+Q8+uNSz4tm13Aw6+5CQEiOOdhsxfV9c3MLld0vavzHnhAmQ9pAFjBUyV9KUduzYAoP/ZLw9VO3mZ5qvmQ4+k1HQvgIXolDQJCrqHBKyxWgP49BxIG7snLz8jCwaHEWWWq1pmWoZRXGQgnH6iuUAbcgX8hU1kxl4kjfSitqg10GWpfMReS4zJoQwGQGk1zGz7um6Wq6ReA8aUNu9weT91DTvvCs X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB0586; 25:YPKmqY9GzoyU1O2DdGdu606i3ViAo9zzVhgdehTrBxOOlVpL9ozcsN8Z/mESYnDfILe1gsvlyTFHSdK+kEmCU/6n9N3YNGsHmX83lr9XZXkQFXSba3PE9svdJ76MrTETjPppSKZ/Gcjf23S958cZMrmtEUF3/6QqzO3b2+aOFt6F3E6sPVZFTKpagZHyAka1bXW6OJkw+I8JOJKOUP/UBmXbbzpGl0l0brwrI7nltNioRKviW1xiREs4P2pfwlra18bkPwbLoDum76uq+U3herFZGL+brnvEw+XwwqTBcjsevP1sWOeHNsnvC1oqOfqBj3/EnaP98y9Uo3n/7twCl73VvIhfgbdj/P3F/FZEajDVrX1ergMduqQDwkriFFz3SXM+e8B1vSdBclF/JORF0b+m16gW9I9OFn9UbfHxjWx5jHGdamYcDajB9aEUNrQDGJ8xuLpUdQ7V6izqY6OfUm5L78WmvSuZ25djfN2gUJg=; 31:NTwH3kv/tMeXloLQICWudGXH7uR/ZDAFD4CB0ZjV03ZU5rYxiV4VcfL9Ld62AtAwZuj/sudHVMMtwb6p9hOKp7bK5lorZrThvU/TlQSAaBA2Je5GYLrTIiS/iXj+kRLQRObLH8krjwi3FBJx4CglAKPggtRuIukdEUzk+MQGBUH2b/9poJh+x2ilaRDpwrFVGowFui5bPQ6e5F9dIpyb1abEdEgM3NEA9HIlpe/An/h93dzzJZF6u74hFZBG88LNNWs+WuR97h8Q4+RAyhLZZA== X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB0586; 20:0yTRwQiMSz7StvRYs4PrcW/4g/z+ME33iDm/9gFQfPRXJVV3m3thtQFJOIa8Bjtew3hNXKXurFakt6BurEAtrIHP+l0P578HJTtDSQxnrhYtRZOlAwmm3piOoSUyyxH61G1q9Gq69HXHezjfaPEEpi+mC5/qeetYj3ZSK8U20Ie1k+rx+yqQnSOGSCYZxTuJ4f4y7+V/KtiO/Vz47J87ubokYt1wb+dFZTPuaz6sWc3gGgwfvdwmPCAa/LKI97ENcA/YWGVfA/iOSQX0+2qvPrY0bvDGg6Za2ACP5y/aO7DXr4/YEQ8FDT6ujpnNzamDMBZ1rGDWec/d8/ve3y/ZWdgLM3Cz2kgX4Hu9hjXSbUo23QVv7+i1vhnfuqvhVxm75gFjiX3dzXeBvrVAu8muORq81bS+I773nI+EG2TVuPVYtHGncrVvCpx0FDOYgoTnVcjx3uNboDW+RPKaHIjqqsmo0yK7sQR8aAwbXZtsRjt00leP+F1/HKGjqa4m2rbcUC3Sp/n6bG+Q+CrXA3oHCPX8MR2dp8xwyOpIGvEW43i4q/mHxP57/GJtcoEWAToAxqlwUu3l1Rv9UuintTAUimhpUK31RC7U1srgq/JJDUw= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700036)(100105000095)(100000701036)(100105300095)(100000702036)(100105100095)(6040450)(601004)(2401047)(5005006)(13018025)(8121501046)(13016025)(3002001)(100000703036)(100105400095)(10201501046)(93006095)(93004095)(6055026)(6041248)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(6072148)(100000704036)(100105200095)(100000705036)(100105500095); SRVR:DB3PR07MB0586; BCL:0; PCL:0; RULEID:(100000800036)(100110000095)(100000801036)(100110300095)(100000802036)(100110100095)(100000803036)(100110400095)(100000804036)(100110200095)(100000805036)(100110500095); SRVR:DB3PR07MB0586; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjNQUjA3TUIwNTg2OzQ6aVZBQTBiaEk1QUZ4c25ZdXorb3dHbUxpMFUr?= =?utf-8?B?a1FHamZlT0FrdjA1cVJYNWZiYm01VGZEdHNZSVp1TnNxenVTY2l3SStiNmRy?= =?utf-8?B?aHlzb1ordUFvN2FJdldONEJQNCt1M3dvQy9YUmVHM3MwMXpaMlVLd0J0a0lv?= =?utf-8?B?ZnFZU1ZKbVg4V1dkRld6VnM4WUQ0UnRnRDNZOWFlSGdlWDhYenI3dXpjTEZD?= =?utf-8?B?TkY2U0dYckNnaDZvb1BtYnIrRlhSTnlhTG1yY1dqS1RmYXlZM3c0UHB5N1hh?= =?utf-8?B?Z0tpN0NsRWNwNXd6emZDTDc1bkhVekJ6WjUydWdyMTk0aUhuVENWNEl1OEpE?= =?utf-8?B?RmpnMGMrZGdtQkFGRmFpaDVza0FDZHdTRUlqdFZQOEw5ZW5RS2Y4ZTlrZnVR?= =?utf-8?B?WmN6RVZwd0hsYzZoR2daQmloQnYyUWlQdmZjNGw1M0VvMi9QSm5GR21KWTdJ?= =?utf-8?B?ZjJXOHJyaTZIdTQ1bGlidFdTcnFqcmNUU2I0Ly9DdWRURld4SDE4cndaRnFL?= =?utf-8?B?T1BzSmRHdmtaTmU4RXlUcG43NnB4a21Vb1YycTJUakVsMzBUZ3JmWUw0djk0?= =?utf-8?B?MHFmSW8xS3hqTFRYV01Cdm9XYW0xTzREdDVaL2E5MkptVjJFbGVDaGhtV3l6?= =?utf-8?B?dHFDQmRmZHo2OCtVK2FiYXR1UGNLMldQbS93YjVQQkpETEFJZldnajB2N081?= =?utf-8?B?WUcrbzUrNHdsMnJVbk94SVBvTGtjR3Q4T3ZlZVp2Yyt5T3dweURXSUpJOHox?= =?utf-8?B?bkNPSjQ3cEhrQ29JZ3owVWVLZ1FZdUs1d0FIZ1E5M0tpdTh0U2RLeWtwVmlJ?= =?utf-8?B?SWR1bUJ0R1hxMEdLaDYyWXRDMkpGQ2lKcFpRcVdiMTFIMUhOcFJLNGxZbGM1?= =?utf-8?B?VUlJZE5KWDlGeS84SzJkRU9TRE8wSjdWVThFaE9BQnduODZ1RXZxdUxNZWl1?= =?utf-8?B?YndoWThoNE00bEJENStMQTZoVWZrN2ljVmNVMjgydHFsSnJRK0pvNEtscXFE?= =?utf-8?B?Z29iaWRVOUEzbE5aY3V6QVdVWFgycW1DUERYZWo1R0FJNUhVdC9YeUcxblk4?= =?utf-8?B?Ulo2RVRNQjVGeWVnalAyL25SODFsTkorY1k4czdUbzhxV1A3b1dhQkdIbnlr?= =?utf-8?B?SDE2OHZZdHpFMStoWnR4NitHTWVKWGUyUzB5SkdLakw0dlIzVEZMQWNkM3Zx?= =?utf-8?B?UHJLMlZYb2xqeStLU2lLSVRGaEZlS3JKa1lncmtyVmtNTmRsdUtGRzZDZzgw?= =?utf-8?B?SlZ6R0pGR3JKSXpyalFsa3JwSXpKYWtWbUw2REVJemtWTEJpdEtkbmo3Umk2?= =?utf-8?B?eFhXa25ZQ0E4MjJZWVNlSWF1Y0VTMnNuUWN4Q2orRzkycWJ3MldEN3NZb200?= =?utf-8?B?MFBzeU5uaDZQTVhzRFdmdExreEM5bDNqRFNqdVQ5OHJRNnJjOHVnWDVrQVN2?= =?utf-8?B?NWkycnBWbHRWVkcwcU5EOGZQMXdwTFZxdEMwdDhnZUVRTFJ3UjRVMURkUW12?= =?utf-8?B?TmE1VTlWaWVYK2xidHpoT000dlBDTVhJRHJvblFBdkd4WFovclFHaFhNaEhG?= =?utf-8?B?S21SVDkxM1hiVG43VGl0akZ1dFpNaks2cVNWSlFNTFRRcnpEVjdlcWYySXlZ?= =?utf-8?B?TnVhdHM0eTAyNjJndTc0Qkxnbjdsa2c2R0ZkOS8yc0lKSHROczNoMG9HUVY3?= =?utf-8?Q?XRCShn22j7XAw7PYA=3D?= X-Forefront-PRVS: 031257FE13 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjNQUjA3TUIwNTg2OzIzOlNINkt5WDFud29paVE0QVBrdnBLbldleFhV?= =?utf-8?B?eksxYlgxSUVlY1lTTWhpeGVXNXUwOTdiQXQ3OFRFUDU2L3E1dnk4K2ZhVDRt?= =?utf-8?B?QkErSk5DaktvYnVFYjRvYlJXbUpwMGZjZEVRY3p1SnZxQ0NOUENVT2swRjZC?= =?utf-8?B?RldVZXF6ZGZ1TDF6d3FCUE9YOXBCbCtZaURhZS96M0V5NEV2elBmMWNPd3FJ?= =?utf-8?B?cTNtdENCZjJOQTVQWFI4K2NaSDdBQ2crSjNvUTlxS1ZOVDRaTkZCTU5sSWNH?= =?utf-8?B?RVhIY2ZDbHF1WEJKdGdxM1Y4YWtramY4L0pnVStCSWY4YWdGdGltaVBncDVq?= =?utf-8?B?U0tvM0piV1c0b0VXWENEVUtUZTZSR3lnKy90MUpyemxFNkl5czNvK0NGZUxX?= =?utf-8?B?SHpFc2ZDRDc4c013M1lDMXhhcENrL21Iei9mZFhJc3hnT1loWko3cnN0MHV5?= =?utf-8?B?R2h1cmpLbHRua21tT0xRdVM4TTBFZWpBTVBUS3NBZDBKZGVWU2J3djh3Si9H?= =?utf-8?B?T3dmSVJLd25Fb2orckN1a01HSC9BNVFNZDgwZkFMRjMwcnRSTDBPSW5YN01X?= =?utf-8?B?cUlBSERUY3BBZDdoUzNydU5SSXNoMXhDOGhudzV4WGIrUzBDQVpsWHZRMWlD?= =?utf-8?B?MXN1VWdXMkNLQXh0NTF5c1dmTFRKdHdCSnhBbUluM3cxR0hQS0ppRTFxQUJX?= =?utf-8?B?elpnVEJiSWZkdVBhRXdiNUV3WHRTNkFPY3A4KzNJVnlzL2ZYSVNCb01PU3Rh?= =?utf-8?B?Q25pbXlJSVV2Rzl5K3kyajlUZytveFgwOFlZcEVnSE9RcVliY202QTlRZWtv?= =?utf-8?B?MWdSVEZYUTVWTE03ZkczR2VoU1F1b2FxbXhmaTFEd2NUeHBDOEtKSDRGZkRT?= =?utf-8?B?U3BwemJSUzQ2QktvNXhNUUs1enB6dzBTL2g0d3BFZFZRdVJRSklxYWErbGpC?= =?utf-8?B?cUhxajJCNGptUytESStWc3JKYXZMUzJRYzdJZ3lFNjJkNmxnUm4zNlZyR3NE?= =?utf-8?B?aEJpbTlRalQvV0xacnRqMEdQTTdwK2NHN2tmWDUyMXZJMDVnUDhNZ3ZmNDFi?= =?utf-8?B?R29VVlZ4Q3FIRy84Myttak4zbEtUMVlLQzFqeGliZzhuMWVNYXlrczJPUGtN?= =?utf-8?B?bWVaVzRPZEZHOTFLZG5jbFlaK0J6WmRWUjN5WlJEKzdnd0Nmcml6VGV1VUZk?= =?utf-8?B?dEs2Y0dyZWVjYmsrSURZOTMwcFQzd3NHbStmS0tVK2c2TEhuc2dweWhiRk5F?= =?utf-8?B?V3ZET2tEeVpFVmgzNDJkYWZuemVZUzNibFZXU1BJNE5FMmJ1bTZNa21qYUJ2?= =?utf-8?B?SHFjckhZVHE0TGVjNit2a1FwTElFa1R1ZUhDVzFhMUE4Z0lYbkJFem1XU1py?= =?utf-8?B?eHRubVE3QXhseFlPMS9jSVpKWlhzSmZRNjhIZHladU5PNE9PbExORlpsV3oz?= =?utf-8?B?K0hwTytZeERFaEdBdTlremRNcU9oRXZINkxqRWxJQ2ZHSTJQZFZITUtkMzc5?= =?utf-8?B?K1R2SzlmTzd6aHZXRHBLZlpsWnN1U1p0ekhUNWovWDdhOENRTXJyMUtQOW83?= =?utf-8?B?ekRCUXFJQ1lLYk9rTE81NXRUVHdMdkhEWGd3eWF4Q1p3dmIveTVwaEhiMkli?= =?utf-8?B?M1QxOTkzMGd5ZXBkTS8rQ25WVjM3aGxXV2VVK09UNm5tZk5pMHVzU0FpNk8w?= =?utf-8?Q?xiXX+20U7UbM7WLEVwPAcy9yac3pv3rIqNNZFfc?= X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB0586; 6:Gd4wrn7J0+roNLsyRqYR8N849QVwXUSaHZhyTfNSqSM574YNfRPw+WZeUg6cnJKS46QjG5FBxO8AK7YHDK38eo9RBfepuyKUYboYOZiQ5y71xI1cMYoRA8E6XnhXeLw/KZ3ruuRQkYS67ekld9iYeEjXfmwyT5WuLC8qLeehWZF15eBLOt3JNRyd1Fp9EUlbC4KtG9mev6vtEkzDgE9U0ZaDwylkAJJ+C0L5nM9XFnMlCK5s7fGbogFxBs7VfWbihVDZoOQCvcU/TfELu2x8jwej2L1/HNO81timgXyKzd2NBtuDOaidEQWEzK0Fe8qvyalMu1yQQYqK6Ox6p7jN5xaV4w5FTQlRGGBDqk02yVUPFJ4M3LnpraLjzX5jqz9aM/6jOi9Y8G+whBRezB925ftnEdFAYMoi1WMRrSGE63BipIDFW+Akx150dPP87YJZJoCEnjZhOgrbDQ/cxQqhWbf3Y49O2Q1qEY654S/KZwj0ZIBILVCibW/niqeXaOksP3ZyHJX8Jq5mNtIx0BPulvHkdKqbaU5a8c/D2MnU7LA= X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB0586; 5:HQx6u7Wru7j0QtoojU56L2/6b8YGOFPH2/pkMD0YNz75RLYNMktuXQSf7eVhq8go9pRoMxH5a1xm3WVg08MJK5jwXt4Hf7uaqmCBFyM5UKUaotoQN79KMAvwyjLaFNilgegyD4aHM2543a7LI8LTUW7b45iovBzUw3rqRs8qmlY3haESfU4dKLx7/3Rm+rsHSt7O0xxJJXVBlZdPT7KezwupczncdANJ9zENa0FIVWgT7tPAQMUmHt0hOoS/sSsT4uM1BStwxYsVLJrm8nZSHbKeS5+CwhW7U6nVipXbx0aeCDOVfQ6QAo5hmo0cfYWa6wCgYj6oGWMnxLIJUy53XgIInrkpev20KiVE7cQOb96ji3ND38ULSo39p/PFlSKjcw+Cq4mdEIufK+9LfC0qrUpFGil24gabq/5F+m1K+kkuYw3xHK+YXSp7ePuNn0J5JmGv8GbSJkHA5X/5f1TYMjr8UsA6eyk5EI/qldHzqMpVQO1bY+xdY5CYd4dH9aog; 24:ev4sjaTi5X+HgmkCDu//OmMrmPgBfLzjf9cgEgeFQTpbgyVw7Qf0lrzP0lpyDbi3EhP7vV91LtEv4LrxA52uAquC/BPPn8J57XpIkjBNDaY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB0586; 7:FAFe1IW72xfnp7d0zBd2oZYG5YaMZX4c2Xm+dwOQo/s4il3ukyieFw9xL30BmkCKKEV/ujddMvyuVnCbvDQqpWZ723SUQxhA3+5ARyOUwpqXBFNPOo/vyOVqK30La/JwsGX/GiyLEHdghM1/n4BxZO3es+oeawcbfw2Ivgb0HBQj9+rELLIR5LX+HyFrDOqPCb21pgYT1IUPHZuOk3FievJk1Ffu2eatUmPKTJ7g2cx25zMSuu0cklKPKvVhRJeB2hYQ94YnSSAakZnLEUeeeAoWU7LdhIxOyMWobXtaKR0PPC8ad3eqWnL9aEL4NbsD26YFidZ5x8z4SyembyGnEA== X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 May 2017 08:13:54.8628 (UTC) X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5d471751-9675-428d-917b-70f44f9630b0; Ip=[135.245.241.12]; Helo=[fr711usmtp1-o.zeu.alcatel-lucent.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB0586 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-pals-vpls-pim-snooping-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 08:19:40 -0000 Russ, Thanks for the review, I found all of your comments to be legitimate. I'll upload an updated version in the coming days. Thanks again, Olivier. On 05/12/2017 12:33 AM, Russ Housley wrote: > Reviewer: Russ Housley > Review result: Has Nits > > 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-pals-vpls-pim-snooping-05 > Reviewer: Russ Housley > Review Date: 2016-05-11 > IETF LC End Date: 2017-05-19 > IESG Telechat date: Unknown > > Summary: Has Nits > > I did not review the state machines in detail. I assume that others > that are far more familiar with PIM have done s detailed review of > them. > > > No Major Concerns > > > Minor Concerns > > Section 1 says: > > In that case, the PW related concept/procedures are not > applicable and that's all. > > I am not sure what you are trying to tell the implementer. > Please clarify. > > Section 1.3 includes: "rpt : Rendezvous Point", and Section 2.3 > includes: "Rendezvous Points (RP)". Please pick one and use it > throughout. > > In Section 2.2, please add a reference for the "split-horizon rule > for mesh PWs" or add a pointer to the section where it is discussed > further in this document. > > A better heading for Section 2.3.2 would be "IPv4 and IPv6". > > > Nits > > Please change the language that makes reference to other "draft", > such > as: "As stated in the VPLS Multicast Requirements draft ...". This > wording leads to changes by the RFC Editor, so it is better to use a > word like "document". > > Please change "J/P messages" to "Join/Prune messages" throughout the > document. > > The document uses both "learned" and "learnt". If there is a > difference > to the reader, it was too subtle for me to figure out. If they are > the > same, please pick one. > > In Section 1.1, rewording would add clarity: > > Depending on how the control messages are handled > (transparently flooded, selectively forwarded, aggregated), the > procedure/process may be called Snooping or proxy in different > contexts. > > I suggest: > > Depending on whether the control messages are > transparently flooded, selectively forwarded, or aggregated, the > processing may be called Snooping or proxy in different contexts. > > Section 2.3 says: > > However, the PE does not need to have any routing tables like as > required in PIM multicast routing. > > Please correct. I think you are trying to say: > > However, the PE does not need any routing tables like those > required in PIM multicast routing. > > Section 4.2.1 says: > > Note that the differences apply only to PIM Join/Prune messages. > PIM > Hello messages are snooped and flooded in all cases. > > Wouldn't it be more clear to consume the same number of lines and add > this information to the table. > > In Section 2.7 the document uses PIM-BIDIR and BIDIR-PIM, and they > seem > have the same meaning. Please pick one. > > From nobody Fri May 19 07:17:29 2017 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 1E01D127599; Fri, 19 May 2017 07:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.022 X-Spam-Level: X-Spam-Status: No, score=-5.022 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 xcwpNoj3WGy9; Fri, 19 May 2017 07:17:14 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76D761274D2; Fri, 19 May 2017 07:17:14 -0700 (PDT) Received: from mail08.wdf.sap.corp (mail01.sap.corp [194.39.131.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3wTqr84pCRz1KKD; Fri, 19 May 2017 16:17:12 +0200 (CEST) X-purgate-ID: 152705::1495203432-0000521C-43C7610E/0/0 X-purgate-size: 2767 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail08.wdf.sap.corp (Postfix) with ESMTP id 3wTqr842gjz2ycn; Fri, 19 May 2017 16:17:12 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 84D9A1A6A1; Fri, 19 May 2017 16:17:12 +0200 (CEST) In-Reply-To: <20170519043827.GL39245@kduck.kaduk.org> To: Benjamin Kaduk Date: Fri, 19 May 2017 16:17:12 +0200 (CEST) CC: iesg@ietf.org, secdir@ietf.org, draft-ietf-tls-ecdhe-psk-aead.all@ietf.org, tls@ietf.org, ietf@ietf.org Reply-To: mrex@sap.com X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20170519141712.84D9A1A6A1@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [secdir] [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 14:17:16 -0000 Benjamin Kaduk wrote: > > Some other editorial nits follow. > > In section 4, "these cipher suites MUST NOT be negotiated in TLS > versions prior to 1.2" should probably clarify that "these" cipher > suites are the new ones specified by this document. This reminds me of the specification goofs in several TLSv1.2-related documents about AEAD cipher suites which are responsible for the viability of the POODLE attack and other exploitable fallback hacks. It would be much preferable to avoid/fix those problems and facilitate the migration to and use of TLSv1.2 without failing TLS handshakes and band aids such as TLS_FALLBACK_SCSV Suggested improvement: The cipher suites defined in this document make use of the authenticated encryption with additional data (AEAD) defined in TLS 1.2 [RFC5246] and DTLS 1.2 [RFC6347]. Earlier versions of TLS do not have support for AEAD and consequently, these cipher suites MUST NOT - be negotiated in TLS versions prior to 1.2. Clients MUST NOT offer - these cipher suites if they do not offer TLS 1.2 or later. Servers, - which select an earlier version of TLS MUST NOT select one of these - cipher suites. A client MUST treat the selection of these cipher - suites in combination with a version of TLS that does not support - AEAD (i.e., TLS 1.1 or earlier) as an error and generate a fatal - 'illegal_parameter' TLS alert. + A client that offers + the cipher suites from this document in ClientHello.cipher_suites + in combination with (3,1) "TLSv1.0" or (3,2) "TLSv1.1" in + ClientHello.client_version MUST support TLSv1.2 and MUST accept + the server to negotiate TLSv1.2 for the current session. If the + client does not support TLSv1.2 or is not willing to negotiate TLSv1.2, + then this client MUST NOT offer any of these cipher suites with a + lower protocol version than (3,3) "TLSv1.2" in ClientHello.client_version. + A server receiving a ClientHello and a client_version indicating + (3,1) "TLSv1.0" or (3,2) "TLSv1.1" and any of the cipher suites from + this document in ClientHello.cipher_suites can safely assume that the + client supports TLSv1.2 and is willing to use it. The server MUST + NOT negotiate these cipher suites with TLS protocol versions earlier + than TLSv1.2. + + Not requiring clients to indicate their support for TLSv1.2 cipher + suites exclusively through ClientHello.client_hello improves the + interoperability in the installed base and use of TLSv1.2 AEAD + cipher suites without upsetting the installed base of version-intolerant + TLS servers, results in more TLS handshakes succeeding and obviates + fallback mechanisms. -Martin From nobody Fri May 19 07:40:10 2017 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 1DB3512871F; Fri, 19 May 2017 07:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=akamai.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 fwjujipgLvp8; Fri, 19 May 2017 07:40:03 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 151D6128616; Fri, 19 May 2017 07:40:02 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4JEREhR018311; Fri, 19 May 2017 15:40:00 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=nqaJ2c6f6nzUTZqHFNr++LfBDzLt1Zs6zhERmLXmwnM=; b=LSAimkt9tpudwA5d5o37bA9f3mwKATS8gWHvoVQG4FTxlYFVdEQbA4pMXNrUPVzQgS6d uxxFN3xzFw4TYbThRwtJK7uSUQ5qqdenPSutm0wp7PbjRHjiqG5Z47HJiqbp2m8G0Tgv J6kdGVpnCVm+1L7nNFYRz6Qq7KNetKVIz72O8lTs9Km/AckfMtIxEsZVLUdo0s9Fm4km QzpToK1goxFW+BMwGu+og5qjmmT91YvQq1oXuWKM57g+IEhFB8P+aj/hnV6urMCkR2DC oku68gECkN1USIWddNyGrDr+Kr0h2aO/sm7mDpEf+Fmpk+Uo0CbOjFP75TxVAKckHJdx eA== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2ahya7h2ju-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 May 2017 15:39:59 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v4JEPUWZ028856; Fri, 19 May 2017 10:39:59 -0400 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2adwfugd74-1; Fri, 19 May 2017 10:39:58 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 37EB01FC72; Fri, 19 May 2017 14:39:58 +0000 (GMT) To: Dave Garrett , tls@ietf.org Cc: draft-ietf-tls-ecdhe-psk-aead.all@ietf.org, secdir@ietf.org, ietf@ietf.org, Benjamin Kaduk , iesg@ietf.org References: <20170519043827.GL39245@kduck.kaduk.org> <201705190316.33316.davemgarrett@gmail.com> From: Benjamin Kaduk Message-ID: <010db57b-37a9-a543-d33c-cc0dd7a75fcf@akamai.com> Date: Fri, 19 May 2017 09:39:57 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <201705190316.33316.davemgarrett@gmail.com> Content-Type: multipart/alternative; boundary="------------4C99548D51EF38DA6C013C38" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-19_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705190092 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-19_09:, , signatures=0 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705190092 Archived-At: Subject: Re: [secdir] [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 14:40:09 -0000 This is a multi-part message in MIME format. --------------4C99548D51EF38DA6C013C38 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 05/19/2017 02:16 AM, Dave Garrett wrote: > On Friday, May 19, 2017 12:38:27 am Benjamin Kaduk wrote: >> In section 4, "these cipher suites MUST NOT be negotiated in TLS >> versions prior to 1.2" should probably clarify that "these" cipher >> suites are the new ones specified by this document. > Probably should be: "the cipher suites defined in this document > MUST NOT be negotiated for any version of TLS other than 1.2." > > The sentence mentioning TLS 1.3+ could be moved up to right after > and just say: "TLS version 1.3 and later negotiate these features in > a different manner." > > That's probably best, yes. The interaction between this document and TLS 1.3 is a little weird, and it's not entirely clear to me that this one needs to say much of anything about TLS 1.3, given that TLS 1.3 changes all the relevant messages and key hierarchy and such. -Ben --------------4C99548D51EF38DA6C013C38 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 05/19/2017 02:16 AM, Dave Garrett wrote:
On Friday, May 19, 2017 12:38:27 am Benjamin Kaduk wrote:

In section 4, "these cipher suites MUST NOT be negotiated in TLS
versions prior to 1.2" should probably clarify that "these" cipher
suites are the new ones specified by this document.

Probably should be: "the cipher suites defined in this document
MUST NOT be negotiated for any version of TLS other than 1.2."

The sentence mentioning TLS 1.3+ could be moved up to right after
and just say: "TLS version 1.3 and later negotiate these features in
a different manner."

That's probably best, yes.  The interaction between this document and TLS 1.3 is a little weird, and it's not entirely clear to me that this one needs to say much of anything about TLS 1.3, given that TLS 1.3 changes all the relevant messages and key hierarchy and such.

-Ben
--------------4C99548D51EF38DA6C013C38-- From nobody Fri May 19 08:56:00 2017 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 97E901294D8; Fri, 19 May 2017 08:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IePb0rm2HD51; Fri, 19 May 2017 08:55:38 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17B04129484; Fri, 19 May 2017 08:55:38 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id 99so3338356lfu.1; Fri, 19 May 2017 08:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=L+plUwKnFmIyg/bdkHFdC9zg9l6zsBn2dNJEtQP4xVY=; b=OSQ+ZqGcE/2bL57NRRhDieKYYUeBNWBBg2E6S6DFYfz88tYyXZEkHZNLBHMdqQ8Jc7 WbZiL65bMIesBTDfh+32SZxazGx3l6THtgI3uNT0GQGpttynE4cfwgpVC5j18jU3Vtxh Yrhz5Z6Umq4h0kNkWr3Rtooxjt7e8bjqlEMDlNEfCZY0QjzW0jGySVCR4ykay0ugoLbX yTj8GaHSJFPnwkuS3XwIWL8plxj3i8JFJSi+sSO1KhfiddfFJhPzZezqrrDtypW70aOh Gmg1SDciTUvf2ld2LAbollaPRQpsm9qDJ/lYnIh48fnSvOeC9tAqMrohd/K2aP5eZJTZ y7Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=L+plUwKnFmIyg/bdkHFdC9zg9l6zsBn2dNJEtQP4xVY=; b=HQ1nVYAOhArZTa/jmK0GNCKJvCNmOnAseIYcnZAggUSjC4txGl13VOhuqgejQx3i08 PKQ2qZHtKpRfotI+LjeSbvY6YNDicBYm/dapVR8C6uhGWbV/ZkTQUd1rpd0iJRh4xVO6 ftq07ULtpgPPVu4b9Hsmy3Dej6R3br0g/PMlLMHCcVEpYjtDz1WWGKayiq7RKPf1HyG/ vcFM0AHs7vA+qLxE41q30GWUUhgnagMiuQlvdEZ5qdAIi5sDXBGM0Nez/2tDWxCgxtS6 vpUO5CMfZOFIzhHS9ifsEuDj7oevfJZRpjX/cpPwvbQ6vEZNmcD5fAfy2RB6/CxC7KVq be8g== X-Gm-Message-State: AODbwcCVtqG8TQp6ZCQqObtWF6Meu7zePAcPQd6ysO6TZ4mVRw8uSK+6 7xBGmHTguF4X/SLdnJtv6d7b7JzVW872 X-Received: by 10.25.228.197 with SMTP id x66mr2272178lfi.145.1495209336235; Fri, 19 May 2017 08:55:36 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.0.14 with HTTP; Fri, 19 May 2017 08:55:35 -0700 (PDT) In-Reply-To: <20170519043827.GL39245@kduck.kaduk.org> References: <20170519043827.GL39245@kduck.kaduk.org> From: Daniel Migault Date: Fri, 19 May 2017 11:55:35 -0400 X-Google-Sender-Auth: mkl0vhJtSKd0EsKUTBHbL0a9Xck Message-ID: To: Benjamin Kaduk Cc: The IESG , secdir@ietf.org, draft-ietf-tls-ecdhe-psk-aead.all@ietf.org, tls , "ietf@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0e7d8859eec0054fe28dcd" Archived-At: Subject: Re: [secdir] [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 15:55:42 -0000 --94eb2c0e7d8859eec0054fe28dcd Content-Type: text/plain; charset="UTF-8" Hi Benjamin, Thank you for the review. Please find my comments inline and let me know if you agree with the proposed text. I believe the only point not addressed concerns the addition of CCM-256 which has been remove after discussion during the WGLC. Thanks you for the review, Yours, Daniel On Fri, May 19, 2017 at 12:38 AM, Benjamin Kaduk wrote: > Hi all, > > 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 with nits. > > Essentially, we are filling in a gap in the TLS (< 1.3) ciphersuite > space, thought of as a cross product of key exchange and > cipher+mac/AEAD -- we have some of the combinations (PSK with ECDHE > but no AES-[GC]CM, PSK with AES-GCM but only non-EC DH, etc.) but > not quite this one. > > That said, it seems a little silly to only partially fill the gap > (by omitting the AES_256_CCM* cipher suites), even though there is > not currently demand for them. > > MGLT: TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 and TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 were mentioned in the 01 and removed after the WGLC. [0] The issue was whether or not introducing new ciphers not supported by TLS1.3. In 01, we though of adding the code point for TLS1.2 and then specify that TLS1.3 was only implementing a **subset** of the cipher suites proposed.In case of needs these could still be supported later by TLS1.3. The consensus seems to not introduce ciphers that would not be handled by TLS1.3. If the WG decides otherwise, these could still be added. [0] https://mailarchive.ietf.org/arch/msg/tls/M442CwmUMxrYJR8FjCh3h-a69o4/?qid=6e4713be1d71bae6718c6e6e6c4b8007 > This document is just assembling pieces that were already specified > elsewhere, so it need not contain much detail itself, which is fine. > That said, I think section 3 should probably state explicitly which > pieces it uses, instead of a vague reference of being "based on RFC > 4279". So, "The ServerKeyExchange and ClientKeyExchange messages > from RFC 5489 for ECDHE_PSK are used, and the premaster secret is > computed in the same manner as for ECDHE_PSK key exchange in RFC > 5489." (I am not sure why RFC 4279 is cited in the current text; it > does not cover ECDHE_PSK.) > MGLT: I agree we coudl be more explicit, here are the changes I propose. I believe it address your purpose. OLD: Messages and pre-master secret construction in this document are based on [RFC4279 ]. NEW: Messages and pre-master secret construction in this document are defined in [RFC5489]. The ServerKeyExchange and ClientKeyExchange messages and premaster secret is computed as for the ECDHE_PSK key exchange. > The premaster_secret structure so used basically ends up putting the > ECDH output first followed by the static PSK; with the pre-TLS 1.2 > PRF, that would give the ECDH shared secret to md5 and the PSK to > sha1, which is perhaps another reason to not use these with pre-1.2 > worth mentioning (in addition to the AEAD availability). > MGLT: I believe the following text address your concern, however I am wondering if we are not going beyond the scope of expected considerations. In addition, it is worth noting that TLS1.0 and TL1.2 splits the premaster in two parts. The PRF results of mixing the two pseudorandom streams with distinct hash functions (MD5 and SHA-1) by exclusive-ORing them together. In the case of ECDHE_PSK authentication, the PSK and pre-master are treated by distinct hash function with distinct properties. This may introduce vulnerabilities over the expected security provided by the constructed pre-master. As such TLS1.0 and TLS1.1 SHOULD NOT be used with ECDHE_PSK. > The security considerations largely refer to those of the other > documents providing the pieces that are combined together here; > those referenced security considerations sections are more than > adequate here, as this document itself does not really do anything > particularly novel. That said, if we are going to reiterate the > entropy requirement for PSKs inline, we probably ought to also > reiterate the nonce-reuse considerations for GCM and CCM. The > relevant constructions help, but there are still ways to mess up and > reuse a nonce when doing crypto in parallel, if I remember the > GCM/TLS document's security considerations correctly. > MGLT: I believe the following text address your comments. GCM or CCM encryption - even of different clear text - re-using a nonce with a same key undermines the security of GCM and CCM. As a result, GCM and CCM MUST only be used with system guaranteeing nonce uniqueness . > > Some other editorial nits follow. > > I see we're already discussing "perfect forward secrecy" vs. > "forward secrecy"; my preference is for just "forward secrecy" (and > I may have been one of the more active voices in causing TLS 1.3 to > switch), but in the grand scheme of things it doesn't really matter. > > MGLT: perfect forward secrecy has been removed and replaced by forward secrecy. > In section 2, the RFC 7525 reference that "AEAD algorithms [...] are > strongly recommended" is scoped to just (D)TLS, so the text here > should probably also list that qualification. > MGLT: I believe the following text address your concern: OLD text: AEAD algorithms that combine encryption and integrity protection are strongly recommended for and non-AEAD algorithms are forbidden to use in TLS 1.3 . NEW text: AEAD algorithms that combine encryption and integrity protection are strongly recommended for (D)TLS and non-AEAD algorithms are forbidden to use in TLS 1.3 . > In section 4, "... make use of the authenticated encryption with > additional data (AEAD) defined in TLS 1.2" seems to make AEAD into > something of a unique object, as opposed to a class of things with > multiple possible instantiations. I would consider something like > "... (AEAD) concept". > > In section 4, "these cipher suites MUST NOT be negotiated in TLS > versions prior to 1.2" should probably clarify that "these" cipher > suites are the new ones specified by this document. > > MGLT: I believe the following text address your comment: OLD: these cipher suites MUST NOT be negotiated in TLS versions prior to 1.2. NEW: the cipher suites defined in this document MUST NOT be negotiated in TLS versions prior to 1.2. OLD: Clients MUST NOT offer these cipher suites NEW: Clients MUST NOT offer these cipher suites defined in this document > s/Servers,\nwhich/Servers\nthat/ > > MGLT: Done > Does the last paragraph of section 5 want a note "RFC Editor please > remove this paragraph"? > > MGLT: Done > Section 6, third paragraph, s/by using short PSK/by using a short > PSK/. Also, s/by a human and thus/by a human which thus/, maybe? > > MGLT: Probably ;-) done. thanks. > Last paragraph page 4, comma after "i.e.". > MGLT: Added > > > -Ben > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c0e7d8859eec0054fe28dcd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Benjamin,

Thank you f= or the review. Please find my comments inline and let me know if you agree = with the proposed text. I believe the only point not addressed concerns the= addition of CCM-256 which has been remove after discussion during the WGLC= .

Thanks you for the review,

Yours,
Da= niel

On Fri, May 19, 2017 at 12:38 AM, Benjamin Kaduk &l= t;kaduk@mit.edu><= /span> wrote:
Hi all,<= br>
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 these comments just like any other last call comments.

This document is ready with nits.

Essentially, we are filling in a gap in the TLS (< 1.3) ciphersuite
space, thought of as a cross product of key exchange and
cipher+mac/AEAD -- we have some of the combinations (PSK with ECDHE
but no AES-[GC]CM, PSK with AES-GCM but only non-EC DH, etc.) but
not quite this one.

That said, it seems a little silly to only partially fill the gap
(by omitting the AES_256_CCM* cipher suites), even though there is
not currently demand for them.

MGLT: TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 and TL= S_ECDHE_PSK_WITH_AES_256_CCM_SHA384=C2=A0 were mentioned in the 01 and remo= ved after=C2=A0 the WGLC. [0] The issue was whether or not introducing new = ciphers not supported by TLS1.3. In 01, we though of adding the code point = for TLS1.2 and then specify that TLS1.3 was only implementing a **subset** = of the cipher suites proposed.In case of needs these could still be support= ed later by TLS1.3. The consensus seems to not introduce ciphers that would= not be handled by TLS1.3. If the WG decides otherwise, these could still b= e added.=C2=A0 =C2=A0

[0] https://mailarchive.ietf.org/arch/msg/tls/M442CwmUMxrYJR8FjCh3h-a69o4= /?qid=3D6e4713be1d71bae6718c6e6e6c4b8007


=C2=A0
This document is just assembling pieces that were already specified
elsewhere, so it need not contain much detail itself, which is fine.
That said, I think section 3 should probably state explicitly which
pieces it uses, instead of a vague reference of being "based on RFC 4279".=C2=A0 So, "The ServerKeyExchange and ClientKeyExchange mes= sages
from RFC 5489 for ECDHE_PSK are used, and the premaster secret is
computed in the same manner as for ECDHE_PSK key exchange in RFC
5489."=C2=A0 (I am not sure why RFC 4279 is cited in the current text;= it
does not cover ECDHE_PSK.)

MGLT: I agre= e we coudl be more explicit, here are the changes I propose. I believe it a= ddress your purpose.

OLD:
Messages and pre-master secret construction in this 
document are base=
d on [RFC4279=
].

NEW:
Messages an=
d pre-master secret construction in this 
document are defined in [RFC54=
89]. The ServerKeyExchange
and ClientKeyExchange messages and premaster =
secret is 
computed as for  the ECDHE_PSK key exchange. =C2=A0
=

The premaster_secret structure so used basically ends up putting the
ECDH output first followed by the static PSK; with the pre-TLS 1.2
PRF, that would give the ECDH shared secret to md5 and the PSK to
sha1, which is perhaps another reason to not use these with pre-1.2
worth mentioning (in addition to the AEAD availability).

MGLT: I believe the following text address your concern, = however I am wondering if we are not going beyond the scope of expected con= siderations.=C2=A0

In addition, it is worth noting that = TLS1.0 <xref target=3D"RFC2246"/> and TL1.2 <xref target= =3D"RFC4346"/> splits the premaster in two parts. The PRF resu= lts of mixing the two pseudorandom streams with distinct hash functions (MD= 5 and SHA-1) by exclusive-ORing them together. In the case of ECDHE_PSK aut= hentication, the PSK and pre-master are treated by distinct hash function w= ith distinct properties. This may introduce vulnerabilities over the expect= ed security provided by the constructed pre-master. As such TLS1.0 and TLS1= .1 SHOULD NOT be used with ECDHE_PSK.
=C2=A0
The security considerations largely refer to those of the other
documents providing the pieces that are combined together here;
those referenced security considerations sections are more than
adequate here, as this document itself does not really do anything
particularly novel.=C2=A0 That said, if we are going to reiterate the
entropy requirement for PSKs inline, we probably ought to also
reiterate the nonce-reuse considerations for GCM and CCM.=C2=A0 The
relevant constructions help, but there are still ways to mess up and
reuse a nonce when doing crypto in parallel, if I remember the
GCM/TLS document's security considerations correctly.
<= div>
MGLT: I believe the following text address your comments.

= =C2=A0<t>GCM or CCM encryption - even of different clear text - re-us= ing a
nonce with a same key undermines the security of GCM and CCM. As = a
result, GCM and CCM MUST only be used with system guaranteeing nonceuniqueness <xref target=3D"RFC5116"/>.</t>

<= /div>


Some other editorial nits follow.

I see we're already discussing "perfect forward secrecy" vs.<= br> "forward secrecy"; my preference is for just "forward secrec= y" (and
I may have been one of the more active voices in causing TLS 1.3 to
switch), but in the grand scheme of things it doesn't really matter.
MGLT: perfect forward secrecy has been removed and re= placed by forward secrecy.
=C2=A0
In section 2, the RFC 7525 reference that "AEAD algorithms [...] are strongly recommended" is scoped to just (D)TLS, so the text here
should probably also list that qualification.
=C2=A0
MGLT: I believe the following text address your concern:
OLD text:
<t>AEAD algorithms that combine encryption= and integrity protection are
strongly recommended for <xref target= =3D"RFC7525" /> and non-AEAD algorithms
are forbidden to us= e in TLS 1.3 <xref target=3D"I-D.ietf-tls-tls13"/>.
NEW text:
<t>AEAD algorithms that combine encryption a= nd integrity protection are
strongly recommended for (D)TLS <xref tar= get=3D"RFC7525" /> and non-AEAD algorithms
are forbidden to= use in TLS 1.3 <xref target=3D"I-D.ietf-tls-tls13"/>.
=
In section 4, "... make use of the authenticated encryption with
additional data (AEAD) defined in TLS 1.2" seems to make AEAD into
something of a unique object, as opposed to a class of things with
multiple possible instantiations.=C2=A0 I would consider something like
"... (AEAD) concept".

In section 4, "these cipher suites MUST NOT be negotiated in TLS
versions prior to 1.2" should probably clarify that "these" = cipher
suites are the new ones specified by this document.

MGLT: I believe the following text address your comme= nt:

OLD:
these cipher suites MUST NOT be negotiated in= TLS=C2=A0 versions prior to 1.2.

NEW:
the cipher suit= es defined in this document MUST NOT be negotiated in TLS
versions prio= r to 1.2.

=C2=A0OLD:
Clients MUST NOT offer these ciph= er suites

NEW:
Clients MUST NOT offer these cipher s= uites defined in this document

=C2=A0
s/Servers,\nwhich/Servers\nthat/


MGLT: Done
=C2=A0
Does the last paragraph of section 5 want a note "RFC Editor please remove this paragraph"?

MGLT: Done
=C2=A0
Section 6, third paragraph, s/by using short PSK/by using a short
PSK/.=C2=A0 Also, s/by a human and thus/by a human which thus/, maybe?

MGLT: Probably ;-) done. thanks.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> Last paragraph page 4, comma after "i.e.".
<= br>
MGLT: Added


-Ben

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--94eb2c0e7d8859eec0054fe28dcd-- From nobody Fri May 19 09:07:42 2017 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 27D681294EC; Fri, 19 May 2017 09:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCfPhlC85vcB; Fri, 19 May 2017 09:07:39 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB561294A4; Fri, 19 May 2017 09:07:39 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id h4so3511215lfj.3; Fri, 19 May 2017 09:07:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=uwHBmfuU4afjEOllwHYg5B3VzGqkeebVf6XvE+EY0gg=; b=PO7WgfJRI5Y2h5a5x+4Z48haRK7enlYhKEX82+icO7n1mXyV5LjnAMlkEKk8fxjSWz 0+jvf7sEfKtlfVuiiTLACjUsvyfQkiXTmfyx9+i+qErhswNaQ3CSyeA1YdCJvI4GU0Zn wasg2WwNIH6Mzx+NFCyywmA/GqQYfgeTmyxyt6E0l+zTHS8W3l+5XXEVLqvL4c535EOJ roVDEwTB/rrT+TjPv6DhSKU5JPNlvdHzK2GHmBa/MLwo7q43n2rQSEf5Ld4TT2Lw5TOt uLsg9L4mTEyeKkZVHW3xCYLxhNToAHy6IsuRNcDProQyaqvlaPHfbyHCzR70vDCTJ4gi C/QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=uwHBmfuU4afjEOllwHYg5B3VzGqkeebVf6XvE+EY0gg=; b=jcE9OllRpEQvmDUK1qHMHPaF4cRWxb6b7K8a6D7knpGDQoYa4hb9bSn7PP2qkPKZhy kPmeVXUU6/krEFWdSXaKRe8AoDZim750iPbRXHyViaesNYSbAHn2rlAYxwQOmdWfGzaN +/KAliemmMBtDD2ZlUu5mJMu0BZM5o8OAejs73kzwic248aUAOGJiBSC5e4mq/JHaLjX UsUM3xy0Vz+3g54RSqIsUy+NobKhahCr9U9CkDo7FFjVzVRxhxs9w9fK8tNwXVwONqCw /Ak15+sViJxy7TzRfa1jNKytQ2mq2fyBMHQXKotof7YHkAlGw4bFGOB8YgxFeifX8tZh CqGQ== X-Gm-Message-State: AODbwcAQaJZNqMAwWyonSD+mhrlgw3B0A/VEGis8np0z/FzsIfn/ut7C LZhl8xdQk0a+isiKe/At5gS06a1JVw== X-Received: by 10.25.193.145 with SMTP id r139mr1531754lff.111.1495210057237; Fri, 19 May 2017 09:07:37 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.0.14 with HTTP; Fri, 19 May 2017 09:07:36 -0700 (PDT) In-Reply-To: <010db57b-37a9-a543-d33c-cc0dd7a75fcf@akamai.com> References: <20170519043827.GL39245@kduck.kaduk.org> <201705190316.33316.davemgarrett@gmail.com> <010db57b-37a9-a543-d33c-cc0dd7a75fcf@akamai.com> From: Daniel Migault Date: Fri, 19 May 2017 12:07:36 -0400 X-Google-Sender-Auth: 9qEQEUqd_BBy51at4x7pj0L4Fqc Message-ID: To: Benjamin Kaduk Cc: Dave Garrett , tls , The IESG , Benjamin Kaduk , draft-ietf-tls-ecdhe-psk-aead.all@ietf.org, "ietf@ietf.org" , secdir@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1a0878538d39054fe2b8a6" Archived-At: Subject: Re: [secdir] [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 16:07:41 -0000 --94eb2c1a0878538d39054fe2b8a6 Content-Type: text/plain; charset="UTF-8" Hi Benjamin and Dave, Thanks for the clarification. Considering also Roman' s and Ben' s comments the section is built as follow. 1) Limit cipher suites to TLS1.2, 2) explain how TLS1.3 and higher version negotiate them 3) bring all explanation foe the previous versions. Yours, Daniel The text is as follows: The cipher suites defined in this document MUST NOT be negotiated for any version of (D)TLS other than TLS1.2. TLS version 1.3 and later negotiate these features in a different manner. Unlike TLS1.2, TLS1.3 separates authentication and cipher suite negotiation Section 1.2. TLS1.3 supports PSK with ECDHE key exchange and the cipher suites TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are part of the specification. As a result, TLS 1.3 and higher versions, negotiate and support these cipher suites in a different way. The cipher suites defined in this document make use of the authenticated encryption with additional data (AEAD) defined in TLS 1.2 and DTLS 1.2 . Earlier versions of TLS do not have support for AEAD and consequently, the cipher suites defined in this document MUST NOT be negotiated in TLS versions prior to 1.2. In addition, it is worth noting that TLS1.0 and TL1.2 splits teh pre-master in two parts. The PRF results of mixing the two pseudorandom streams with distinct hash functions (MD5 and SHA-1) by exclusive-ORing them together. In the case of ECDHE_PSK authentication, the PSK and pre-master are treated by distinct hash function with distinct properties. This may introduce vulnerabilities over the expected security provided by the constructed pre-master. As such TLS1.0 and TLS1.1 SHOULD NOT be used with ECDHE_PSK. Clients MUST NOT offer these cipher suites defined in this document if they do not offer TLS 1.2 or later. Servers that select an earlier version of TLS MUST NOT select one of these cipher suites. A client MUST treat the selection of these cipher suites in combination with a version of TLS that does not support AEAD (i.e., TLS 1.1 or earlier) as an error and generate a fatal 'illegal_parameter' TLS alert. On Fri, May 19, 2017 at 10:39 AM, Benjamin Kaduk wrote: > On 05/19/2017 02:16 AM, Dave Garrett wrote: > > On Friday, May 19, 2017 12:38:27 am Benjamin Kaduk wrote: > > In section 4, "these cipher suites MUST NOT be negotiated in TLS > versions prior to 1.2" should probably clarify that "these" cipher > suites are the new ones specified by this document. > > Probably should be: "the cipher suites defined in this document > MUST NOT be negotiated for any version of TLS other than 1.2." > > The sentence mentioning TLS 1.3+ could be moved up to right after > and just say: "TLS version 1.3 and later negotiate these features in > a different manner." > > > > > That's probably best, yes. The interaction between this document and TLS > 1.3 is a little weird, and it's not entirely clear to me that this one > needs to say much of anything about TLS 1.3, given that TLS 1.3 changes all > the relevant messages and key hierarchy and such. > > -Ben > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c1a0878538d39054fe2b8a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Benjamin and Dave,

Thanks for t= he clarification. Considering also Roman' s and Ben' s comments the= section is built as follow. 1) Limit cipher suites to TLS1.2, 2) explain h= ow TLS1.3 and higher version negotiate them 3) bring all explanation foe th= e previous versions.

Yours,
Daniel

=
The text is as follows:

<t> The cipher suites defined in= this document MUST NOT be negotiated
for any version of (D)TLS other th= an TLS1.2.</t>

<t> TLS version 1.3 and later negotiate t= hese features in a different
manner. Unlike TLS1.2, TLS1.3 separates aut= hentication and cipher suite
negotiation <xref target=3D"I-D.iet= f-tls-tls13"/> Section 1.2. TLS1.3
supports PSK with ECDHE key e= xchange and the cipher suites
TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SH= A384, TLS_AES_128_CCM_8_SHA256
and=C2=A0 TLS_AES_128_CCM_SHA256 are par= t of the specification. As a result,
TLS 1.3 and higher versions, negoti= ate and support these cipher suites
in a different way. </t>
<t>The cipher suites defined in this document make use of the
au= thenticated encryption with additional data (AEAD) defined in TLS 1.2
&l= t;xref target=3D"RFC5246"/> and DTLS 1.2 <xref target=3D&qu= ot;RFC6347" />.
Earlier versions of TLS do not have support for = AEAD and consequently,
the cipher suites defined in this document MUST N= OT be negotiated in TLS
versions prior to 1.2.=C2=A0 In addition, it is = worth noting that TLS1.0
<xref target=3D"RFC2246"/> and = TL1.2 <xref target=3D"RFC4346"/> splits teh
pre-master i= n two parts. The PRF results of mixing the two pseudorandom
streams with= distinct hash functions (MD5 and SHA-1) by exclusive-ORing
them togethe= r. In the case of ECDHE_PSK authentication, the PSK and
pre-master are t= reated by distinct hash function with distinct
properties. This may intr= oduce vulnerabilities over the expected
security provided by the constru= cted pre-master. As such TLS1.0 and
TLS1.1 SHOULD NOT be used with ECDHE= _PSK.=C2=A0 Clients MUST NOT offer these
cipher suites defined in this d= ocument if they do not offer TLS 1.2 or
later. Servers that select an ea= rlier version of TLS MUST NOT select one
of these cipher suites. A clien= t MUST treat the selection of these
cipher suites in combination with a = version of TLS that does not support
AEAD (i.e., TLS 1.1 or earlier) as = an error and generate a fatal
'illegal_parameter' TLS alert.<= ;/t>

=C2=A0

On Fri, May 19, 2017 at 10:39 AM, Benjamin Kadu= k <bkaduk@akamai.com> wrote:
=20 =20 =20
On 05/19/2017 02:16 AM, Dave Garrett wrote:
On Friday, May 19, 2017 12:38:27 am Benjamin Kaduk wrote:

In section 4, "these cipher suites MUST NOT be negotiated=
 in TLS
versions prior to 1.2" should probably clarify that "these" =
cipher
suites are the new ones specified by this document.

Probably should be: "the cipher suites defined in this docu=
ment
MUST NOT be negotiated for any version of TLS other than 1.2."

The sentence mentioning TLS 1.3+ could be moved up to right after
and just say: "TLS version 1.3 and later negotiate these features in
a different manner."

That's probably best, yes.=C2=A0 The interaction between this docum= ent and TLS 1.3 is a little weird, and it's not entirely clear to me that this one needs to say much of anything about TLS 1.3, given that TLS 1.3 changes all the relevant messages and key hierarchy and such.

-Ben

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--94eb2c1a0878538d39054fe2b8a6-- From nobody Fri May 19 09:26:30 2017 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 BCFF712955F; Fri, 19 May 2017 09:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5W5i34hUVr6; Fri, 19 May 2017 09:25:54 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 A8C441294F3; Fri, 19 May 2017 09:25:53 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id y126so3711035lfc.2; Fri, 19 May 2017 09:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=bE8IPZygLAJ0pGuNryzThjkvrgswGRp2YcsgJ+gq/Rw=; b=iBczSge/YhesrK4a3UJvGU4UHTlmhhzglARpMLvX/+TDV7JuP4sGmK/8hvdcpRMgc7 OTOvCJ/oM5v+JdmmFxGKoL/5ImGrIaC3iKJ2+8QjBQBayrfz1i7FVvrNo0+laugh0ZrZ kOSi8txkxz7IbpMe2RFhaWhtS1nsQ4Er5kDMkCIDLfRiwE/xIEWjaAg2bZoQT3MvNlnb yGondVLxCcJ7ZJqBqYzC9HtzCXf8UA+WGcskSH9cmQ4En9dmJPmBTjCBIg3GiHSxpreM ucJcnwm7smgOIDNwPUtrNW5aJgO0DFn+pBskjGQvAVUBo8Eya9LHTpjKCW71jP78ng0D bBLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=bE8IPZygLAJ0pGuNryzThjkvrgswGRp2YcsgJ+gq/Rw=; b=m/n42gDzlb3okWAzofhnc4nXIMYgO6GB3IxUWBri8M+tnqJRSdTpPvrDsAsPBSeeul ger5hE2H++WEHPhmLjMdJzV4i1EW36a00eDCiHHdoYH/GLYDGfx6wf5y4kPG6GHwc2/o XnGa9GvJb/biZfho8YSVe2MeciDziiQuBs3Fhwo+XuatF/8c0OHYNJcG7eFC0oI1XyqS DLt4KGx1mx1blGiCixHN5MH+EdSpWdDtKtDCmeKGA5Rri8PcGqIjMvBP0u3zjXwMBWwu jX0qjzHMFvGmkhTCtbbZ+cGe1IqQSDfs7dBHL8VdT+Iyc/lU1NbpFI/jh7sdqOC3dalb pcTA== X-Gm-Message-State: AODbwcCBSP/jpEaaINwznvPwwiGzuoEh5N7VbglxFiplsfTfKGxgUxcO 1ZedHvywuQxWKsRa8SP2+Zmy/gpDdA== X-Received: by 10.25.229.69 with SMTP id c66mr2783915lfh.102.1495211151786; Fri, 19 May 2017 09:25:51 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.0.14 with HTTP; Fri, 19 May 2017 09:25:51 -0700 (PDT) In-Reply-To: <20170519141712.84D9A1A6A1@ld9781.wdf.sap.corp> References: <20170519043827.GL39245@kduck.kaduk.org> <20170519141712.84D9A1A6A1@ld9781.wdf.sap.corp> From: Daniel Migault Date: Fri, 19 May 2017 12:25:51 -0400 X-Google-Sender-Auth: WPgY13FdGIvJnTffCNRBub0cj_Q Message-ID: To: mrex@sap.com Cc: Benjamin Kaduk , tls , draft-ietf-tls-ecdhe-psk-aead.all@ietf.org, "ietf@ietf.org" , The IESG , secdir@ietf.org Content-Type: multipart/alternative; boundary="001a113c0cb2910d10054fe2f9e6" Archived-At: Subject: Re: [secdir] [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 16:25:57 -0000 --001a113c0cb2910d10054fe2f9e6 Content-Type: text/plain; charset="UTF-8" Hi Martin, Thank you for the proposed text. It was very clear and I took it entirely, just changing s/TLSv1/TLS 1/. Yours, Daniel The current text is as follows:
The cipher suites defined in this document MUST NOT be negotiated for any version of (D)TLS other than TLS 1.2. TLS version 1.3 and later negotiate these features in a different manner. Unlike TLS 1.2, TLS 1.3 separates authentication and cipher suite negotiation Section 1.2. TLS 1.3 supports PSK with ECDHE key exchange and the cipher suites TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are part of the specification. As a result, TLS 1.3 and higher versions, negotiate and support these cipher suites in a different way. The cipher suites defined in this document make use of the authenticated encryption with additional data (AEAD) defined in TLS 1.2 and DTLS 1.2 . Earlier versions of TLS do not have support for AEAD and consequently, the cipher suites defined in this document MUST NOT be negotiated in TLS versions prior to 1.2. In addition, it is worth noting that TLS 1.0 and TL1.2 splits the pre-master in two parts. The PRF results of mixing the two pseudorandom streams with distinct hash functions (MD5 and SHA-1) by exclusive-ORing them together. In the case of ECDHE_PSK authentication, the PSK and pre-master are treated by distinct hash function with distinct properties. This may introduce vulnerabilities over the expected security provided by the constructed pre-master. As such TLS 1.0 and TLS 1.1 SHOULD NOT be used with ECDHE_PSK. A client that offers the cipher suites from this document in ClientHello.cipher_suites in combination with (3,1) "TLS 1.0" or (3,2) "TLS 1.1" in ClientHello.client_version MUST support TLS 1.2 and MUST accept the server to negotiate TLS 1.2 for the current session. If the client does not support TLS 1.2 or is not willing to negotiate TLS 1.2, then this client MUST NOT offer any of these cipher suites with a lower protocol version than (3,3) "TLS 1.2" in ClientHello.client_version. A server receiving a ClientHello and a client_version indicating (3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from this document in ClientHello.cipher_suites can safely assume that the client supports TLS 1.2 and is willing to use it. The server MUST NOT negotiate these cipher suites with TLS protocol versions earlier than TLS 1.2. Not requiring clients to indicate their support for TLS 1.2 cipher suites exclusively through ClientHello.client_hello improves the interoperability in the installed base and use of TLS 1.2 AEAD cipher suites without upsetting the installed base of version-intolerant TLS servers, results in more TLS handshakes succeeding and obviates fallback mechanisms. On Fri, May 19, 2017 at 10:17 AM, Martin Rex wrote: > Benjamin Kaduk wrote: > > > > Some other editorial nits follow. > > > > In section 4, "these cipher suites MUST NOT be negotiated in TLS > > versions prior to 1.2" should probably clarify that "these" cipher > > suites are the new ones specified by this document. > > > This reminds me of the specification goofs in several TLSv1.2-related > documents about AEAD cipher suites which are responsible for the viability > of the POODLE attack and other exploitable fallback hacks. > > It would be much preferable to avoid/fix those problems and facilitate > the migration to and use of TLSv1.2 without failing TLS handshakes and > band aids such as TLS_FALLBACK_SCSV > > > Suggested improvement: > > The cipher suites defined in this document make use of the > authenticated encryption with additional data (AEAD) defined in TLS > 1.2 [RFC5246] and DTLS 1.2 [RFC6347]. Earlier versions of TLS do not > have support for AEAD and consequently, these cipher suites MUST NOT > - be negotiated in TLS versions prior to 1.2. Clients MUST NOT offer > - these cipher suites if they do not offer TLS 1.2 or later. Servers, > - which select an earlier version of TLS MUST NOT select one of these > - cipher suites. A client MUST treat the selection of these cipher > - suites in combination with a version of TLS that does not support > - AEAD (i.e., TLS 1.1 or earlier) as an error and generate a fatal > - 'illegal_parameter' TLS alert. > + A client that offers > + the cipher suites from this document in ClientHello.cipher_suites > + in combination with (3,1) "TLSv1.0" or (3,2) "TLSv1.1" in > + ClientHello.client_version MUST support TLSv1.2 and MUST accept > + the server to negotiate TLSv1.2 for the current session. If the > + client does not support TLSv1.2 or is not willing to negotiate TLSv1.2, > + then this client MUST NOT offer any of these cipher suites with a > + lower protocol version than (3,3) "TLSv1.2" in > ClientHello.client_version. > + A server receiving a ClientHello and a client_version indicating > + (3,1) "TLSv1.0" or (3,2) "TLSv1.1" and any of the cipher suites from > + this document in ClientHello.cipher_suites can safely assume that the > + client supports TLSv1.2 and is willing to use it. The server MUST > + NOT negotiate these cipher suites with TLS protocol versions earlier > + than TLSv1.2. > + > + Not requiring clients to indicate their support for TLSv1.2 cipher > + suites exclusively through ClientHello.client_hello improves the > + interoperability in the installed base and use of TLSv1.2 AEAD > + cipher suites without upsetting the installed base of version-intolerant > + TLS servers, results in more TLS handshakes succeeding and obviates > + fallback mechanisms. > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113c0cb2910d10054fe2f9e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin,

Thank you for= the proposed text. It was very clear and I took it entirely, just changing= s/TLSv1/TLS 1/.

Yours,
Daniel


The= current text is as follows:
<section title=3D"Applicable TLS Ve= rsions">


<t> The cipher suites defined in this doc= ument MUST NOT be negotiated
for any version of (D)TLS other than TLS 1.= 2.</t>

<t> TLS version 1.3 and later negotiate these fea= tures in a different
manner. Unlike TLS 1.2, TLS 1.3 separates authentic= ation and cipher suite
negotiation <xref target=3D"I-D.ietf-tls-= tls13"/> Section 1.2. TLS 1.3
supports PSK with ECDHE key exchan= ge and the cipher suites
TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,= TLS_AES_128_CCM_8_SHA256
and=C2=A0 TLS_AES_128_CCM_SHA256 are part of t= he specification. As a result,
TLS 1.3 and higher versions, negotiate an= d support these cipher suites
in a different way. </t>

<= t>The cipher suites defined in this document make use of the
authenti= cated encryption with additional data (AEAD) defined in TLS 1.2
<xref= target=3D"RFC5246"/> and DTLS 1.2 <xref target=3D"RFC= 6347" />.
Earlier versions of TLS do not have support for AEAD a= nd consequently,
the cipher suites defined in this document MUST NOT be = negotiated in TLS
versions prior to 1.2.=C2=A0 In addition, it is worth = noting that TLS 1.0
<xref target=3D"RFC2246"/> and TL1.2= <xref target=3D"RFC4346"/> splits the
pre-master in two= parts. The PRF results of mixing the two pseudorandom
streams with dist= inct hash functions (MD5 and SHA-1) by exclusive-ORing
them together. In= the case of ECDHE_PSK authentication, the PSK and
pre-master are treate= d by distinct hash function with distinct
properties. This may introduce= vulnerabilities over the expected
security provided by the constructed = pre-master. As such TLS 1.0 and
TLS 1.1 SHOULD NOT be used with ECDHE_PS= K.</t>

<t>A client that offers the cipher suites from th= is document in
ClientHello.cipher_suites in combination with (3,1) "= ;TLS 1.0" or (3,2)
"TLS 1.1" in ClientHello.client_versio= n MUST support TLS 1.2 and MUST
accept the server to negotiate TLS 1.2 f= or the current session.=C2=A0 If the
client does not support TLS 1.2 or = is not willing to negotiate TLS 1.2,
then this client MUST NOT offer any= of these cipher suites with a lower
protocol version than (3,3) "T= LS 1.2" in ClientHello.client_version.</t>

<t>A ser= ver receiving a ClientHello and a client_version indicating
(3,1) "= TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites fro= m
this document in ClientHello.cipher_suites can safely assume that the<= br>client supports TLS 1.2 and is willing to use it. The server MUST NOTnegotiate these cipher suites with TLS protocol versions earlier than
T= LS 1.2. Not requiring clients to indicate their support for TLS 1.2
ciph= er suites exclusively through ClientHello.client_hello improves the
inte= roperability in the installed base and use of TLS 1.2 AEAD cipher
suites= without upsetting the installed base of version-intolerant TLS
servers,= results in more TLS handshakes succeeding and obviates fallback
mechani= sms.</t>


On Fri, May 19, 2017 at 10:17 AM, Martin Rex &= lt;mrex@sap.com> wrote:
Benjamin Ka= duk wrote:
>
> Some other editorial nits follow.
>
> In section 4, "these cipher suites MUST N= OT be negotiated in TLS
> versions prior to 1.2" should probably clarify that "these&q= uot; cipher
> suites are the new ones specified by this document.


This reminds me of the specification goofs in several TLSv1.2-relate= d
documents about AEAD cipher suites which are responsible for the viability<= br> of the POODLE attack and other exploitable fallback hacks.

It would be much preferable to avoid/fix those problems and facilitate
the migration to and use of TLSv1.2 without failing TLS handshakes and
band aids such as TLS_FALLBACK_SCSV


Suggested improvement:

=C2=A0 =C2=A0The cipher suites defined in this document make use of the
=C2=A0 =C2=A0authenticated encryption with additional data= (AEAD) defined in TLS
=C2=A0 =C2=A01.2 [RFC5246] and DTLS 1.2 [RFC6347].=C2=A0 Earlier ver= sions of TLS do not
=C2=A0 =C2=A0have support for AEAD and consequently, these cipher suites MU= ST NOT
-=C2=A0 be negotiated in TLS versions prior to 1.2.=C2=A0 Clients MUST NOT = offer
-=C2=A0 these cipher suites if they do not offer TLS 1.2 or later.=C2=A0 Se= rvers,
-=C2=A0 which select an earlier version of TLS MUST NOT select one of these=
-=C2=A0 cipher suites.=C2=A0 A client MUST treat the selection of these cip= her
-=C2=A0 suites in combination with a version of TLS that does not support -=C2=A0 AEAD (i.e., TLS 1.1 or earlier) as an error and generate a fatal -=C2=A0 'illegal_parameter' TLS alert.
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0A client that offers
+=C2=A0 the cipher suites from this document in ClientHello.cipher_suites +=C2=A0 in combination with (3,1) "TLSv1.0" or (3,2) "TLSv1.= 1" in
+=C2=A0 ClientHello.client_version MUST support TLSv1.2 and MUST accept
+=C2=A0 the server to negotiate TLSv1.2 for the current session.=C2=A0 If t= he
+=C2=A0 client does not support TLSv1.2 or is not willing to negotiate TLSv= 1.2,
+=C2=A0 then this client MUST NOT offer any of these cipher suites with a +=C2=A0 lower protocol version than (3,3) "TLSv1.2" in ClientHell= o.client_version.
+=C2=A0 A server receiving a ClientHello and a client_version indicating +=C2=A0 (3,1) "TLSv1.0" or (3,2) "TLSv1.1" and any of t= he cipher suites from
+=C2=A0 this document in ClientHello.cipher_suites can safely assume that t= he
+=C2=A0 client supports TLSv1.2 and is willing to use it.=C2=A0 The server = MUST
+=C2=A0 NOT negotiate these cipher suites with TLS protocol versions earlie= r
+=C2=A0 than TLSv1.2.
+
+=C2=A0 Not requiring clients to indicate their support for TLSv1.2 cipher<= br> +=C2=A0 suites exclusively through ClientHello.client_hello improves the +=C2=A0 interoperability in the installed base and use of TLSv1.2 AEAD
+=C2=A0 cipher suites without upsetting the installed base of version-intol= erant
+=C2=A0 TLS servers, results in more TLS handshakes succeeding and obviates=
+=C2=A0 fallback mechanisms.


-Martin

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a113c0cb2910d10054fe2f9e6-- From nobody Fri May 19 09:27:44 2017 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 61EFA129526; Fri, 19 May 2017 09:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUKWvGG-H7b0; Fri, 19 May 2017 09:27:34 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 9E4E7129447; Fri, 19 May 2017 09:27:33 -0700 (PDT) X-AuditID: 1209190d-fd7ff700000023f1-de-591f1cf45586 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id B6.96.09201.4FC1F195; Fri, 19 May 2017 12:27:32 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v4JGRU5P007560; Fri, 19 May 2017 12:27:31 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v4JGRPmR013013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 May 2017 12:27:29 -0400 Date: Fri, 19 May 2017 11:27:25 -0500 From: Benjamin Kaduk To: Daniel Migault Cc: The IESG , secdir@ietf.org, draft-ietf-tls-ecdhe-psk-aead.all@ietf.org, tls , "ietf@ietf.org" Message-ID: <20170519162725.GM39245@kduck.kaduk.org> References: <20170519043827.GL39245@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRmVeSWpSXmKPExsUixCmqrftFRj7SYOEGZYsp0/ewWbxZtonJ YsaficwWzzbOZ7H4sPAhi8Wn812MDmwev75eZfNYsuQnUwBTFJdNSmpOZllqkb5dAlfGnOZP 7AVrHCtONW1gb2BsNeli5OSQEDCRON3/lgnEFhJYzCSxb7EnhL2RUeLXvPQuRi4g+yqTxNpf J1hAEiwCqhLzJh1hBLHZBFQkGrovM4PYIgIGEi8n7GQDsZkFFjBKzPltCGILC7hIrOhbAlbD C7Rs79zdUMuqJY5cmMgGEReUODnzCQtEr5bEjX8vgWo4gGxpieX/OEDCnAKBElM+zAdbKyqg LPH38D2WCYwCs5B0z0LSPQuhewEj8ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdI73czBK91JTS TYzgUJbk3cH4767XIUYBDkYlHt6EX3KRQqyJZcWVuYcYJTmYlER5HQ8DhfiS8lMqMxKLM+KL SnNSiw8xSnAwK4nwMojKRwrxpiRWVqUW5cOkpDlYlMR5xTUaI4QE0hNLUrNTUwtSi2CyMhwc ShK8G6WBGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGvwOp4S0uSMwtzkyHyJ9iVJQS5z0EkhAASWSU 5sH1glKNRPb+mleM4kCvCPOqAROPEA8wTcF1vwIazAQ0uPmBNMjgkkSElFQDY8GJ5y4qF7be uHe8Qtfk+Pfp166E8p07ey9CUC3v0OfjAr3Xdko82Ph5/2Y534mt9w46znyynOGxl/SUvs2t asd3yc4Q8ddVdUpd0LhJ+viBwxW7dv/zsJmrWLT7emSly/XMcOntIlW23G7ftfau3DSjKK7j 53L2oG0WvSIBP3fWRubOPVQR/FWJpTgj0VCLuag4EQBhJEK1EAMAAA== Archived-At: Subject: Re: [secdir] [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 16:27:36 -0000 On Fri, May 19, 2017 at 11:55:35AM -0400, Daniel Migault wrote: > Hi Benjamin, > > Thank you for the review. Please find my comments inline and let me know if > you agree with the proposed text. I believe the only point not addressed > concerns the addition of CCM-256 which has been remove after discussion > during the WGLC. > > Thanks you for the review, > > Yours, > Daniel > > On Fri, May 19, 2017 at 12:38 AM, Benjamin Kaduk wrote: > > > Hi all, > > > > 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 with nits. > > > > Essentially, we are filling in a gap in the TLS (< 1.3) ciphersuite > > space, thought of as a cross product of key exchange and > > cipher+mac/AEAD -- we have some of the combinations (PSK with ECDHE > > but no AES-[GC]CM, PSK with AES-GCM but only non-EC DH, etc.) but > > not quite this one. > > > > That said, it seems a little silly to only partially fill the gap > > (by omitting the AES_256_CCM* cipher suites), even though there is > > not currently demand for them. > > > > MGLT: TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 and > TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 were mentioned in the 01 and removed > after the WGLC. [0] The issue was whether or not introducing new ciphers > not supported by TLS1.3. In 01, we though of adding the code point for > TLS1.2 and then specify that TLS1.3 was only implementing a **subset** of > the cipher suites proposed.In case of needs these could still be supported > later by TLS1.3. The consensus seems to not introduce ciphers that would > not be handled by TLS1.3. If the WG decides otherwise, these could still be > added. > > [0] > https://mailarchive.ietf.org/arch/msg/tls/M442CwmUMxrYJR8FjCh3h-a69o4/?qid=6e4713be1d71bae6718c6e6e6c4b8007 That seems like a reasonable position for the WG to take, given how close TLS 1.3 is to publication. (It would also be reasonable to define the full cross-product for TLS 1.2 only and have TLS 1.3 just use a subset, but I have no real preference.) > > > This document is just assembling pieces that were already specified > > elsewhere, so it need not contain much detail itself, which is fine. > > That said, I think section 3 should probably state explicitly which > > pieces it uses, instead of a vague reference of being "based on RFC > > 4279". So, "The ServerKeyExchange and ClientKeyExchange messages > > from RFC 5489 for ECDHE_PSK are used, and the premaster secret is > > computed in the same manner as for ECDHE_PSK key exchange in RFC > > 5489." (I am not sure why RFC 4279 is cited in the current text; it > > does not cover ECDHE_PSK.) > > > > MGLT: I agree we coudl be more explicit, here are the changes I propose. I > believe it address your purpose. > > OLD: > > Messages and pre-master secret construction in this > document are based on [RFC4279 ]. > > NEW: > > Messages and pre-master secret construction in this > document are defined in [RFC5489]. The ServerKeyExchange > and ClientKeyExchange messages and premaster secret is > computed as for the ECDHE_PSK key exchange. That basically works for me, though I'd tweak the phrasing slightly for clarity/grammar: NEW2: Messages and pre-master secret construction in this document are defined in [RFC5489]. The ServerKeyExchange and ClientKeyExchange messages are used and the premaster secret is computed as for the ECDHE_PSK key exchange. > > > The premaster_secret structure so used basically ends up putting the > > ECDH output first followed by the static PSK; with the pre-TLS 1.2 > > PRF, that would give the ECDH shared secret to md5 and the PSK to > > sha1, which is perhaps another reason to not use these with pre-1.2 > > worth mentioning (in addition to the AEAD availability). > > > > MGLT: I believe the following text address your concern, however I am > wondering if we are not going beyond the scope of expected considerations. It perhaps is and perhaps is not worth mentioning, yes. > In addition, it is worth noting that TLS1.0 and > TL1.2 splits the premaster in two parts. The PRF > results of mixing the two pseudorandom streams with distinct hash functions "results of" is an unusual phrasing; "results from" might be more familiar. > (MD5 and SHA-1) by exclusive-ORing them together. In the case of ECDHE_PSK > authentication, the PSK and pre-master are treated by distinct hash > function with distinct properties. This may introduce vulnerabilities over > the expected security provided by the constructed pre-master. As such > TLS1.0 and TLS1.1 SHOULD NOT be used with ECDHE_PSK. The general tenor of this text addresses my concern, yes, but feel free to use editorial discretion and not bother putting it in, if you don't think it's useful. (BTW, I think we are still TLS1.0 and TLS1.1 MUST NOT be used with these ciphersuites, so maybe the SHOULD NOT in the last sentence is not quite what is intended.) > > > The security considerations largely refer to those of the other > > documents providing the pieces that are combined together here; > > those referenced security considerations sections are more than > > adequate here, as this document itself does not really do anything > > particularly novel. That said, if we are going to reiterate the > > entropy requirement for PSKs inline, we probably ought to also > > reiterate the nonce-reuse considerations for GCM and CCM. The > > relevant constructions help, but there are still ways to mess up and > > reuse a nonce when doing crypto in parallel, if I remember the > > GCM/TLS document's security considerations correctly. > > > > MGLT: I believe the following text address your comments. > > GCM or CCM encryption - even of different clear text - re-using a > nonce with a same key undermines the security of GCM and CCM. As a > result, GCM and CCM MUST only be used with system guaranteeing nonce > uniqueness . Sure, sounds good. (Grammar nit: "a system".) > > > > > Some other editorial nits follow. > > > > > In section 2, the RFC 7525 reference that "AEAD algorithms [...] are > > strongly recommended" is scoped to just (D)TLS, so the text here > > should probably also list that qualification. > > > > MGLT: I believe the following text address your concern: > > OLD text: > AEAD algorithms that combine encryption and integrity protection are > strongly recommended for and non-AEAD algorithms > are forbidden to use in TLS 1.3 . > > NEW text: > AEAD algorithms that combine encryption and integrity protection are > strongly recommended for (D)TLS and non-AEAD > algorithms > are forbidden to use in TLS 1.3 . Yes, thanks. > > In section 4, "... make use of the authenticated encryption with > > additional data (AEAD) defined in TLS 1.2" seems to make AEAD into > > something of a unique object, as opposed to a class of things with > > multiple possible instantiations. I would consider something like > > "... (AEAD) concept". > > > > In section 4, "these cipher suites MUST NOT be negotiated in TLS > > versions prior to 1.2" should probably clarify that "these" cipher > > suites are the new ones specified by this document. > > > > MGLT: I believe the following text address your comment: > > OLD: > these cipher suites MUST NOT be negotiated in TLS versions prior to 1.2. > > NEW: > the cipher suites defined in this document MUST NOT be negotiated in TLS > versions prior to 1.2. > > OLD: > Clients MUST NOT offer these cipher suites > > NEW: > Clients MUST NOT offer these cipher suites defined in this document I think I only intended to comment about the first one, but there is no harm in changing both. Thanks! -Ben From nobody Fri May 19 09:58:27 2017 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 159E2129526; Fri, 19 May 2017 09:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEOmbOLhX0KY; Fri, 19 May 2017 09:58:10 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55ED71294F4; Fri, 19 May 2017 09:58:10 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id 99so4186874lfu.1; Fri, 19 May 2017 09:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+V2BlG7CJ4wjwDCI5HgOPAYPEgdbYUi0drEqepx0PpY=; b=GbUP8NcWDSRJL37PEG3lENkC5o5sqFJGz5ZU0eXFG5i8s9C62XHUXcsNn4cI5OxExJ d97SlGJZCfnO1zDzsb2sYcSN5dLE275JNb2lqCZlCn/tySN5g179k1vLBljS2uCXsTVX zye2rF35ktbC/jQefDZfaABSGc+8NYU6zmznNjcgksl5lIS98BCTXce6jlKic5Xvwt86 wkmTCDXO1yL0cUbu8HLwil0gNYSFV3f+TH1KPM5GtoGIAvclqGGdi6yemYTvshSnvPfX qLJ7DC2Idah65cy0/hRilitcHS+pdCuw5TbTuCl2/AgY3DWyAzggrKGRF9o858tUGMYi H9tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+V2BlG7CJ4wjwDCI5HgOPAYPEgdbYUi0drEqepx0PpY=; b=HuMMTwJAVABH1Z+DtlrYk6zFcbSZomBlIAxR1ttJlCewDJMllGbK7TUhfG8MrtfCxg wzpyaodv7AkbK3ZrZ4X6w5gDfcgzIpUgowQjB6sz/DfPlU2N2c9M3z+8loNrWjkQFlN5 q7/1+ytbt7cCskkF8ntE4vR/RqUdm/LHR/p1zu3pLpZxThTGzLThws1tz1GBDjIR074F zDmtBrsfr7yS4gUv/yfTadtL58IK2IYxOoe99YeUPVO+DG9f5D4L4zTm7VxwcR+fbBb+ 6VStK2xOt1C/UsaDuxSL5TSXuijlLqWpifSlWCq858zVmzRc8eM7l6WqibY5v+RdCsM2 YflQ== X-Gm-Message-State: AODbwcBRxwpTAYFV+Ev4iFBYLfpwf0Ib7ogoYG6+SxRKfkTHhkqZ5m+V nlBtL/V+wskUu9dFnwGTp2SAikFITw== X-Received: by 10.46.69.8 with SMTP id s8mr2564481lja.55.1495213088509; Fri, 19 May 2017 09:58:08 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.0.14 with HTTP; Fri, 19 May 2017 09:58:07 -0700 (PDT) In-Reply-To: <20170519162725.GM39245@kduck.kaduk.org> References: <20170519043827.GL39245@kduck.kaduk.org> <20170519162725.GM39245@kduck.kaduk.org> From: Daniel Migault Date: Fri, 19 May 2017 12:58:07 -0400 X-Google-Sender-Auth: 1raqJXhaY3kI7429EhZs5caQhV8 Message-ID: To: Benjamin Kaduk Cc: tls , draft-ietf-tls-ecdhe-psk-aead.all@ietf.org, "ietf@ietf.org" , The IESG , secdir@ietf.org Content-Type: multipart/alternative; boundary="001a114b07fe0114c9054fe36d55" Archived-At: Subject: Re: [secdir] [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 16:58:14 -0000 --001a114b07fe0114c9054fe36d55 Content-Type: text/plain; charset="UTF-8" Thank you, Your comments have all been addressed. I have one remaining clarification. In my text the SHOULD NOT was intended to the ECDHE_PSK in general, and not only for the cipher suites of the draft. In your opinion do we clarify this, and should we use something else than SHOULD NOT ? Thanks for the reviews! Yours, Daniel > (MD5 and SHA-1) by exclusive-ORing them together. In the case of ECDHE_PSK > authentication, the PSK and pre-master are treated by distinct hash > function with distinct properties. This may introduce vulnerabilities over > the expected security provided by the constructed pre-master. As such > TLS1.0 and TLS1.1 SHOULD NOT be used with ECDHE_PSK. The general tenor of this text addresses my concern, yes, but feel free to use editorial discretion and not bother putting it in, if you don't think it's useful. (BTW, I think we are still TLS1.0 and TLS1.1 MUST NOT be used with these ciphersuites, so maybe the SHOULD NOT in the last sentence is not quite what is intended.) On Fri, May 19, 2017 at 12:27 PM, Benjamin Kaduk wrote: > On Fri, May 19, 2017 at 11:55:35AM -0400, Daniel Migault wrote: > > Hi Benjamin, > > > > Thank you for the review. Please find my comments inline and let me know > if > > you agree with the proposed text. I believe the only point not addressed > > concerns the addition of CCM-256 which has been remove after discussion > > during the WGLC. > > > > Thanks you for the review, > > > > Yours, > > Daniel > > > > On Fri, May 19, 2017 at 12:38 AM, Benjamin Kaduk wrote: > > > > > Hi all, > > > > > > 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 with nits. > > > > > > Essentially, we are filling in a gap in the TLS (< 1.3) ciphersuite > > > space, thought of as a cross product of key exchange and > > > cipher+mac/AEAD -- we have some of the combinations (PSK with ECDHE > > > but no AES-[GC]CM, PSK with AES-GCM but only non-EC DH, etc.) but > > > not quite this one. > > > > > > That said, it seems a little silly to only partially fill the gap > > > (by omitting the AES_256_CCM* cipher suites), even though there is > > > not currently demand for them. > > > > > > MGLT: TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 and > > TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 were mentioned in the 01 and > removed > > after the WGLC. [0] The issue was whether or not introducing new ciphers > > not supported by TLS1.3. In 01, we though of adding the code point for > > TLS1.2 and then specify that TLS1.3 was only implementing a **subset** of > > the cipher suites proposed.In case of needs these could still be > supported > > later by TLS1.3. The consensus seems to not introduce ciphers that would > > not be handled by TLS1.3. If the WG decides otherwise, these could still > be > > added. > > > > [0] > > https://mailarchive.ietf.org/arch/msg/tls/M442CwmUMxrYJR8FjCh3h-a69o4/? > qid=6e4713be1d71bae6718c6e6e6c4b8007 > > That seems like a reasonable position for the WG to take, given how > close TLS 1.3 is to publication. (It would also be reasonable to > define the full cross-product for TLS 1.2 only and have TLS 1.3 just > use a subset, but I have no real preference.) > > > > > > This document is just assembling pieces that were already specified > > > elsewhere, so it need not contain much detail itself, which is fine. > > > That said, I think section 3 should probably state explicitly which > > > pieces it uses, instead of a vague reference of being "based on RFC > > > 4279". So, "The ServerKeyExchange and ClientKeyExchange messages > > > from RFC 5489 for ECDHE_PSK are used, and the premaster secret is > > > computed in the same manner as for ECDHE_PSK key exchange in RFC > > > 5489." (I am not sure why RFC 4279 is cited in the current text; it > > > does not cover ECDHE_PSK.) > > > > > > > MGLT: I agree we coudl be more explicit, here are the changes I propose. > I > > believe it address your purpose. > > > > OLD: > > > > Messages and pre-master secret construction in this > > document are based on [RFC4279 ]. > > > > NEW: > > > > Messages and pre-master secret construction in this > > document are defined in [RFC5489]. The ServerKeyExchange > > and ClientKeyExchange messages and premaster secret is > > computed as for the ECDHE_PSK key exchange. > > That basically works for me, though I'd tweak the phrasing slightly > for clarity/grammar: > > NEW2: > > Messages and pre-master secret construction in this > document are defined in [RFC5489]. The ServerKeyExchange > and ClientKeyExchange messages are used and the premaster secret is > computed as for the ECDHE_PSK key exchange. > > > > > > > The premaster_secret structure so used basically ends up putting the > > > ECDH output first followed by the static PSK; with the pre-TLS 1.2 > > > PRF, that would give the ECDH shared secret to md5 and the PSK to > > > sha1, which is perhaps another reason to not use these with pre-1.2 > > > worth mentioning (in addition to the AEAD availability). > > > > > > > MGLT: I believe the following text address your concern, however I am > > wondering if we are not going beyond the scope of expected > considerations. > > It perhaps is and perhaps is not worth mentioning, yes. > > > In addition, it is worth noting that TLS1.0 and > > TL1.2 splits the premaster in two parts. The PRF > > results of mixing the two pseudorandom streams with distinct hash > functions > > "results of" is an unusual phrasing; "results from" might be more > familiar. > > > (MD5 and SHA-1) by exclusive-ORing them together. In the case of > ECDHE_PSK > > authentication, the PSK and pre-master are treated by distinct hash > > function with distinct properties. This may introduce vulnerabilities > over > > the expected security provided by the constructed pre-master. As such > > TLS1.0 and TLS1.1 SHOULD NOT be used with ECDHE_PSK. > > The general tenor of this text addresses my concern, yes, but feel > free to use editorial discretion and not bother putting it in, if > you don't think it's useful. (BTW, I think we are still TLS1.0 and > TLS1.1 MUST NOT be used with these ciphersuites, so maybe the SHOULD > NOT in the last sentence is not quite what is intended.) > > > > > > The security considerations largely refer to those of the other > > > documents providing the pieces that are combined together here; > > > those referenced security considerations sections are more than > > > adequate here, as this document itself does not really do anything > > > particularly novel. That said, if we are going to reiterate the > > > entropy requirement for PSKs inline, we probably ought to also > > > reiterate the nonce-reuse considerations for GCM and CCM. The > > > relevant constructions help, but there are still ways to mess up and > > > reuse a nonce when doing crypto in parallel, if I remember the > > > GCM/TLS document's security considerations correctly. > > > > > > > MGLT: I believe the following text address your comments. > > > > GCM or CCM encryption - even of different clear text - re-using a > > nonce with a same key undermines the security of GCM and CCM. As a > > result, GCM and CCM MUST only be used with system guaranteeing nonce > > uniqueness . > > Sure, sounds good. (Grammar nit: "a system".) > > > > > > > > > Some other editorial nits follow. > > > > > > > > In section 2, the RFC 7525 reference that "AEAD algorithms [...] are > > > strongly recommended" is scoped to just (D)TLS, so the text here > > > should probably also list that qualification. > > > > > > > MGLT: I believe the following text address your concern: > > > > OLD text: > > AEAD algorithms that combine encryption and integrity protection are > > strongly recommended for and non-AEAD > algorithms > > are forbidden to use in TLS 1.3 . > > > > NEW text: > > AEAD algorithms that combine encryption and integrity protection are > > strongly recommended for (D)TLS and non-AEAD > > algorithms > > are forbidden to use in TLS 1.3 . > > Yes, thanks. > > > > In section 4, "... make use of the authenticated encryption with > > > additional data (AEAD) defined in TLS 1.2" seems to make AEAD into > > > something of a unique object, as opposed to a class of things with > > > multiple possible instantiations. I would consider something like > > > "... (AEAD) concept". > > > > > > In section 4, "these cipher suites MUST NOT be negotiated in TLS > > > versions prior to 1.2" should probably clarify that "these" cipher > > > suites are the new ones specified by this document. > > > > > > MGLT: I believe the following text address your comment: > > > > OLD: > > these cipher suites MUST NOT be negotiated in TLS versions prior to 1.2. > > > > NEW: > > the cipher suites defined in this document MUST NOT be negotiated in TLS > > versions prior to 1.2. > > > > OLD: > > Clients MUST NOT offer these cipher suites > > > > NEW: > > Clients MUST NOT offer these cipher suites defined in this document > > I think I only intended to comment about the first one, but there is > no harm in changing both. Thanks! > > > -Ben > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114b07fe0114c9054fe36d55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you,

Your comments have= all been addressed. I have one remaining clarification. In my text the SHO= ULD NOT was intended to the ECDHE_PSK in general, and not only for the ciph= er suites of the draft. In your opinion do we clarify this, and should we u= se something else than SHOULD NOT ?

Thanks for the review= s!

Yours,
Daniel

> (MD5 and SHA-1) by exclusive-ORing them together. In the case o= f ECDHE_PSK
> authentication, the PSK and pre-master are treated by distinct hash > function with distinct properties. This may introduce vulnerabilities = over
> the expected security provided by the constructed pre-master. As such<= br> > TLS1.0 and TLS1.1 SHOULD NOT be used with ECDHE_PSK.

The general tenor of this text addresses my concern, yes, but feel free to use editorial discretion and not bother putting it in, if
you don't think it's useful.=C2=A0 (BTW, I think we are still TLS1.= 0 and
TLS1.1 MUST NOT be used with these ciphersuites, so maybe the SHOULD
NOT in the last sentence is not quite what is intended.)
<= div class=3D"gmail_extra">
On Fri, May 19, 20= 17 at 12:27 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
On Fri, May= 19, 2017 at 11:55:35AM -0400, Daniel Migault wrote:
> Hi Benjamin,
>
> Thank you for the review. Please find my comments inline and let me kn= ow if
> you agree with the proposed text. I believe the only point not address= ed
> concerns the addition of CCM-256 which has been remove after discussio= n
> during the WGLC.
>
> Thanks you for the review,
>
> Yours,
> Daniel
>
> On Fri, May 19, 2017 at 12:38 AM, Benjamin Kaduk <kaduk@mit.edu> wrote:
>
> > Hi all,
> >
> > I have reviewed this document as part of the security directorate= 's
> > ongoing effort to review all IETF documents being processed by th= e
> > IESG.=C2=A0 These comments were written primarily for the benefit= of the
> > security area directors.=C2=A0 Document editors and WG chairs sho= uld
> > treat these comments just like any other last call comments.
> >
> > This document is ready with nits.
> >
> > Essentially, we are filling in a gap in the TLS (< 1.3) cipher= suite
> > space, thought of as a cross product of key exchange and
> > cipher+mac/AEAD -- we have some of the combinations (PSK with ECD= HE
> > but no AES-[GC]CM, PSK with AES-GCM but only non-EC DH, etc.) but=
> > not quite this one.
> >
> > That said, it seems a little silly to only partially fill the gap=
> > (by omitting the AES_256_CCM* cipher suites), even though there i= s
> > not currently demand for them.
> >
> > MGLT: TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 and
> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384=C2=A0 were mentioned in the= 01 and removed
> after=C2=A0 the WGLC. [0] The issue was whether or not introducing new= ciphers
> not supported by TLS1.3. In 01, we though of adding the code point for=
> TLS1.2 and then specify that TLS1.3 was only implementing a **subset**= of
> the cipher suites proposed.In case of needs these could still be suppo= rted
> later by TLS1.3. The consensus seems to not introduce ciphers that wou= ld
> not be handled by TLS1.3. If the WG decides otherwise, these could sti= ll be
> added.
>
> [0]
> https://mailarchive.ietf.org/arch/msg/tls/M442CwmUM= xrYJR8FjCh3h-a69o4/?qid=3D6e4713be1d71bae6718c6e6e6c4b8007

That seems like a reasonable position for the WG to take, given= how
close TLS 1.3 is to publication.=C2=A0 (It would also be reasonable to
define the full cross-product for TLS 1.2 only and have TLS 1.3 just
use a subset, but I have no real preference.)

>
> > This document is just assembling pieces that were already specifi= ed
> > elsewhere, so it need not contain much detail itself, which is fi= ne.
> > That said, I think section 3 should probably state explicitly whi= ch
> > pieces it uses, instead of a vague reference of being "based= on RFC
> > 4279".=C2=A0 So, "The ServerKeyExchange and ClientKeyEx= change messages
> > from RFC 5489 for ECDHE_PSK are used, and the premaster secret is=
> > computed in the same manner as for ECDHE_PSK key exchange in RFC<= br> > > 5489."=C2=A0 (I am not sure why RFC 4279 is cited in the cur= rent text; it
> > does not cover ECDHE_PSK.)
> >
>
> MGLT: I agree we coudl be more explicit, here are the changes I propos= e. I
> believe it address your purpose.
>
> OLD:
>
> Messages and pre-master secret construction in this
> document are based on [RFC4279 <https://tools.ietf= .org/html/rfc4279>].
>
> NEW:
>
> Messages and pre-master secret construction in this
> document are defined in [RFC5489]. The ServerKeyExchange
> and ClientKeyExchange messages and premaster secret is
> computed as for=C2=A0 the ECDHE_PSK key exchange.

That basically works for me, though I'd tweak the phrasing sligh= tly
for clarity/grammar:

NEW2:

Messages and pre-master secret construction in this
document are defined in [RFC5489]. The ServerKeyExchange
and ClientKeyExchange messages are used and the premaster secret is<= br> computed as for the ECDHE_PSK key exchange.


>
> > The premaster_secret structure so used basically ends up putting = the
> > ECDH output first followed by the static PSK; with the pre-TLS 1.= 2
> > PRF, that would give the ECDH shared secret to md5 and the PSK to=
> > sha1, which is perhaps another reason to not use these with pre-1= .2
> > worth mentioning (in addition to the AEAD availability).
> >
>
> MGLT: I believe the following text address your concern, however I am<= br> > wondering if we are not going beyond the scope of expected considerati= ons.

It perhaps is and perhaps is not worth mentioning, yes.

> In addition, it is worth noting that TLS1.0 <xref target=3D"RF= C2246"/> and
> TL1.2 <xref target=3D"RFC4346"/> splits the premaster = in two parts. The PRF
> results of mixing the two pseudorandom streams with distinct hash func= tions

"results of" is an unusual phrasing; "results from&qu= ot; might be more
familiar.

> (MD5 and SHA-1) by exclusive-ORing them together. In the case of ECDHE= _PSK
> authentication, the PSK and pre-master are treated by distinct hash > function with distinct properties. This may introduce vulnerabilities = over
> the expected security provided by the constructed pre-master. As such<= br> > TLS1.0 and TLS1.1 SHOULD NOT be used with ECDHE_PSK.

The general tenor of this text addresses my concern, yes, but feel free to use editorial discretion and not bother putting it in, if
you don't think it's useful.=C2=A0 (BTW, I think we are still TLS1.= 0 and
TLS1.1 MUST NOT be used with these ciphersuites, so maybe the SHOULD
NOT in the last sentence is not quite what is intended.)

>
> > The security considerations largely refer to those of the other > > documents providing the pieces that are combined together here; > > those referenced security considerations sections are more than > > adequate here, as this document itself does not really do anythin= g
> > particularly novel.=C2=A0 That said, if we are going to reiterate= the
> > entropy requirement for PSKs inline, we probably ought to also > > reiterate the nonce-reuse considerations for GCM and CCM.=C2=A0 T= he
> > relevant constructions help, but there are still ways to mess up = and
> > reuse a nonce when doing crypto in parallel, if I remember the > > GCM/TLS document's security considerations correctly.
> >
>
> MGLT: I believe the following text address your comments.
>
>=C2=A0 <t>GCM or CCM encryption - even of different clear text - = re-using a
> nonce with a same key undermines the security of GCM and CCM. As a
> result, GCM and CCM MUST only be used with system guaranteeing nonce > uniqueness <xref target=3D"RFC5116"/>.</t>

Sure, sounds good.=C2=A0 (Grammar nit: "a system".)

>
> >
> > Some other editorial nits follow.
> >
>
> > In section 2, the RFC 7525 reference that= "AEAD algorithms [...] are
> > strongly recommended" is scoped to just (D)TLS, so the text = here
> > should probably also list that qualification.
> >
>
> MGLT: I believe the following text address your concern:
>
> OLD text:
> <t>AEAD algorithms that combine encryption and integrity protect= ion are
> strongly recommended for <xref target=3D"RFC7525" /> a= nd non-AEAD algorithms
> are forbidden to use in TLS 1.3 <xref target=3D"I-D.ietf-tls-t= ls13"/>.
>
> NEW text:
> <t>AEAD algorithms that combine encryption and integrity protect= ion are
> strongly recommended for (D)TLS <xref target=3D"RFC7525" = /> and non-AEAD
> algorithms
> are forbidden to use in TLS 1.3 <xref target=3D"I-D.ietf-tls-t= ls13"/>.

Yes, thanks.

> > In section 4, "... make use of the authenticated encryption = with
> > additional data (AEAD) defined in TLS 1.2" seems to make AEA= D into
> > something of a unique object, as opposed to a class of things wit= h
> > multiple possible instantiations.=C2=A0 I would consider somethin= g like
> > "... (AEAD) concept".
> >
> > In section 4, "these cipher suites MUST NOT be negotiated in= TLS
> > versions prior to 1.2" should probably clarify that "th= ese" cipher
> > suites are the new ones specified by this document.
> >
> > MGLT: I believe the following text address your comment:
>
> OLD:
> these cipher suites MUST NOT be negotiated in TLS=C2=A0 versions prior= to 1.2.
>
> NEW:
> the cipher suites defined in this document MUST NOT be negotiated in T= LS
> versions prior to 1.2.
>
>=C2=A0 OLD:
> Clients MUST NOT offer these cipher suites
>
> NEW:
> Clients MUST NOT offer these cipher suites defined in this document
I think I only intended to comment about the first one, but there is=
no harm in changing both.=C2=A0 Thanks!


-Ben

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a114b07fe0114c9054fe36d55-- From nobody Mon May 22 10:36:05 2017 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 CB0BC12EB31; Mon, 22 May 2017 10:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjJkW-SRmM2z; Mon, 22 May 2017 10:35:43 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 2F54B1200ED; Mon, 22 May 2017 10:35:43 -0700 (PDT) X-AuditID: 1209190c-07dff70000001ef4-ff-5923216d00d9 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id A1.FB.07924.D6123295; Mon, 22 May 2017 13:35:42 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v4MHZei6031223; Mon, 22 May 2017 13:35:40 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v4MHZZb2025266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 May 2017 13:35:38 -0400 Date: Mon, 22 May 2017 12:35:35 -0500 From: Benjamin Kaduk To: Daniel Migault Cc: tls , draft-ietf-tls-ecdhe-psk-aead.all@ietf.org, "ietf@ietf.org" , The IESG , secdir@ietf.org Message-ID: <20170522173534.GT39245@kduck.kaduk.org> References: <20170519043827.GL39245@kduck.kaduk.org> <20170519162725.GM39245@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHIsWRmVeSWpSXmKPExsUixG6nopunqBxpcP8Yq8WU6XvYLN4s28Rk MePPRGaLZxvns1h8WPiQxeLT+S5GBzaPX1+vsnksWfKTKYApissmJTUnsyy1SN8ugSvj748D zAXTOSqeLLnA2sC4na2LkZNDQsBEYmXvW8YuRi4OIYHFTBKTbx9hBEkICWxklJjRVwCRuMok 8WD7dCaQBIuAqsS/W+9YQGw2ARWJhu7LzCC2iICBxMsJO9lAGpgFFjBK7GtqAysSFnCRWNG3 BKyIF2hdz45+qA1vGSU2PqiHiAtKnJz5BKyeWUBL4sa/l0DLOIBsaYnl/zhATE6BQIn76/hB KkQFlCX+Hr7HMoFRYBaS5llImmchNC9gZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qka6iXm1mi l5pSuokRFMyckjw7GM+88TrEKMDBqMTDq/FYKVKINbGsuDL3EKMkB5OSKO/RN0AhvqT8lMqM xOKM+KLSnNTiQ4wSHMxKIrx57MqRQrwpiZVVqUX5MClpDhYlcV4JjcYIIYH0xJLU7NTUgtQi mKwMB4eSBO9kBaBGwaLU9NSKtMycEoQ0EwcnyHAeoOGzQWp4iwsSc4sz0yHypxgVpcR5d4Ak BEASGaV5cL2gZCORvb/mFaM40CvCvGUgVTzARAXX/QpoMBPQYOtn8iCDSxIRUlINjK3n5JZk O9V/1Uyc16yopM53cm3Gju8rp1x86aW/YM6es7tXVxm6s6s+0NtTHdWen6ZwnW3R6ndZK55x GlZwLnddckukpXz6S1ed3U7M0rv33v/+TZ7plczSvV6OqRuZZrYp5J+b5dXKnbnRwEmUhana KiFD0VJ5+p5rV+PzL+7oWpqRsVg8UYmlOCPRUIu5qDgRAHMN/G0RAwAA Archived-At: Subject: Re: [secdir] [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 17:35:45 -0000 Sorry for the slow reply. On Fri, May 19, 2017 at 12:58:07PM -0400, Daniel Migault wrote: > Thank you, > > Your comments have all been addressed. I have one remaining clarification. > In my text the SHOULD NOT was intended to the ECDHE_PSK in general, and not > only for the cipher suites of the draft. In your opinion do we clarify > this, and should we use something else than SHOULD NOT ? It's somewhat awkward, as what we really want to do is Update RFC 5489 to add this prohibition there. But, that's more process to jump through and this document is already at a late stage, so I do not actually propose doing that. I would be okay saying As such, all ECDHE_PSK ciphers, including those defined outside this document, SHOULD NOT be negotiated in TLS versions prior to 1.2. to match up with the MUST NOT text we have for these new ciphers. (Taking into account Martin's text that the prohibition is on negotiating them, but offering them in a ClientHello that also offers the old version is okay.) -Ben From nobody Tue May 23 03:24:46 2017 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 D534B129A92 for ; Tue, 23 May 2017 03:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thoyn-nR3H2u for ; Tue, 23 May 2017 03:24:43 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A226612940B for ; Tue, 23 May 2017 03:24:42 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id h4so45609227lfj.3 for ; Tue, 23 May 2017 03:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=0sFBOjGJ87ZQQ07bnX841FuNERFhfjG6DuXptLFhyp0=; b=UzpCQ7i/LKEky+TQ33Ork8/a3qwpMnHDLr1kQg6tk3O26MjWkZBq4AjmBufKzSR++A ddMcAg8uOoBy+GPRsxxqvyvgUj3XiPfYejJgo8yjO7rBoE6Iap6dsIqyDsBynm0l5T5e YqqBsBEKRPKeqaviqboI+ZOUQanVbP0LSI0iflutiIzfJyP2vB9b6rIQYq5v6/mc6AwH Ic7wPtsxR8N5Yc+D2m2zmdqNp5Wim1/P7Z+U7B2h4Rx/qLlIIeSNpePMrpexnRBZ/roN 80UkaoADcchMPXeyOG4qz1DHRTzdKZPwlstnFknF3U9cuPvVY1j7AZZxjGN/htlTSpJ2 Lkkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=0sFBOjGJ87ZQQ07bnX841FuNERFhfjG6DuXptLFhyp0=; b=fRJ1YNs98RKtPcdD/gOoLmj8gWwHQxH2od2eeVYZu5pqG68wH+eNFJvNB/ERR0TVBe rHzgOZiOeWHAwkhlBXnkxtS8R7/9ZobHymz0Ro3QdQpun0kLBmyalFvTGpIxsKnejXHR Lv1/GmHf9PmQFZJ6U1BbH7nG7/pPKv6BJc4mBKctH3MxUBc/w2p920EYUNPfPZT4aQET YU4vPxlG6UEc5XgrZ7jy5fhM3ProczefiSJEQPDsPhK6dntNmSTX8zHd1KNu5HxpgQSO dRSbWoh1iEI2rog0+HXHnu/+1fzKPCZtDjTyq6sp/TMGJRJbipkLKO+B4VHZIb8a/CcM Y/Qw== X-Gm-Message-State: AODbwcArZYmTFvllRBFSUnWa/Sdi+k/9fpyhG86QC0At7BqitnwWNRYo q6wLRarCYhTsBDz8 X-Received: by 10.46.21.73 with SMTP id 9mr6840635ljv.118.1495535080581; Tue, 23 May 2017 03:24:40 -0700 (PDT) Received: from ?IPv6:2001:6b0:7:1:46f:449a:b219:7a5a? ([2001:6b0:7:1:46f:449a:b219:7a5a]) by smtp.gmail.com with ESMTPSA id k81sm78299lfe.22.2017.05.23.03.24.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 May 2017 03:24:39 -0700 (PDT) To: draft-ietf-idr-shutdown.all@ietf.org, "iesg@ietf.org" , "secdir@ietf.org" From: Leif Johansson Message-ID: <9567c18c-b165-bbf6-29ca-40f5ca5de8b0@sunet.se> Date: Tue, 23 May 2017 12:24:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [secdir] secdir review of draft-ietf-idr-shutdown-08 (Ready) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 10:24:45 -0000 Status: 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 document describes a simple and straight-forward mechanism to notify BGP peers of shutdown/reset events. The security considerations section clearly spells out the limitations and caveats involved and gives advice for what semantic to assign the message. Best R Leif Johansson From nobody Tue May 23 15:05:08 2017 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 65C7512EB49; Tue, 23 May 2017 15:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjov76PGlap3; Tue, 23 May 2017 15:04:58 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 012C912EB25; Tue, 23 May 2017 15:04:57 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id h4so57645961lfj.3; Tue, 23 May 2017 15:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BcPuDhO1pMmWTz00D2DzmDeckG9yrIFP/RDyuvcpmwU=; b=hk37aTM1gMC9xmHLiM2X1NRjMy1scZR1bHf9D5zFEV6SSSrE+w394A8e9X3OMh3E0I F8KVMl0nGPzN7DnpeXbI7O6hPd9wXgIZBEp81TIkns/d6qsaKrEIXrYgige0mCjFz0CO sqChPjKGzfeU3JxSgdIEJEmKvxjPzxSLWnHaZCqDD6V5IkqsWZqPoRXK4iBbPXNASHco GGbKW20PvPF+UscI92OK4D8SxqNpi08d2wdF74E8SIPFfozWvMuMKo4HTvBhFVQOsvEe WCQxZ2fxGFxW/82Cgv7Pq+/RBsA3JpRHZQYa2QYpeUm7A5m/zLfGgDagmcVLnUg+UvpA tZqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=BcPuDhO1pMmWTz00D2DzmDeckG9yrIFP/RDyuvcpmwU=; b=f3QU4YUL9/a0DaBKhu02KBpWiXCtZAyLS0QH5uiHZMxaay2jrYDFFokepXRN8rf/1R ML1LromVNGH6R/x8hCX5AZl09yxleiTbVIaHhJ2KAD9p6fTM5ctIoRDeCJREBFg8A6qU PZvjbuGKk8dXp+r4uCVQWUUPKRrExd57u1LTjd6KgHKr3CCUS03s+SW/WdVFG7XDHxZj vfJrBWvUQS2jt7GxKFwK5AfMjUOfRQGvc9sd6a7R38+ZOncrZERXAK+swduIkkNbsfrZ Xec2bXgusWTe1X7Ykbq4ZsghsANsZBOoXeIJYCzwUCSWNWAZzkbuRkHNO5JfRgYhF3F4 LVng== X-Gm-Message-State: AODbwcD9LVtd4OZAxukI0lQNvXLiZx4SSscX+jJIEnI3FrijXuwtI8jA fsiChjAnmE12J36oeGaa99Ep1Rbecg== X-Received: by 10.46.81.17 with SMTP id f17mr8864653ljb.96.1495577096361; Tue, 23 May 2017 15:04:56 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.0.14 with HTTP; Tue, 23 May 2017 15:04:55 -0700 (PDT) In-Reply-To: <20170522173534.GT39245@kduck.kaduk.org> References: <20170519043827.GL39245@kduck.kaduk.org> <20170519162725.GM39245@kduck.kaduk.org> <20170522173534.GT39245@kduck.kaduk.org> From: Daniel Migault Date: Tue, 23 May 2017 18:04:55 -0400 X-Google-Sender-Auth: mo_QA4jOMmlD5y2_qXqm4vGR1-M Message-ID: To: Benjamin Kaduk Cc: tls , draft-ietf-tls-ecdhe-psk-aead.all@ietf.org, "ietf@ietf.org" , The IESG , secdir@ietf.org Content-Type: multipart/alternative; boundary="f403045ff93c901dac0550382d46" Archived-At: Subject: Re: [secdir] [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 22:04:59 -0000 --f403045ff93c901dac0550382d46 Content-Type: text/plain; charset="UTF-8" Thank you for the clarifying text. I have added it on my local copy. Yours, Daniel On Mon, May 22, 2017 at 1:35 PM, Benjamin Kaduk wrote: > Sorry for the slow reply. > > On Fri, May 19, 2017 at 12:58:07PM -0400, Daniel Migault wrote: > > Thank you, > > > > Your comments have all been addressed. I have one remaining > clarification. > > In my text the SHOULD NOT was intended to the ECDHE_PSK in general, and > not > > only for the cipher suites of the draft. In your opinion do we clarify > > this, and should we use something else than SHOULD NOT ? > > It's somewhat awkward, as what we really want to do is Update RFC > 5489 to add this prohibition there. But, that's more process to > jump through and this document is already at a late stage, so I do > not actually propose doing that. I would be okay saying > > As such, all ECDHE_PSK ciphers, including those defined outside > this document, SHOULD NOT be negotiated in TLS versions prior to > 1.2. > > to match up with the MUST NOT text we have for these new ciphers. > (Taking into account Martin's text that the prohibition is on > negotiating them, but offering them in a ClientHello that also > offers the old version is okay.) > > -Ben > --f403045ff93c901dac0550382d46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for the clarifying text. I have added = it on my local copy.
Yours,
Daniel

On Mon, May 22, 2017 at 1:3= 5 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
Sorry for the slow reply.

On Fri, May 19, 2017 at 12:58:07PM -0400, Daniel Migault wrote:
> Thank you,
>
> Your comments have all been addressed. I have one remaining clarificat= ion.
> In my text the SHOULD NOT was intended to the ECDHE_PSK in general, an= d not
> only for the cipher suites of the draft. In your opinion do we clarify=
> this, and should we use something else than SHOULD NOT ?

It's somewhat awkward, as what we really want to do is Update RF= C
5489 to add this prohibition there.=C2=A0 But, that's more process to jump through and this document is already at a late stage, so I do
not actually propose doing that.=C2=A0 I would be okay saying

=C2=A0 As such, all ECDHE_PSK ciphers, including those defined outside
=C2=A0 this document, SHOULD NOT be negotiated in TLS versions prior to
=C2=A0 1.2.

to match up with the MUST NOT text we have for these new ciphers.
(Taking into account Martin's text that the prohibition is on
negotiating them, but offering them in a ClientHello that also
offers the old version is okay.)

-Ben

--f403045ff93c901dac0550382d46-- From nobody Tue May 23 19:40:38 2017 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 ABB011286D6; Tue, 23 May 2017 19:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.551 X-Spam-Level: X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7broaKFVaqt; Tue, 23 May 2017 19:40:35 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56C4C126CC4; Tue, 23 May 2017 19:40:35 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id k91so109451717ioi.1; Tue, 23 May 2017 19:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=OeQGzEgFI8rVyuAwgx88UqSr7uiXur1CMCO83xQ3fUg=; b=PCRnY7h2FO3oOYW1H5s4ELiYAyWkNBE9DEzg741MpfjF6La6ZFq6d93lDG5v4Vc083 cVcY/bRFFafbmIjIgGIttN8nehLLUYsxbqM8YMvYX0lHxiAyT8pEgNKXmUc4EH0qa1mx ABLEgCRN7VPqh8bYHiCOB2x1LSoSWIngSe5/dqWIou3sZ+UKuTOZOJMCkrckIybXBlV3 LjHaDhTQiTi6Ln2UnEFPgg/GaXr6IHOvPLqtQB9FAwoKCxOfUa3C76OAEBe7liQCSdFu CvjehbqdPRIYaNCuDZrJhBXDpWUiR82+V/lnEXUVQK06NYWc9aBHOS4BuiJL5Y4B4uM4 Im6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=OeQGzEgFI8rVyuAwgx88UqSr7uiXur1CMCO83xQ3fUg=; b=q+zfLM144Y7LNTbsxq9Lhpj4jg8DmRAhG77cQc0naBL5/5lofFOkxGXf6kFiMfHf0P l6OfjPqpSel99AVYz13S/M665gxyKzcj5/NWo1OPd/VEmAX8lh2rJKedFm41H1/Fz4zx BazHX1IaoleA9JHUnuA2QbPznpxoH4HYnHz9BFMuuAF8NpvDFV8ytNwk3ly1BBH0fRAn zO+h5JuyIhQhlpXExGWVsPxzUVAI2dZMWT/y0z2olzJlma2VUpoUAOUbo9Nm9bJgkhdL G7jfxJZFHEHrcgiiga4BlPVXcsEbHcG06PrWuTmIocUGMuthZjm9D0otQ6ikiaxJxDPS 2ADg== X-Gm-Message-State: AODbwcAEIoZhQYZBiF5Hv7ipTH1dcRFceDEiBg7vBcltWnMEADy5IkyX t2CIrTAcEpYaYw+X6Fn35uPnBgDIOQ== X-Received: by 10.107.161.206 with SMTP id k197mr10748535ioe.141.1495593634692; Tue, 23 May 2017 19:40:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.134.208 with HTTP; Tue, 23 May 2017 19:40:19 -0700 (PDT) From: Donald Eastlake Date: Tue, 23 May 2017 22:40:19 -0400 Message-ID: To: "iesg@ietf.org" , draft-ietf-oauth-native-apps.all@ietf.org Cc: "secdir@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [secdir] SECDIR review of draft-ietf-oauth-native-apps-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 02:40:37 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. The primary goal of this BCP draft is to specify that OAuth 2.0 authorization requests from native apps should only be made through external user agents, primarily the user's browser, as opposed to an embedded user-agent. Security Considerations This BCP is all at quite a high level. It talks about interprocess and world wide web interactions to effectuate OAuth 2.0, mechanisms with which I am not too familiar. But, all mechanism details are in other documents.. The recommendations seem reasonable and the beginning of the Security Considerations section paints a somewhat dismal security picture compared with that typical of cryptographic or protocol security. As best I can tell, it is ready with trivial nits as listed below. Minor SSO is used multiple times but never expanded. Trivial English Improvements Page 13, Section 8.8 "for native apps to include" -> "that native apps include" Page , Appendix B "in an generic manner" -> "in a generic manner" Page 19, Appendix B.4, 2nd paragraph Last word of first line and first word of second line are duplicates. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Tue May 23 23:19:23 2017 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 E1D20126E3A for ; Tue, 23 May 2017 23:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUDQGMgALZTQ for ; Tue, 23 May 2017 23:19:20 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91CC91204DA for ; Tue, 23 May 2017 23:19:20 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id h4so229212525oib.3 for ; Tue, 23 May 2017 23:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=DsoGaruAbHMte4hoZ4KJIsoamIVPqzf7CZAuYw8/wNU=; b=S6ypEiyc/10aiZkuXEe/2O4QFKg+lAO+eBh6YDF1n8nW9CybS+FlbhLJIgfP8RLRFI aehFFvh7aL67sMWN/jxj+7LBtnCM9E5KOse1aQ4VYii4U1mnMHgkGCNCkt1Impn8kTDD gnob9Wb6LB2igFK/By48m9Fqx+mUbWuCgQf91p4t6lGU3gvRo3Jn9Wg0mZSIIYkJTU0t i/KyGiv5NPKYH31Ars2jEnZ4t0igD+YrHva+vXbVlhvEC3dTXW5p2Xj88+A/AuZRs3tr 9nwNuusvb6hNtdN2fxNoNEmYKpAcOneV9VUbWzqQixT8NNltlsqqnZRvuUZhvzIkhGRy wl2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DsoGaruAbHMte4hoZ4KJIsoamIVPqzf7CZAuYw8/wNU=; b=RZbCrr4wQ8aJ8UdcyuP0oBfsQ3Jf9mX9kYV3p/FFWvIgkd+209Ea6JdtAnzLgdQo0y ug75hincwfYWUjCTKkngxmRi504jMbYMtlz0DfikckiMwOKEwaTgFHUDAJShm7piXVWZ rzn1BXgN+RUfyy0KbS15GUFhItvT/g8cPBf8KkUQnL6IRCsf1ZgE3DoNSDpcLQ+DMIHi YTeTJQnyMlyXCcyr2cPQw1aPLWb3IP8OQPVT4cIm9w6murALpqYuRqzw3eaivVZ0aXLN qr0+zGP+O5ESWs4QUaXZ1xKiNtDg/u7ufbUAzVmRS+4eA/LXwtT7Pt/f3H5RjWkXSX1m +RuQ== X-Gm-Message-State: AODbwcAPyuxsnV8Qkn/7JQsMIZZ/09MCztsSv2DgIo7/cJgpsMLkiscW UG3giXXtK0u27uv6r0dbCkj6rW/yXTnI7ds= X-Received: by 10.202.240.66 with SMTP id o63mr16127307oih.169.1495606759690; Tue, 23 May 2017 23:19:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.44.173 with HTTP; Tue, 23 May 2017 23:19:19 -0700 (PDT) From: Shawn Emery Date: Wed, 24 May 2017 00:19:19 -0600 Message-ID: To: secdir@ietf.org, draft-ietf-nfsv4-xattrs.all@tools.ietf.org Content-Type: multipart/alternative; boundary="94eb2c093cdaa2998105503f15bd" Archived-At: Subject: [secdir] Review of draft-ietf-nfsv4-xattrs-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 06:19:22 -0000 --94eb2c093cdaa2998105503f15bd 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 draft discusses extensions for file attributes in the NFSv4 protocol. The security considerations section does exist and states that file attribute extensions adds no new concerns than that of file data and named attributes. It defers to the security considerations of application data in NFSv4.2 (RFC 7862), which refers to NFSv4.1 (RFC 5661). 5661 discusses possible MITM and down-grade attacks and how to mitigate them with RPCSEC_GSS (integrity or privacy services). I agree with this assertion, though I'd rather have the draft reference 5661 directly or RFC 7530. General comments: None. Editorial comments: Section 7.1: the copyright should be updated. Shawn. -- --94eb2c093cdaa2998105503f15bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed this docu= ment as part of the security directorate's
ongoing effort to review all=C2= =A0IETF=C2=A0documents being processed by the IESG.
These comments were wri= tten 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 draft discusses extensions for fil= e attributes in the NFSv4 protocol.

The security considerations se= ction does exist and states that
file attribute extensions adds no new concerns than that of file data
and named attributes.=C2=A0 It defers to = the security considerations of application
data in NFSv4.2 (RFC 7862), which refers to NFSv4.1 (RFC=C2=A056= 61).
5661 discusses possi= ble MITM and down-grade attacks and how to
mitigate them with=C2=A0RPCSEC_GSS (integrity or priv= acy services).=C2=A0 I agree
with this assertion, though I'd rather have the draft reference 566= 1 directly
or RFC 7530.

General comments:

None.

Editorial comments:

Section 7.1: the copyri= ght should=C2=A0be updated.

Shawn.
--
--94eb2c093cdaa2998105503f15bd-- From nobody Thu May 25 04:56:02 2017 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 0E02612940B; Thu, 25 May 2017 04:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rcs-rds.ro 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 bZ69oG4WYTKo; Thu, 25 May 2017 04:55:51 -0700 (PDT) Received: from mailproxy1.rcs-rds.ro (mailproxy1.rcs-rds.ro [212.54.120.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183EA129493; Thu, 25 May 2017 04:55:50 -0700 (PDT) Received: from [10.172.5.198] (unknown [10.172.5.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailproxy1.rcs-rds.ro (Postfix) with ESMTPSA id 9B8A210000E; Thu, 25 May 2017 14:55:48 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rcs-rds.ro; s=MailProxy; t=1495713348; bh=IbamMC0nmweDv6HNZYtm1JH/j3H9mqp3uDY+FXCpbWE=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=kY4RGAZJRo6Uywhu9IbbohIjAwb6A6v3yqVZ0XeBVN4cZbYExLvGlAI4VZO3Acgea V1FNzbpQF0xhkWb76z4e6Hrbci6+/ogi57Tr4oRz7nKJkhCBfysEzEqL/U++KmWgG0 CKis1Iwxyz8qqCGY6/nW/2dr4A7NIZ8yLmeqVhBw= From: Marius Georgescu Message-Id: <8A2A6836-708B-47EB-BB91-9F998DC7B509@rcs-rds.ro> Content-Type: multipart/alternative; boundary="Apple-Mail=_1A3999AE-1F1C-4491-BF42-3AE38A834F14" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 25 May 2017 14:55:46 +0300 In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF25F9B349@njmtexg4.research.att.com> Cc: Taylor Yu , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-bmwg-ipv6-tran-tech-benchmarking.all@ietf.org" To: Alfred C Morton References: <4D7F4AD313D3FC43A053B309F97543CF25F96C2C@njmtexg4.research.att.com> <3AF9B659-1229-43F8-BA74-1B5526277391@rcs-rds.ro> <4D7F4AD313D3FC43A053B309F97543CF25F9B349@njmtexg4.research.att.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] secdir last call review of draft-ietf-bmwg-ipv6-tran-tech-benchmarking-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 11:55:54 -0000 --Apple-Mail=_1A3999AE-1F1C-4491-BF42-3AE38A834F14 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Taylor, Please see my answer inline. > On May 12, 2017, at 2:21 AM, MORTON, ALFRED C (AL) = wrote: >=20 > Hi Taylor, > please see in-line reply, thanks, > Al >=20 >> -----Original Message----- >> From: Taylor Yu [mailto:tlyu@mit.edu ] >> Sent: Thursday, May 11, 2017 6:55 PM >> To: Marius Georgescu >> Cc: MORTON, ALFRED C (AL); iesg@ietf.org ; = secdir@ietf.org ; draft-ietf- >> bmwg-ipv6-tran-tech-benchmarking.all@ietf.org = >> Subject: Re: secdir last call review of = draft-ietf-bmwg-ipv6-tran-tech- >> benchmarking-07.txt >>=20 >> Marius Georgescu writes: >>=20 >>>> On May 8, 2017, at 4:34 AM, Taylor Yu wrote: >>=20 >>>> I'm sorry, I guess I misinterpreted, then. Do you mean that the >>>> implementations tested in the benchmarking lab should not = materially >>>> differ from ones intended for production? As in the tested >>>> implementations should be have neither stronger nor weaker security >>>> properties than their deployed counterparts? I might be able to >> suggest >>>> improved wording if I understand your intentions correctly. >>=20 >>> Indeed, we meant that the implementations tested in the lab should = not >>> differ from the ones intended for production. >>=20 >> In that case, what do you think of the following change? >>=20 >> OLD >>=20 >> Further, benchmarking is performed on a "black-box" basis, relying >> solely on measurements observable external to the DUT/SUT. Special >> capabilities SHOULD NOT exist in the DUT/SUT specifically for >> benchmarking purposes. Any implications for network security = arising >> from the DUT/SUT SHOULD be identical in the lab and in production >> networks. >>=20 >> NEW >>=20 >> Further, benchmarking is performed on a "black-box" basis, relying >> solely on measurements observable external to the DUT. Special >> capabilities SHOULD NOT exist in the DUT specifically for >> benchmarking purposes. Testers and implementors SHOULD ensure that >> the DUT has identical security properties to its production = version. > [ACM]=20 > This new sentence has redundant effect with second sentence = (unchanged). > Furthermore, Testing personnel have no means to ensure the identical=20= > properties, and implementers may not yet have a production version = available > (Benchmarking often takes place with very early products, whose > non-tested aspects may change before reaching production). >=20 >> For example, any security hardening or instrumentation present on = the >> DUT SHOULD also be present in the production version, and vice = versa. > [ACM]=20 > Again, this cannot be ensured when it is not a tested feature,=20 > and there may be *many* (later) production releases that differ=20 > from the DUT. The example goes too far. >=20 > At this point, I feel it is appropriate to point out that BMWG has=20 > used the original wording of the paragraphs in this section for years > (~10), and their intent has been sufficiently clear to the community. [MG] I agree with Al, I personally don't see how the new text is = improving the old. I understand that it is important to consider the security features as a = potential parameter when testing, and that it should be isolated. However, I find the current text clear enough. Would you please elaborate on why it isn't from your perspective. Best regards, Marius --Apple-Mail=_1A3999AE-1F1C-4491-BF42-3AE38A834F14 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello Taylor,

Please see my answer inline.
On = May 12, 2017, at 2:21 AM, MORTON, ALFRED C (AL) <acmorton@att.com> = wrote:

Hi Taylor,
please see in-line reply, thanks,
Al

-----Original = Message-----
From: Taylor Yu [mailto:tlyu@mit.edu]
Sent: Thursday, May 11, 2017 6:55 PM
To: Marius = Georgescu
Cc: MORTON, ALFRED C (AL); iesg@ietf.org; secdir@ietf.org; = draft-ietf-
bmwg-ipv6-tran-tech-benchmarking.all@ietf.org
Subject: Re: secdir last call review of = draft-ietf-bmwg-ipv6-tran-tech-
benchmarking-07.txt

Marius Georgescu <marius.georgescu@rcs-rds.ro> writes:

On May 8, 2017, at 4:34 AM, Taylor Yu <tlyu@mit.edu> wrote:

I'm sorry, = I guess I misinterpreted, then.  Do you mean that the
implementations tested in the benchmarking lab should not = materially
differ from ones intended for production? =  As in the tested
implementations should be have = neither stronger nor weaker security
properties than their = deployed counterparts?  I might be able to
suggest
improved = wording if I understand your intentions correctly.

Indeed, we meant that the implementations = tested in the lab should not
differ from the ones intended = for production.

In that case, = what do you think of the following change?

OLD

  Further, = benchmarking is performed on a "black-box" basis, relying
  solely on measurements observable external to the = DUT/SUT. Special
  capabilities SHOULD NOT exist = in the DUT/SUT specifically for
  benchmarking = purposes. Any implications for network security arising
  from the DUT/SUT SHOULD be identical in the lab = and in production
  networks.

NEW

  Further, = benchmarking is performed on a "black-box" basis, relying
  solely on measurements observable external to the = DUT.  Special
  capabilities SHOULD NOT = exist in the DUT specifically for
  benchmarking = purposes.  Testers and implementors SHOULD ensure that
  the DUT has identical security properties to its = production version.
[ACM] 
This new sentence has redundant effect with = second sentence (unchanged).
Furthermore, Testing personnel = have no means to ensure the identical 
properties, and implementers may not yet have a = production version available
(Benchmarking often takes place = with very early products, whose
non-tested aspects may change = before reaching production).

  For example, any = security hardening or instrumentation present on the
  DUT SHOULD also be present in the production = version, and vice versa.
[ACM] 
Again, this cannot be ensured when it is not a = tested feature, 
and there may be *many* (later) production = releases that differ 
from the DUT. The example goes too = far.

At this point, I feel it is = appropriate to point out that BMWG has 
used the original wording of the paragraphs in = this section for years
(~10), and their intent has been = sufficiently clear to the community.

[MG] I agree with Al, I = personally don't see how the new text is improving the old.
I = understand that it is important to consider the security features as a = potential parameter when testing, and that it should be = isolated.
However, I find the current text clear = enough.
Would you please elaborate on why it isn't from your = perspective.

Best = regards,
Marius

= --Apple-Mail=_1A3999AE-1F1C-4491-BF42-3AE38A834F14-- From nobody Thu May 25 06:48:16 2017 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 52F6B129AAD; Thu, 25 May 2017 06:48:07 -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, 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 eBulgv9VsswQ; Thu, 25 May 2017 06:48:04 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 6B57A129AAA; Thu, 25 May 2017 06:48:04 -0700 (PDT) Received: from [192.168.20.72] (CPEf4cc552207f0-CM00fc8dce0fa0.cpe.net.cable.rogers.com [99.230.129.191]) by mail.networkradius.com (Postfix) with ESMTPSA id EF714AF; Thu, 25 May 2017 13:48:02 +0000 (UTC) From: Alan DeKok Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1FDB6D3F-5885-47DA-A3D8-E26171B66DF7@deployingradius.com> Date: Thu, 25 May 2017 09:48:00 -0400 To: draft-nottingham-rfc5988bis-05.all@ietf.org, IESG , secdir@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [secdir] SECDIR review of draft-nottingham-rfc5988bis X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 13:48:07 -0000 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.=20 This document describes a model for indicating relationship between = resources on the web. It largely describes concepts, with some "on the = wire" specification. This document is Ready with NITs Section 2 says: ... the relative ordering of links in any particular serialisation, or between serialisations (e.g., the Link header field and in-content links) is not specified or significant in this specification; applications that wish to consider ordering significant can do so. I'm not sure about the impact of the last statement in that sentence. = If ordering is not significant, why would applications consider it to be = significant? What does that mean to the application, and how does that = affect this standard? Section 2 says: Finally, links are consumed by _link applications_. NIT: I'm not sure what "consumed" means here. Perhaps "interpreted" = would be better? Section 2.1.1 says: Registered relation type names MUST conform to the reg-rel-type rule (see Section 3.3), and MUST be compared character-by-character in a case-insensitive fashion. =20 Question: are there any restrictions on the encodings of the strings? = I.e. are they ASCII? Or UTF-8? Having spent some time trying to to i18n in historical protocols, I'm = wary of statements which require case-insensitive string matching with = no further qualification. Similar comments apply to Section 2.1.2. Section 2.1.1 says: ... This practice is NOT RECOMMENDED, because the resulting strings will not be considered equivalent to the registered relation types by other processors. NIT: this is the only use of "processors" I can find in the document. I = suggest replacing it with a term used by the rest of the document. Section 2.1.1.1 says: Registration requests consist of at least the following information: o *Relation Name*: The name of the relation type Question: is this an English name? The "Description" field states that = it is a "shot English description" Should the name generally be lowercase? Uppercase? Mixed case? If the name does not follow existing practices, can the Expert Review = suggest changes? And for the string comparisons, is this ASCII? UTF-8? Some guidance = would be appreciated. Section 2.1.1.2 says: The goal of the registry is to reflect common use of links on the Internet. Therefore, the Expert(s) SHOULD be strongly biased towards approving registrations, unless they are abusive, frivolous, not likely to be used on the Internet, or actively harmful to the Internet and/or the Web (not merely aesthetically displeasing, or architecturally dubious).=20 Question: how are these determinations to be made? Is there any = guidance? How can a "Relation name" or "reference" be "abusive", or "actively = harmful" ? Section 5 says: The content of the Link header field is not secure, private or integrity-guaranteed, and due caution should be exercised when using it. Use of Transport Layer Security (TLS) with HTTP ([RFC2818] and [RFC2817]) is currently the only end-to-end way to provide such protection. Question: Is there guidance on what other applications should do with = the links? Link applications ought to consider the attack vectors opened by automatically following, trusting, or otherwise using links gathered from HTTP headers. In particular, Link header fields that use the "anchor" parameter to associate a link's context with another resource are to be treated with due caution. Question: what is "due caution"? I'd also suggest that *parsing* links is a hard problem, as parsing is = (in general) a source of many security issues. For examples, see: = http://blog.checkpoint.com/2017/05/23/hacked-in-translation/ Where malicious subtitles can result in video players being = compromised. The Link header field makes extensive use of IRIs and URIs. See [RFC3987] for security considerations relating to IRIs. See [RFC3986] for security considerations relating to URIs. See [RFC7230] for security considerations relating to HTTP headers. NIT: I suggest referencing the "Security Considerations" sections = directly, instead of just referring to the entire document.= From nobody Fri May 26 01:48:50 2017 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 3C3711286D6 for ; Fri, 26 May 2017 01:48:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <149578852924.8673.16063870926976914350.idtracker@ietfa.amsl.com> Date: Fri, 26 May 2017 01:48:49 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 08:48:49 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-06-08 Reviewer LC end Draft Daniel Franke 2017-05-15 draft-ietf-bmwg-vswitch-opnfv-03 Daniel Gillmor 2017-05-14 draft-ietf-netmod-yang-model-classification-07 Tobias Gondrom 2017-05-14 draft-ietf-calext-caldav-attachments-02 Takeshi Takahashi R2017-05-02 draft-ietf-grow-bgp-reject-07 For telechat 2017-06-22 Reviewer LC end Draft Stephen Kent 2017-06-15 draft-jones-cose-rsa-03 For telechat 2017-07-06 Reviewer LC end Draft Scott Kelly None draft-turner-est-extensions-08 Last calls: Reviewer LC end Draft Charlie Kaufman 2017-05-28 draft-ietf-curdle-cms-ecdh-new-curves-07 Tero Kivinen 2017-06-08 draft-ietf-avtext-lrr-05 Watson Ladd 2017-06-06 draft-ietf-v6ops-unique-ipv6-prefix-per-host-03 Ben Laurie 2017-06-05 draft-ietf-v6ops-v4v6-xlat-prefix-01 Barry Leiba 2017-06-05 draft-ietf-sacm-requirements-15 Chris Lonvick 2017-06-01 draft-ietf-sipcore-name-addr-guidance-01 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-08 Dacheng Zhang 2017-05-04 draft-ietf-spring-resiliency-use-cases-11 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Next in the reviewer rotation: David Mandelberg Catherine Meadows Alexey Melnikov Matthew Miller Adam Montville Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom Hilarie Orman From nobody Fri May 26 09:01:02 2017 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 3F3D31296B3; Fri, 26 May 2017 09:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 OF2CSu1837Mu; Fri, 26 May 2017 09:00:52 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (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 A624612EA5A; Fri, 26 May 2017 09:00:52 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id 130so3303809ybl.3; Fri, 26 May 2017 09:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wwa+S03nNCYOF2RPvOLaLui+JhjJeCZusKEBQtTujRs=; b=sjZvO0AGQXybvwOtI5GjPqqn92o2aXKdrb1HYPSVgsQjENsIIhKjVLolGfzG93NoBd t+t30yUT8BznYMjcLsSFGN38Ptv1hUyIHk48JsgOyDq1P8Pt/B85qizM8UrkYlDcwfAm V7NTpdCA0w/H77k39Vwu5lyw0ml7r9xRZ8oz0f6ba6xCkJ7GMYbTk7bbvDXiYh3mVAAX MeUPnEJcaS2N8ENTjwVGB7S1TQd6BZ7ow/8sNbNu9WikCLFGFMRs49lKRFmjv9g51PP3 sjz0truRQ8M8RUeoUK72yCOudqK7fCdTFMkYwn2jXnfK4dsydIruoTd4o50+jkID3VZx iwPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wwa+S03nNCYOF2RPvOLaLui+JhjJeCZusKEBQtTujRs=; b=dfj6OL1ly5J67+1HxdWv6IL5kJS+7x569r1eyX1+1jBczT+kxi0lUctMT15ZHIQ4Zh nvDgShZQErPJY+V18qPK/zeS6aann5lFPJU9ivLNFQzjcMCCXMStaiDZTuvs/SrzaBTI l/Ir8pn4bXufbU+lyUFtJvfo1aZ7oA8VO2F5ZoZsBN7nfRwdcJ0OFRoeRE5VEMDbm/EQ dClf729+7g1V02A2V5sFi/yUAVPO1G0P67A6YOLWss2IAfFwYfffmoOgZorRg6LGhYPx y0yjl/YEccQRPSgZc3mGuCXyIvB0bI5JkcTsJ1beEGE4zw2i1wmGsqxXyQEjzol0o6vc oGoA== X-Gm-Message-State: AODbwcA+fo0gQq2rkzqSqrdPAvj6dBKaEhYXjaByUMKq332Xm5yaoE2A LigLSa40kgh25xb2SKIlqtHEGVb50A== X-Received: by 10.37.184.10 with SMTP id v10mr32644977ybj.82.1495814451837; Fri, 26 May 2017 09:00:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.195.194 with HTTP; Fri, 26 May 2017 09:00:51 -0700 (PDT) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Fri, 26 May 2017 12:00:51 -0400 Message-ID: To: Phillip Hallam-Baker Cc: "secdir@ietf.org" , draft-ietf-nfsv4-umask.all@ietf.org, IETF Discussion Mailing List , NFSv4 Content-Type: multipart/alternative; boundary="089e0822e59c0d5b5e05506f719c" Archived-At: Subject: Re: [secdir] SECDIR Review of draft-ietf-nfsv4-umask-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 16:00:54 -0000 --089e0822e59c0d5b5e05506f719c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Phillip, (adding the NFSv4 working group mailing list, because the issue you raised in this review is relevant to pretty much all of NFSv4) On Thu, May 18, 2017 at 12:10 PM, Phillip Hallam-Baker < phill@hallambaker.com> wrote: > Reviewer: > =E2=80=8BPhillip Hallam-Baker > > Review result: > =E2=80=8BOK but...=E2=80=8B > > > 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: Review of draft-ietf-nfsv4-umask-03 > Reviewer: > =E2=80=8BPhillip Hallam-Baker > > > > Review result: > =E2=80=8BOK but...=E2=80=8B > > > This particular draft looks OK to me. Aligning the semantics of NFS with > the semantics of the file system seems to me to be absolutely the way to = go > forward. I am not sufficiently experienced in the semantics of NFS or Uni= x > as deployed to be able to offer an opinion on whether the draft achieves > that. However it appears that the author does. > > =E2=80=8BWhat is problematic here is that the Security Considerations in = the draft > are essentially relying on those in rfc7530 which are woefully inadequate > given the critical role of NFS in Internet security. They are not so much= a > security plan as a collection of random thoughts jotted down in haphazard > fashion.=E2=80=8B > > There is clearly no coherent model of what NFS security should achieve, > what the threats are, what controls are deployed to control them. Also no= te > that the main reason this review is late is that I have been dealing with > issues arising from WannaCry which used an SMB:1 exploit. Re-reading > RFC7530 in the light of that experience gives me grave concern. > This is very interesting ... Speaking as the responsible AD, I'm thinking that the right thing to do, is for me to ask the NFSv4 working group to consider the issue you're raising, with the high-order bit question being whether it's time to revisit NFS security. The working group is actively discussing a recharter, likely to be discussed in Prague, so it's the right time to ask the question. Given that RFC 7530 is the umbrella RFC for all of NFSv4, I'm thinking that's the right place to fix anything that needs fixing. And thanks for your review. Spencer --089e0822e59c0d5b5e05506f719c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Phillip,

(adding the NFSv4 working = group mailing list, because the issue you raised in this review is relevant= to pretty much all of NFSv4)

On Thu, May 18, 2017 at 12:10 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
Reviewer:=C2=A0
=E2=80=8BPhillip Hallam-Baker

Review result:=C2= =A0
=E2=80=8BOK but...=E2=80= =8B


I reviewed this document as part of the= Security Directorate's
ongoing
effort to review all IETF documents being process= ed by the IESG.
These
comments were written primarily for the benefit of the Security= Area
Directors.=C2=A0 Document authors, document editors, and WG chairs should<= /span>
treat= these comments just like any other IETF Last Call comments.

Document:=C2=A0Review of draft-ietf-nfsv4-umask-03
Reviewer:
=E2=80=8BPhillip Hallam-Baker
<= /span>


Review result:=C2= =A0
=E2=80=8BOK but...=E2=80=8B

This particular draft looks OK to me. Aligning the semantics o= f NFS with the semantics of the file system seems to me to be absolutely th= e way to go forward. I am not sufficiently experienced in the semantics of = NFS or Unix as deployed to be able to offer an opinion on whether the draft= achieves that. However it appears that the author does.

=E2=80=8BWhat is problematic here is that the Security Considerations = in the draft are essentially relying on those in rfc7530 which are woefully= inadequate given the critical role of NFS in Internet security. They are n= ot so much a security plan as a collection of random thoughts jotted down i= n haphazard fashion.=E2=80=8B

There is clearly no coherent model of what NFS security should achieve= , what the threats are, what controls are deployed to control them. Also no= te that the main reason this review is late is that I have been dealing wit= h issues arising from WannaCry which used an SMB:1 exploit. Re-reading RFC7= 530 in the light of that experience gives me grave concern.

This is very interesting ...
<= br>
Speaking as the responsible AD, I'm thinking that the rig= ht thing to do, is for me to ask the NFSv4 working group to consider the is= sue you're raising, with the high-order bit question being whether it&#= 39;s time to revisit NFS security. The working group is actively discussing= a recharter, likely to be discussed in Prague, so it's the right time = to ask the question.

Given that RFC 7530 is the um= brella RFC for all of NFSv4, I'm thinking that's the right place to= fix anything that needs fixing.

And thanks for yo= ur review.

Spencer=C2=A0
--089e0822e59c0d5b5e05506f719c-- From nobody Fri May 26 09:04:46 2017 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 E9D8B129AF2 for ; Fri, 26 May 2017 08:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 F_C8e_POLngE for ; Fri, 26 May 2017 08:56:22 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (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 5C7C912EA5A for ; Fri, 26 May 2017 08:56:15 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id 9so15273756pfj.1 for ; Fri, 26 May 2017 08:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=cK7Hgl6olih2ijpF4UTTvVu6yIKGEZ5nKjPlGPcI5GU=; b=fUYLaZ1mGMnnkoaDeCnA6sxkDR0NNs4VNmFZYjvT5jz0cljrfJQ5pIFzF9BooGjrIP sYbOGVIRflKqTZgy/MW/JyrWxuONKGptiKecyyaNEfS6Z9ioABgX5rgHMHuMlsdIjaDA N3PbuZdCiGBv/ePA7hwpbP2Z/ezrO6qmfQtznnU/WdxobHprTOVQRyys7Bv4JCBz1NjC GCN45iE6ml1BpZBOz/a1j1K4/u1ya4poRVNPOX3D3s5ttF+qsgcZXjdcWaNht9xUTxiA SOwzNNSHAxZ1tPNd7ejdz5i2C7DLNSg5n1WOmWu71tDnq7R3f4cpBfBagUFVhl9EDfvR XsEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=cK7Hgl6olih2ijpF4UTTvVu6yIKGEZ5nKjPlGPcI5GU=; b=cc9S/KPTL1NTH7khG0Dzub21g7GdwhUV+wwu8RWNp3Lw6YHx2qhWAezASNwFMpuwh4 RBw1tWmeH9cYrWuY8LkNfRpvIpEZPlNdr0kwi60KpEMQg0bvZuthLacb3C18oquYi+ST A+UvGfvWhhhrQWgbCj/uDP+5KSEle+UzAHVevV2M6pra72JIxrhcp/Iioc+iCI4LYicG F0fBld086XKieB5TT1vkON/pLYkoWH0agCQWupH6O+wLRTX09W63oC+jwbCO3J0QVhnU v0DpCg5ppfitd41ixTz5yatNP7EObOyR6TFhItdLp/5qrAbo8yqy/Bh/zL++Dl1PYNPT 8Wig== X-Gm-Message-State: AODbwcCkH/ZcebO36zw10ky50MnJuTSj62wlsJyyImeRbwHyh/bGPREv vMEjUEcDmtAPnMsEHYLO68iB2G/sQg== X-Received: by 10.84.193.129 with SMTP id f1mr59381746pld.129.1495814174986; Fri, 26 May 2017 08:56:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.135 with HTTP; Fri, 26 May 2017 08:55:34 -0700 (PDT) In-Reply-To: <149577630701.8724.2136766192406951320.idtracker@ietfa.amsl.com> References: <149577630701.8724.2136766192406951320.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Fri, 26 May 2017 11:55:34 -0400 Message-ID: To: "saag@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Fri, 26 May 2017 09:04:44 -0700 Subject: [secdir] Fwd: NomCom 2017-2018 Call for Volunteers X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 15:56:24 -0000 Please consider volunteering for NomCom this cycle, see the message below. My term is up next year and I am in process of deciding if I will volunteer again. Whether or not I do put my name in the hat, it is important for the NomCom to have a good pool of candidates to select from this year. Please also consider volunteering for Sec AD. EKR and I, as well as prior ADs would be more than happy to chat with anyone interested about the position. Best regards, Kathleen ---------- Forwarded message ---------- From: NomCom Chair 2017 Date: Fri, May 26, 2017 at 1:25 AM Subject: NomCom 2017-2018 Call for Volunteers To: IETF Announcement List Cc: ietf@ietf.org The IETF NomCom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the NomCom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the NomCom can be found in RFC 7437 (BCP 10), and RFC 3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 7437, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are: IETF =3D 94 (Yokohama) \ 95 (Buenos Aires) \ 96 (Berlin) -*** ANY THREE! 97 (Seoul) / 98 (Chicago) / You can check your eligibility at: https://www.ietf.org/registration/nomcom= .py If you qualify, please volunteer. Before you decide to volunteer, please remember that anyone appointed to this NomCom will not be considered as a candidate for any of the positions that the 2017 - 2018 NomCom is responsible for filling. Many people have already volunteered by ticking the box on the IETF 98 registration form. Once these people have been verified as eligible, I will contact all of them shortly. Thank you for volunteering! The list of people and posts whose terms end with the March 2018 IETF meeting, and thus the positions for which this NomCom is responsible, are IAOC: Leslie Daigle IAB: Ted Hardie Joe Hildebrand Lee Howard Erik Nordmark Martin Thomson Brian Trammell IESG: Alia Atlas (RTG) Benoit Claise (OPS) Suresh Krishnan (INT) Mirja K=C3=BChlewind (TSV) Alexey Melnikov (ART) Kathleen Moriarty (SEC) All appointments are for 2 years. The ART and Routing areas have 3 ADs and the General area has 1; all other areas have 2 ADs. Thus, all areas have at least one continuing AD. The primary activity for this NomCom will begin in July 2017 and should be completed in January 2018. The NomCom will have regularly scheduled conference calls to ensure progress. There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. While being a NomCom member does require some time commitment it is also a very rewarding experience. As a member of the NomCom it is very important that you be able to attend IETF 100 (Singapore) to conduct interviews. Being at IETF 99 (Prague) is useful for orientation. Being at IETF 101 (London) is not essential. Please volunteer by sending me an email before 23:59 UTC June 26, 2017, as follows: To: nomcom-chair-2017 at ietf dot org Subject: NomCom 2017-18 Volunteer Please include the following information in the email body: Your Full Name: __________ // as you write it on the IETF registration form Current Primary Affiliation: // Typically what goes in the Company field // in the IETF Registration Form Emails: _______________ // All email addresses used to register for the past 5 IETF meetings // Preferred email address first Telephone: _______________________ // For confirmation if selected You should expect an email response from me within 5 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that NomCom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the NomCom is a great way to contribute to the IETF! You can find a detailed timeline on the NomCom web site at: https://datatracker.ietf.org/nomcom/2017/ I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next few weeks. Thank you! Peter Yee peter at akayla dot com nomcom-chair-2017 at ietf dot org --=20 Best regards, Kathleen From nobody Fri May 26 17:27:14 2017 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 F2C2D129447; Fri, 26 May 2017 17:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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=outlook.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 hvVVTW2uHRKj; Fri, 26 May 2017 17:27:11 -0700 (PDT) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-co1nam05olkn0822.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe50::822]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FB8F128B93; Fri, 26 May 2017 17:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PbcxgwHgGz6U1kDLe4UVKZkjOgtFPKSadoTcc1oRgcM=; b=JR7nxcefmwH0nLc+FNtpb4C9GHKccGe9gcYjWvkC1WWkP6UxMiWM7jGCFBbBn5zSpeKPza+DxfWzBj0DNTGzesdPoSEc6S7xDYEJYlMvDubfb9Qo13VRil4qi0D0HJBPjL+3M0LHleNAQaiEi/avZFfqGKryeydHTQRrl3Q+EXhXPuUUxkSBGRVO47H2BB+FzWrP8PviUuWBklKLpLDEXrq3krjRVMwq15rptYcjM57J3MH93r5BvqFfLwEQPnwu36tJrfUhEPmgz2cV3B3dYzUFg4HiXT+2y3m9h0GN95JT1yfO1cbBcvgjeb+nWI/jOcspViRHVA/+yCMOXMC6Lg== Received: from CO1NAM05FT062.eop-nam05.prod.protection.outlook.com (10.152.96.53) by CO1NAM05HT026.eop-nam05.prod.protection.outlook.com (10.152.96.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.12; Sat, 27 May 2017 00:26:55 +0000 Received: from CY4PR17MB1559.namprd17.prod.outlook.com (10.152.96.53) by CO1NAM05FT062.mail.protection.outlook.com (10.152.96.180) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.12 via Frontend Transport; Sat, 27 May 2017 00:26:54 +0000 Received: from CY4PR17MB1559.namprd17.prod.outlook.com ([10.173.63.8]) by CY4PR17MB1559.namprd17.prod.outlook.com ([10.173.63.8]) with mapi id 15.01.1124.013; Sat, 27 May 2017 00:26:54 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-curdle-cms-ecdh-new-curves.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-curdle-cms-ecdh-new-curves-07 Thread-Index: AQHS1n4QYaBxX5txmEqTemQ5uNeXtA== Date: Sat, 27 May 2017 00:26:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=outlook.com; x-incomingtopheadermarker: OriginalChecksum:FCB5137996B8F92EBBF32A8383642CD97AD42D8A04A5D1C645401A28ECB5B8A3; UpperCasedChecksum:F826EC2513747ED42FAB8B6549656D7F5D87F56D51A44100CC7C3A13B063023B; SizeAsReceived:8287; Count:43 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [PnelY7MeZsfw5bmCBY+YYwHPuusEZXoPsYn0FtXCFnBEHA9DUKvX+w==] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO1NAM05HT026; 5:E1eOyHlqs5tVAy6KpgjFOkrQ9mQ6G/MH+d25MfIAUpVGjtxq0gcDxRQczxO0tRm0NfY0fc74HQbQ0cZxzhqYDO4XWHtRmc3LAvVANlIWHwS6bczgWgrAW7H4jZ7CL1Bn7V9Rm4Qtpj/fTwtbCOwHhg==; 24:xfLQgUnu2Xx/2xeSrpfJKthO1U2Tiy+lmOuhE8JQsVk6crT8N8PELI2DbWZt+u5JKDS2xmFVgjeHpigutTaZJOwp3w/T9J+NK3G7m1e8Lm0=; 7:rZTEAgkBAmMnGGJ+PlqLoZLmhrsf85wm2zdjyP9cJbZPhzuHkGfNKZJtBtRqxhiQERGdLoPi2RNcA+RxJWIJHc0P8Aqh/dmxgQj+BMNxooFWj6a2YbvpwoNKU8TA2UdH4yNkYnaF/Ttu8bOlPTL0wPptQAihTPiI4mdhnMbCw7gBGE1vgHi8g1V+1YzZ544+F9Zeq8pPvMJccwtKl3NIIsZ/tZSi1vnCwEA5Q+SeieyrDYLg/frLinQVPP733eE62ITS8KWbqg8z8xN8krFurbTLfiueOfy+wc44/8EeR1ZKGr0mmT2BVyleX8hgkRfW x-incomingheadercount: 43 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:CO1NAM05HT026; H:CY4PR17MB1559.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:; x-ms-office365-filtering-correlation-id: 62b49452-f443-4187-8383-08d4a49713fd x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1601125374)(1603101448)(1701031045); SRVR:CO1NAM05HT026; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:CO1NAM05HT026; BCL:0; PCL:0; RULEID:; SRVR:CO1NAM05HT026; x-forefront-prvs: 0320B28BE1 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR17MB155963DE817AD76F7713B15CDFFD0CY4PR17MB1559namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2017 00:26:54.6769 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM05HT026 Archived-At: Subject: [secdir] secdir review of draft-ietf-curdle-cms-ecdh-new-curves-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 00:27:13 -0000 --_000_CY4PR17MB155963DE817AD76F7713B15CDFFD0CY4PR17MB1559namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. Document = editors and WG chairs should treat these comments just like any other last = call comments. This document specifies the syntactic details for encrypting and signing CM= S documents using two additional cryptographic algorithms. This syntax appe= ars consistent with the patterns set in RFC 5652, and I could find no error= s (even nits). Unless other more critical eyes than mine can find issues, I believe this d= ocument is ready to be advanced. My only complaint - and it is probably not with this document - is that it = should not take 16 pages to specify a handful of IANA registrations. I'm no= t sure why it was necessary, but my guess is that RFC 5652 was not forward = looking enough to allow the use of future algorithms to be specified with j= ust a few table entries, so subsequent documents have to include lots of in= formation duplicating one another. But that is not a criticism of the techn= ical content. --_000_CY4PR17MB155963DE817AD76F7713B15CDFFD0CY4PR17MB1559namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the security directorate'= s ongoing effort to review all IETF documents being processed by the IESG. = Document editors and WG chairs should treat these comments just like any ot= her last call comments.


This document specifies the syntactic details for encrypting and signing= CMS documents using two additional cryptographic algorithms. This syntax a= ppears consistent with the patterns set in RFC 5652, and I could find no er= rors (even nits).


Unless other more critical eyes than mine can find issues, I believe thi= s document is ready to be advanced.


My only complaint - and it is probably not with this document - is that = it should not take 16 pages to specify a handful of IANA registrations. I'm= not sure why it was necessary, but my guess is that RFC 5652 was not forwa= rd looking enough to allow the use of future algorithms to be specified with just a few table entries, so sub= sequent documents have to include lots of information duplicating one anoth= er. But that is not a criticism of the technical content.


 

--_000_CY4PR17MB155963DE817AD76F7713B15CDFFD0CY4PR17MB1559namp_-- From nobody Fri May 26 18:30:09 2017 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 71FED129411; Fri, 26 May 2017 18:30:07 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 0JUeTPOUoa8v; Fri, 26 May 2017 18:30:05 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 9824212940F; Fri, 26 May 2017 18:30:05 -0700 (PDT) X-AuditID: c6180641-361ff700000037f2-1c-5928903be5a8 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 07.78.14322.B3098295; Fri, 26 May 2017 22:29:50 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0339.000; Fri, 26 May 2017 21:30:00 -0400 From: Daniel Migault To: Charlie Kaufman , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-curdle-cms-ecdh-new-curves.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-curdle-cms-ecdh-new-curves-07 Thread-Index: AQHS1n4QYaBxX5txmEqTemQ5uNeXtKIHY1Aw Date: Sat, 27 May 2017 01:29:59 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118C6DB0D@eusaamb107.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_2DD56D786E600F45AC6BDE7DA4E8A8C118C6DB0Deusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZXLonQddugkakwYavShbTfp9gsTjU8o/N YsaficwWHxY+ZHFg8Viy5CeTx+bXL5g9vlz+zBbAHMVlk5Kak1mWWqRvl8CV0bP7AltBv0HF jjvGDYwHNbsYOTkkBEwkVu/oZO1i5OIQEjjKKNF+6xkThLOcUeLsks3sIFVsAkYSbYf62UES IgKfGSVWTvnIApIQFnCTaLq7GMwWEXCXmLR7DiuEbSRxe8YpMJtFQFWi78YJJhCbV8BXYvOs SYwgtpBAjMScFT/BbE6BWIlXNxrBbEYBMYnvp9aA1TMLiEvcejKfCeJUAYkle84zQ9iiEi8f /2OFsJUk5ry+xgxRny9xvnMuI8QuQYmTM5+wTGAUnoVk1CwkZbOQlEHEdSQW7P7EBmFrSyxb +JoZxj5z4DETsvgCRvZVjBylxQU5uelGhpsYgVF0TILNcQfj3l7PQ4wCHIxKPLzCORqRQqyJ ZcWVuYcYJTiYlUR47S4BhXhTEiurUovy44tKc1KLDzFKc7AoifO+K78QISSQnliSmp2aWpBa BJNl4uCUamBceE02kPt8WIMBn9SLZfukVh6sOayslpc666nlzkKGH/k9StOOlzYXzGQ6MinC 5LeOUGPKzlib57onfLama2/XsTspGrnVdY6Azt1cOc3IxsavvzecX7r7Favgzsiv9VvLOmL2 PNQ9/XL57fiPv+sdVxiUmyd2eTh4ybd/za4NEpaev/jZnKVKLMUZiYZazEXFiQDtPzl8ngIA AA== Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-curdle-cms-ecdh-new-curves-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 01:30:07 -0000 --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118C6DB0Deusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks you Charlie for your review. Yours, Daniel From: secdir [mailto:secdir-bounces@ietf.org] On Behalf Of Charlie Kaufman Sent: Friday, May 26, 2017 8:27 PM To: secdir@ietf.org; iesg@ietf.org; draft-ietf-curdle-cms-ecdh-new-curves.a= ll@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-curdle-cms-ecdh-new-curves-07 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. Document = editors and WG chairs should treat these comments just like any other last = call comments. This document specifies the syntactic details for encrypting and signing CM= S documents using two additional cryptographic algorithms. This syntax appe= ars consistent with the patterns set in RFC 5652, and I could find no error= s (even nits). Unless other more critical eyes than mine can find issues, I believe this d= ocument is ready to be advanced. My only complaint - and it is probably not with this document - is that it = should not take 16 pages to specify a handful of IANA registrations. I'm no= t sure why it was necessary, but my guess is that RFC 5652 was not forward = looking enough to allow the use of future algorithms to be specified with j= ust a few table entries, so subsequent documents have to include lots of in= formation duplicating one another. But that is not a criticism of the techn= ical content. --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118C6DB0Deusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks you Charlie for your review.

Yours,
Daniel

 

From: secdir [mailto:secdir-bounces@ietf.org]= On Behalf Of Charlie Kaufman
Sent: Friday, May 26, 2017 8:27 PM
To: secdir@ietf.org; iesg@ietf.org; draft-ietf-curdle-cms-ecdh-new-c= urves.all@tools.ietf.org
Subject: [secdir] secdir review of draft-ietf-curdle-cms-ecdh-new-cu= rves-07

 

I have reviewed this docume= nt as part of the security directorate's ongoing effort to review all IETF = documents being processed by the IESG. Document editors and WG chairs shoul= d treat these comments just like any other last call comments.

 

This document specifies the= syntactic details for encrypting and signing CMS documents using two addit= ional cryptographic algorithms. This syntax appears consistent with the pat= terns set in RFC 5652, and I could find no errors (even nits).

 

Unless other more critical = eyes than mine can find issues, I believe this document is ready to be adva= nced.

 

My only complaint - and it = is probably not with this document - is that it should not take 16 pages to= specify a handful of IANA registrations. I'm not sure why it was necessary= , but my guess is that RFC 5652 was not forward looking enough to allow the use of future algorithms to be spe= cified with just a few table entries, so subsequent documents have to inclu= de lots of information duplicating one another. But that is not a criticism= of the technical content.


 

--_000_2DD56D786E600F45AC6BDE7DA4E8A8C118C6DB0Deusaamb107erics_-- From nobody Sat May 27 14:19:42 2017 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 DC219124D85; Sat, 27 May 2017 14:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrSDm53VWvPA; Sat, 27 May 2017 14:19:39 -0700 (PDT) Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (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 35B80126BF3; Sat, 27 May 2017 14:19:38 -0700 (PDT) Received: by mail-oi0-x241.google.com with SMTP id w138so6663019oiw.3; Sat, 27 May 2017 14:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=TuS6stFCXSUW4GV4fPcSKIliKozEI7/4K0ASFTaNnlE=; b=WIEsnxv2bIw8cn9HgeePicgWginQLVQ6RBU8m4PoVQAC8/FAJWSPuBTUZpPMoGIDrw rJ3/n2C4gAYtLig0iDN9DsWHJI1y2i2aoGknEVBs0JAzek+nZqElwnM9Ncb3BGFtFufS jD1vLw0++4+MlbHrZVdYiwE9qK2RpvbqUXTzQmPqhN5lXVWKeaASSg2Y4QnKH+8SdhBz +FdqzlzL3aJdb5xmz5ILKnOibTEczqjYSIiSkvKidLcijsq0svnsKWgfrs6JEflwuGXz kpvkhBhPXV3DRHBAt5Ecgs/NEW5U93QeT7/Akk3HeQIYj9w/wUe31ctwbCht0slGAccU uxAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=TuS6stFCXSUW4GV4fPcSKIliKozEI7/4K0ASFTaNnlE=; b=AbxvsE5Dtv1IkcLu/zR8lGoU+Nwb0F5i8LcdGpUSbWYmkf3oZrjWBHXRwsaVjecEKM 8l80p3WaQRQ9euIByD2GtvgVS3esGOLsJYFd6MnPI4JgaOeB0SvZHdtVUYKy1UIgefp+ A4mApHFx+evFtEuryF6fE9huuiLQGYJnjTPsTNM/xJFIBYRNOsi8dA9ggS8dmlwe1iWo v3WXaPd5/zrYN6HzdqJ3VrJj0jOYulCOSe68qA+9AC9Z14Nl4kzTzGDcopQXQFXCen9z 2mvBDPjochosT5amU/qhZ2+WI7rJoIUNhseMGRGNSKwrf4AQ4Lvrq8TN/EuiAsC5N8kB zIPA== X-Gm-Message-State: AODbwcB4gHVEqqyVr8HCaE8cWp5DGxLLClqoWScosspyAIDAUE+uwt2x kfL8swaStP8IuN54 X-Received: by 10.202.214.18 with SMTP id n18mr4069157oig.27.1495919978259; Sat, 27 May 2017 14:19:38 -0700 (PDT) Received: from Chriss-Air.attlocal.net ([2602:306:838b:1c40:dd90:7465:c43f:a14c]) by smtp.googlemail.com with ESMTPSA id q35sm1102114ota.20.2017.05.27.14.19.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 May 2017 14:19:37 -0700 (PDT) To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-sipcore-name-addr-guidance.all@ietf.org From: Chris Lonvick Message-ID: <5929ED68.60203@gmail.com> Date: Sat, 27 May 2017 16:19:36 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------040007040008040100020504" Archived-At: Subject: [secdir] SECDIR review of draft-ietf-sipcore-name-addr-guidance X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 21:19:41 -0000 This is a multi-part message in MIME format. --------------040007040008040100020504 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, 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 updatesRFC3261 to state the constraint generically, and clarifies that the constraint applies to all SIP header fields where there is a choice between using name-addr or addr-spec. It also updates the RFCs that define extension SIP header fields using the alternative to clarify that the constraint applies (RFCs 3325, 3515, 3892, 4508, 5002, 5318, 5360, and 5502). The document is READY. It is well written, to the point, and I found no nits. Thanks, Chris --------------040007040008040100020504 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi,

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 updates RFC3261 to state the constraint generically,
   and clarifies that the constraint applies to all SIP header fields
   where there is a choice between using name-addr or addr-spec.  It
   also updates the RFCs that define extension SIP header fields using
   the alternative to clarify that the constraint applies (RFCs 3325,
   3515, 3892, 4508, 5002, 5318, 5360, and 5502).
The document is READY. It is well written, to the point, and I found no nits.

Thanks,
Chris

--------------040007040008040100020504-- From nobody Mon May 29 06:14:20 2017 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 C372B12785F; Mon, 29 May 2017 06:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.279 X-Spam-Level: X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_NEUTRAL=0.779] 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 xCvQKu2tLevs; Mon, 29 May 2017 06:14:12 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 C0D72126C22; Mon, 29 May 2017 06:14:11 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v4TDE7Wv025284 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 29 May 2017 16:14:07 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v4TDE7RI000705; Mon, 29 May 2017 16:14:07 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22828.7839.477175.483470@fireball.acr.fi> Date: Mon, 29 May 2017 16:14:07 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-draft-ietf-avtext-lrr.all@ietf.org X-Edit-Time: 7 min X-Total-Time: 7 min Archived-At: Subject: [secdir] Secdir review of draft-draft-ietf-avtext-lrr-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 13:14:14 -0000 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. The document describes the RTCP Layered refresh request which can be uesd to request state refres of substreams. The security considerations point to the RFC5104 and says it is mandatory to validate that payload types and layers are valid for the stream. I think security considerations section is adequate. -- kivinen@iki.fi From nobody Tue May 30 08:38:49 2017 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 44F7212969E for ; Tue, 30 May 2017 08:38:45 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=raytheon.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 v-B3nRary-2i for ; Tue, 30 May 2017 08:38:41 -0700 (PDT) Received: from dfw-mailout20.raytheon.com (dfw-mailout20.raytheon.com [199.46.199.221]) (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 AB9AF12957B for ; Tue, 30 May 2017 08:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=raytheon.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=dkim2017; bh=whYHCyGL4k/gYJnz8+LpcfUs0Q32PZd+7aUHlV10VJE=; b=pBIdaL3Kgpbno6wbpigBc5Wg66E5Bzro7hvkCsQLOYUtvfLddbwIwIxO6ujEAkCErZE6 DF1UQXbFjV3k4+pa8rJypseyIgMFhd3zygNL3NUd7blNkoJ/O+pPUY+tAoDOQUz76lxQ Fkvb59HfeD6eE+Ox1vSKzW1W/QVX3aOwahXu4b8fMBRqNr3Jbu9qF2s5h96RxMO5j9ek lStZEdELMZ5DpcNOHFGnmvR/szm3N5k0jqKpF4B5m2IsW9EkI1453b7a0Gt3Deo3Nt7H 3SVbSBZj3kx8+gYjU2AegLpuzivrWc2ZFT4yJrT2XKVE1WygvInjDUTPtQFigdt1kAeH kQ== Authentication-Results: raytheon.com; spf=fail smtp.mailfrom=steve.kent@raytheon.com; dmarc=none Received: from ca-mailout10.rtnmail.ray.com (ca-mailout10.rtnmail.ray.com [147.25.146.12]) by dfw-mailout20.ext.ray.com (8.16.0.17/8.16.0.17) with ESMTPS id v4UFcXxF007276 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 May 2017 15:38:40 GMT Received: from 008-smtp-out.ray.com ([23.103.8.214]) by ca-mailout10.rtnmail.ray.com (8.16.0.17/8.16.0.17) with ESMTPS id v4UFcXmA045724 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 30 May 2017 15:38:39 GMT Received: from CY1PR0601MB023.008f.mgd2.msft.net (23.103.8.215) by CY1PR0601MB022.008f.mgd2.msft.net (23.103.8.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1084.16; Tue, 30 May 2017 15:38:06 +0000 Received: from CY1PR0601MB023.008f.mgd2.msft.net ([23.103.8.215]) by CY1PR0601MB023.008f.mgd2.msft.net ([23.103.8.215]) with mapi id 15.01.1084.015; Tue, 30 May 2017 15:38:05 +0000 From: Steve KENT To: "secdir@ietf.org" CC: "mbj@microsoft.com" , Kathleen Moriarty Thread-Topic: SECDIR review of draft-ietf-jones-cose-rsa-03 Thread-Index: AQHS2VqqctxWP9UAykODyhjwKhcFFg== Date: Tue, 30 May 2017 15:38:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [23.103.1.5] x-ms-publictraffictype: Email Content-Type: multipart/alternative; boundary="_000_e18f092be12b4790b5add4ef0121529fCY1PR0601MB023008fmgd2m_" MIME-Version: 1.0 X-CC: mbj@microsoft.com, kathleen.moriarty.ietf@gmail.com, secdir@ietf.org X-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-30_10:, , signatures=0 X-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-30_10:, , signatures=0 X-DMZ-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705300293 X-DMZ-Spam-Reason: mlx X-Marking: None Archived-At: Subject: [secdir] SECDIR review of draft-ietf-jones-cose-rsa-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 15:38:45 -0000 --_000_e18f092be12b4790b5add4ef0121529fCY1PR0601MB023008fmgd2m_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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 co= mments 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 cha= irs should treat these comments just like any other last call comments. This document defines algorithm encodings and representations for using RSA= algorithms in the context of COSE messages (draft-ietf-cose-msg). Encodin= gs for the use of RSASSA-PSS signatures, RSAES-OAEP encryption, and RSA key= s are specified in this document. This is a very brief document, only 8 pages, including the usual RFC boiler= plate. Most of the document consists of tables specifying the numeric value= s assigned to RSA algorithms (and parameters thereof) used for encryption a= nd signing in the COSE message context. Section 2 defines the parameters for RSASSA-PSS, appropriately citing RFC 3= 447. Section 3 provides analogous specs for RSAES-OAEP. Section 4 defines RSA key pair parameter identifiers, including support fo= r multi-prime RSA keys, based on conventions described in RFC 3447. Security Considerations are the topic of Section 6. Section 6.1 establishes= 2K bit keys as a minimum SHOULD size, but also establishes 16K keys as a m= aximum SHOULD. The text notes that very large keys create a possible DoS at= tack surface, and it suggests (lower case =93recommend=94) that a size chec= k be performed before beginning crypto operations. The final paragraph of t= his subsection includes text that does not seems very useful, as it is too = vague. Specifically it says =93=85no cryptography would be done except with= keys of legitimate parties.=94 The term =93legitimate=94 is too vague to b= e useful. Does it mean that only keys extracted from verified public key ce= rtificates or acquired through trusted channels are to be employed? The sec= ond countermeasure noted here, i.e., that applications can specified maximu= m as well as minimum key sizes, seems much more useful. Section 6.2 opens with the following statement: =93There is a theoretical h= ash substitution attack that can be mounted against RSASSA-PSS.=94 This sen= tence should include a reference to a paper that describes this attack. Sim= ilarly, the closing sentence of Section 6.3 also would benefit from a refer= ence to a paper that supports the author=92s assertion that using SHA-1 in = this context does not enable any (known) attacks. --_000_e18f092be12b4790b5add4ef0121529fCY1PR0601MB023008fmgd2m_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the se= curity directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving security re= quirements and considerations in IETF drafts.  Comments not addressed in last call may be included in AD reviews du= ring the IESG review.  Document editors and WG chairs should treat these comments just like= any other last call comments.

 

This document defines algorithm enco= dings and representations for using RSA algorithms in the context of COSE m= essages (draft-ietf-cose-msg).  Encodings for the use of RSASSA-PSS signatures, RSAES-OAEP encryptio= n, and RSA keys are specified in this document.

 

This is a very brief document, only = 8 pages, including the usual RFC boilerplate. Most of the document consists= of tables specifying the numeric values assigned to RSA algorithms (and parameters thereof) used for encryption an= d signing in the COSE message context.

 

Section 2 defines the parameters for= RSASSA-PSS, appropriately citing RFC 3447. Section 3 provides analogous sp= ecs for RSAES-OAEP.

 

Section 4 defines RSA key pair param= eter identifiers, including  support for multi-prime RSA keys, based on conventions described in = RFC 3447.

 

Security Considerations are the topi= c of Section 6. Section 6.1 establishes 2K bit keys as a minimum SHOULD siz= e, but also establishes 16K keys as a maximum SHOULD. The text notes that very large keys create a possible Do= S attack surface, and it suggests (lower case =93recommend=94) that a size = check be performed before beginning crypto operations. The final paragraph = of this subsection includes text that does not seems very useful, as it is too vague. Specifically it says =93= =85no cryptography would be done except with keys of legitimate parties.=94= The term =93legitimate=94 is too vague to be useful. Does it mean that onl= y keys extracted from verified public key certificates or acquired through trusted channels are to be employed? The second counte= rmeasure noted here, i.e., that applications can specified maximum as well = as minimum key sizes, seems much more useful.

 

Section 6.2 opens with the following= statement: =93There is a theoretical hash substitution attack that can be = mounted against RSASSA-PSS.=94 This sentence should include a reference to a paper that describes this attack. Similarl= y, the closing sentence of Section 6.3 also would benefit from a reference = to a paper that supports the author=92s assertion that using SHA-1 in this = context does not enable any (known) attacks.


--_000_e18f092be12b4790b5add4ef0121529fCY1PR0601MB023008fmgd2m_-- From nobody Tue May 30 10:42:45 2017 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 6A20F129C31; Tue, 30 May 2017 10:42:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba To: Cc: draft-ietf-sacm-requirements.all@ietf.org, ietf@ietf.org, sacm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149616615640.19877.7389294095180042080@ietfa.amsl.com> Date: Tue, 30 May 2017 10:42:36 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-sacm-requirements-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 17:42:36 -0000 Reviewer: Barry Leiba Review result: Has Nits While I'm calling this document "ready", I really don't see why it should be published in the RFC series at all. It's well written, and it seems to be important material for the working group to use as it develops the SACM architecture, data model and transport protocols, but does not seem to be of lasting interest after those are done. I'd rather see it in the working group wiki, and used that way. That said, I know the working group wants it published and that my comment here is likely not to go far, so I'll say that if it's to be published as an RFC, it's ready. The one nit I note is that in the XML "title" element you appear to have abbrev="Abbreviated Title", rather than the more likely abbrev="SACM Requirements". From nobody Wed May 31 06:23:56 2017 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 B3695129524; Wed, 31 May 2017 06:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZqkjPX-OkIP; Wed, 31 May 2017 06:23:53 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82FE129438; Wed, 31 May 2017 06:23:52 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id g126so11254666ith.0; Wed, 31 May 2017 06:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kPIalmkq3FyPiUSPOslsw0mPM+uWZYwyxwHV/g8apeU=; b=nERP2asZlPEZEPMA7O86bTQ+B6dJXsy4NSvFmQNtLUUfvxh+w0/q4ke2nt1NGZS1qi u8AtNoGTuPEitaH9ema9yvuPq+emJUU9BYreoysq2AjJqI+vhdJ8wxbyw+NxMaALvVXg vPvtkLdWoaTjz77+FZjjRTaBsmPOQv6D3IRBiYYPHf6c7+aaq87M//4RGtnTi7lEhvad 8frscadFcQU/o+tp+y26RiVfy+G2EFs3awxBAezgdpFFw/g+uVsgyMyQWwvVq4dW8DEq 51NrQBwz91j0CPv+owVadENJxR+s7jAhq6kPaehQDbVFzDvzQ82VZ8xyn8h0hcQLewFt fzLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kPIalmkq3FyPiUSPOslsw0mPM+uWZYwyxwHV/g8apeU=; b=HdkL8m7a5qfWkSt2j9yEO19mjW1vryN9LzNYyBetfE4gSeU64xOjdIVWyDZeSz0d6O MG4ag58ux5rcgDbNkUIC3YwL3G8YZHEuWqb/6SOZOjnGQCFwUolyq8pgUhxrYQdeU4VE 844hCPoXZADA7lIzgcx2cPAM0qwqYjdXEs7J+mDuOqQVeF64ntu3RPontHF4KxokS01F loWOFc5Z6hZ+ZgVxMh0LneGG5uTWoSaU9vH/8/emSeYfGx/kbxqz5r2RB3DykSlOlH3e 1JEL2aViZZH78Z9vyYu9doGRKVC09FJ98Nu3yF29/ne6UAY8DpCkpIJqOTMC2JoyvgCM yZEg== X-Gm-Message-State: AODbwcDrVpFsYWEdX1UkCY/iRT0AlrsTcrObaOX+OaM6rX71rWpXIqOx EVebJASgZArcX3vX+Oelcex3FhhKRA== X-Received: by 10.36.26.199 with SMTP id 190mr7245223iti.57.1496237032084; Wed, 31 May 2017 06:23:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.4.148 with HTTP; Wed, 31 May 2017 06:23:51 -0700 (PDT) In-Reply-To: References: From: David Noveck Date: Wed, 31 May 2017 09:23:51 -0400 Message-ID: To: Spencer Dawkins at IETF Cc: Phillip Hallam-Baker , NFSv4 , "secdir@ietf.org" Content-Type: multipart/alternative; boundary="001a1143d750cc1b850550d1d4e0" Archived-At: Subject: Re: [secdir] [nfsv4] SECDIR Review of draft-ietf-nfsv4-umask-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 13:23:55 -0000 --001a1143d750cc1b850550d1d4e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Phillip Hallam-Baker wrote > They are not so much a security plan as a collection of random thoughts jotted down > in haphazard fashion.=E2=80=8B This is fair criticism. I've looked through the Security Considerations sections of RFCs 3530, 7530, and 5661 and the differences are minor. None of these sections were written to provide a security plan, but tried to describe, somewhat inelegantly, the evolution of NFS from its origins in a LAN environment towards NFSv4 which attempted to provide some reasonable security features. Any security needs were provided by RPCSECGSS, and not by the protocol itself. > There is clearly no coherent model of what NFS security should achieve, what the > threats are, what controls are deployed to control them An alternative would have been to define an entirely new protocol with a real security plan covering these matters, but that wasn't the goal then. If it had been, we would probably have a much more secure protocol that nobody would deploy. What happened was that NFSv4 was defined requiring implementation, but not use, of RPCSECGSS. Even today, many NFSv4 deployments use AUTH_SYS and very few which use RPCSECGSS, use integrity or privacy, because of performance issues. Security is provided by use of physically isolated networks or VPNs. That was considered adequate when RFCs 3530, 5661, and 7530 were written and approved. If it is appropriate to move the goal posts here, based on current needs, we have to understand exactly what is being asked for, in order to see if remediation is possible while maintaining continuity with the existing NFSv4 protocol and implementations. Some possibilities: - A clear security plan which defines the threats that NFSv4 addresses and is clear about those it does not address (and so have to addressed b= y other means). - A security plan plan defining the threats that NFSv4 should address, how some of those are addressed by various NFSv4 minor versions, and oth= ers will be by extensions to NFSv4.2 or later minor versions. Spencer Dawkins wrote: > Speaking as the responsible AD, I'm thinking that the right thing to do, is for me to ask the NFSv4 > working group to consider the issue you're raising, with the high-order bit question being whether > it's time to revisit NFS security. If so, we need to better understand exactly what we need to do in this area and are able to do while supporting adequately other uses of NFS, in more controlled environments, where the concerns are different. > The working group is actively discussing a recharter, likely to be discussed in Prague, so it's > the right time to ask the question. Yes. Right now, one of the bulleted items in the extensions section of my proposed draft reads: - Provide effective NFS response to increasing security challenges. It seems to me that the IESG might reasonably be skeptical of our attempt to address new/increasing security challenges, given the level of dissatisfaction with the base we are building on. My next draft will try to address the clarity needs regarding security in the Maintenance section. In any case, the working group will have to discuss these issues in Prague. As it is, we have allocated a total of 30 minutes to the entire charter discussion, so there will probably only be time to begin the discussion and not reach a conclusion. > Given that RFC 7530 is the umbrella RFC for all of NFSv4. Actually, there is no umbrella RFC for all of NFSv4, which is a definite problem given reasonable precipitation expectations :-( RFC5661 is pretty clear about the the fact that it stands on its own. The only NFSv4 RFC that will apply to all of NFSv4 is the one that will arise from the vesioning work. We could create others. > I'm thinking that's the right place to fix anything that needs fixing. I think that will depend on what we decide is fixable, but any substantive securIty extensions would require definition in a new document. With regard to updating the Security Considerations section, we need to address both NFSv4.0 and NFSv4.1, so I don't see an rfc7530bis in our future. If we are able to provide an appropriate updated treatment, it would have to be marked as updating RFCs 5661 and 7530. On Fri, May 26, 2017 at 12:00 PM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Hi, Phillip, > > (adding the NFSv4 working group mailing list, because the issue you raise= d > in this review is relevant to pretty much all of NFSv4) > > On Thu, May 18, 2017 at 12:10 PM, Phillip Hallam-Baker < > phill@hallambaker.com> wrote: > >> Reviewer: >> =E2=80=8BPhillip Hallam-Baker >> >> Review result: >> =E2=80=8BOK but...=E2=80=8B >> >> >> 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: Review of draft-ietf-nfsv4-umask-03 >> Reviewer: >> =E2=80=8BPhillip Hallam-Baker >> >> >> >> Review result: >> =E2=80=8BOK but...=E2=80=8B >> >> >> This particular draft looks OK to me. Aligning the semantics of NFS with >> the semantics of the file system seems to me to be absolutely the way to= go >> forward. I am not sufficiently experienced in the semantics of NFS or Un= ix >> as deployed to be able to offer an opinion on whether the draft achieves >> that. However it appears that the author does. >> >> =E2=80=8BWhat is problematic here is that the Security Considerations in= the >> draft are essentially relying on those in rfc7530 which are woefully >> inadequate given the critical role of NFS in Internet security. They are >> not so much a security plan as a collection of random thoughts jotted do= wn >> in haphazard fashion.=E2=80=8B >> >> There is clearly no coherent model of what NFS security should achieve, >> what the threats are, what controls are deployed to control them. Also n= ote >> that the main reason this review is late is that I have been dealing wit= h >> issues arising from WannaCry which used an SMB:1 exploit. Re-reading >> RFC7530 in the light of that experience gives me grave concern. >> > > This is very interesting ... > > Speaking as the responsible AD, I'm thinking that the right thing to do, > is for me to ask the NFSv4 working group to consider the issue you're > raising, with the high-order bit question being whether it's time to > revisit NFS security. The working group is actively discussing a recharte= r, > likely to be discussed in Prague, so it's the right time to ask the > question. > > Given that RFC 7530 is the umbrella RFC for all of NFSv4, I'm thinking > that's the right place to fix anything that needs fixing. > > And thanks for your review. > > Spencer > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www.ietf.org/mailman/listinfo/nfsv4 > > --001a1143d750cc1b850550d1d4e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Phillip Hallam-Baker wrote
> They are not so = much a security plan as a collection of random thoughts jotted down=C2=A0> in haphazard fashion.=E2=80=8B

This is= fair criticism.=C2=A0 I've looked through the Security Considerations = sections of RFCs 3530, 7530, and 5661 and the differences are minor. =C2=A0= None of these sections were written to provide a security plan, but tried = to describe, somewhat inelegantly, the evolution of NFS from its origins in= a LAN environment towards NFSv4 which attempted to provide some reasonable= security features.=C2=A0 Any security needs were provided by RPCSECGSS, an= d not by the protocol itself.

=
> There is clearly no coherent model of what NFS secur= ity should achieve, what the=C2=A0
> threats are, what control= s are deployed to control them

An alternative woul= d have been to define an entirely new protocol with a real security plan co= vering these matters, but that wasn't the goal then.=C2=A0 If it had be= en, we would probably have a much more secure protocol that nobody would de= ploy.=C2=A0 What happened was that NFSv4 was defined requiring implementati= on, but not use, of RPCSECGSS.=C2=A0 Even today, many NFSv4 deployments use= AUTH_SYS and very few which use RPCSECGSS, use integrity or privacy, becau= se of performance issues.=C2=A0 Security is provided by use of physically i= solated networks or VPNs. =C2=A0 That was considered adequate when RFCs 353= 0, 5661, and 7530 were written and approved.

If it= is appropriate to move the goal posts here, based on current needs, we hav= e to understand exactly what is being asked for, in order to see if remedia= tion is possible while maintaining continuity with the existing NFSv4 proto= col and implementations.=C2=A0 Some possibilities:
  • A clea= r security plan which defines the threats that NFSv4 addresses and is clear= about those it does not address (and so have to addressed by other means).=
  • A security plan plan defining the threats that NFSv4 should addres= s, how some of those are addressed by various NFSv4 minor versions, and oth= ers will be by extensions to NFSv4.2 or later minor versions.
Spencer Dawkins wrote:
> Speaking as the responsibl= e AD, I'm thinking that the right thing to do, is for me to ask the NFS= v4=C2=A0
> working group to consider the issue you're rais= ing, with the high-order bit question being whether=C2=A0
> it= 's time to revisit NFS security.=C2=A0

If so, = we need to better understand exactly what we need to do in this area and ar= e able to do while supporting adequately other uses of NFS, in more control= led environments, where the concerns are different.=C2=A0

> The working group is actively discussing a recharter, likely t= o be discussed in Prague, so it's=C2=A0
> the right time t= o ask the question.
Yes.=C2=A0 Right now, one of the bulleted items in the extensio= ns section of my proposed draft reads:
  • Provide effective = NFS response to increasing security challenges.
It seems = to me that the IESG might reasonably be skeptical of our attempt to address= new/increasing security challenges, given the level of dissatisfaction wit= h the base we are building on.

My next draft= will try to address the clarity needs regarding security in the Maintenanc= e section.=C2=A0 In any case, the working group will have to discuss these = issues in Prague.=C2=A0 As it is, we have allocated a total of 30 minutes t= o the entire charter discussion, so there will probably only be time to beg= in the discussion and not reach a conclusion.=C2=A0

> Given that RFC 7530 is the umbrella RFC for all of NFSv4.
=
Actually, there is no umbrella RFC for all of NFSv4, which i= s a definite problem given reasonable precipitation expectations :-(
<= div>
RFC5661 is pretty clear about the the fact that it stand= s on its own.

The only NFSv4 RFC that will apply t= o all of NFSv4 is the one that will arise from the vesioning work.=C2=A0 We= could create others.

> I'm thinking that&#= 39;s =C2=A0the right place to fix anything that needs fixing.
I think that will depend on what we decide is fixable, but any = substantive securIty extensions would require definition in a new document.=

With regard to updating the Security Consideratio= ns section, we need to address both NFSv4.0 and NFSv4.1, so I don't see= an rfc7530bis in our future.=C2=A0 If we are able to provide an appropriat= e updated treatment, it would have to be marked as updating RFCs 5661 and 7= 530.


On Fri, May 26, 2017 at 12:00 PM, Spencer Dawk= ins at IETF <spencerdawkins.ietf@gmail.com> wrot= e:
Hi, Phillip,

=
(adding the NFSv4 working group mailing list, because the issue = you raised in this review is relevant to pretty much all of NFSv4)

On Thu, May 18, 2017 a= t 12:10 PM, Phillip Hallam-Baker <phill@hallambaker.com>= wrote:
Reviewer:=C2=A0
=E2=80= =8BPhillip Hallam-Baker

Review result:=C2=A0
=E2=80=8BOK but...=E2=80=8B


I revi= ewed 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 primaril= y for the benefit of the Security Area
Directors.=C2=A0 Document authors, docume= nt editors, and WG chairs should
treat these comments just like any other IETF L= ast Call comments.

Document:=C2=A0Review of draft= -ietf-nfsv4-umask-03
Reviewer:
=E2= =80=8BPhillip Hallam-Baker



Review result:=C2=A0
=E2= =80=8BOK but...=E2=80=8B


This particular draft looks OK= to me. Aligning the semantics of NFS with the semantics of the file system= seems to me to be absolutely the way to go forward. I am not sufficiently = experienced in the semantics of NFS or Unix as deployed to be able to offer= an opinion on whether the draft achieves that. However it appears that the= author does.

=E2=80=8BWhat is problematic here is t= hat the Security Considerations in the draft are essentially relying on tho= se in rfc7530 which are woefully inadequate given the critical role of NFS = in Internet security. They are not so much a security plan as a collection = of random thoughts jotted down in haphazard fashion.=E2=80=8B

There is clearly no coherent model of = what NFS security should achieve, what the threats are, what controls are d= eployed to control them. Also note that the main reason this review is late= is that I have been dealing with issues arising from WannaCry which used a= n SMB:1 exploit. Re-reading RFC7530 in the light of that experience gives m= e grave concern.

This is = very interesting ...

Speaking as the responsible A= D, I'm thinking that the right thing to do, is for me to ask the NFSv4 = working group to consider the issue you're raising, with the high-order= bit question being whether it's time to revisit NFS security. The work= ing group is actively discussing a recharter, likely to be discussed in Pra= gue, so it's the right time to ask the question.

Given that RFC 7530 is the umbrella RFC for all of NFSv4, I'm thinki= ng that's the right place to fix anything that needs fixing.
=
And thanks for your review.

Spencer=C2=A0

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


--001a1143d750cc1b850550d1d4e0-- From nobody Wed May 31 20:59:40 2017 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 6722C12EB0F; Wed, 31 May 2017 20:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Xh_ZIRGxzxR7; Wed, 31 May 2017 20:59:31 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE8391267BB; Wed, 31 May 2017 20:59:30 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id m17so25575196pfg.3; Wed, 31 May 2017 20:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r6tsKvprVD6hHzPiauZZJ1AZwbpUOaY/XGE7WIRDIPw=; b=nov409/6NpbO3GRlpvKf8wLPeU71NeC+uxIwme4DtD3lZz6cXvr8WOIZpFkIox/CxG lA2wD/B1vdH5ir88kboWy9uPzzb+SBn7gXFiniPKvr+Vr71Ir/FOS6YlaANztcb26Kf+ 54DJKr4oSUa7GiV4hYLRcCrG3HbkdwoCQMonoir+nFlVQn4IXtkY2mWWkHttDkIC8jze HyG9CoEGuz8Pjf78gHePxiN/z0HK+14V8exKtQbne1QZIo4dIs5QMSoQJ2Bs0yRpgXGQ 9M8pnlPRe8xzpYkYXrMHMJHYNV9Qu6HujrHCiw8PSMHfwLnBdY+/fap+XYNCwPmiWoZb leKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r6tsKvprVD6hHzPiauZZJ1AZwbpUOaY/XGE7WIRDIPw=; b=oofLLEoaUrA6l4syxD/aPjOvq7f4i50gDtHaFQLRoY/sEccKAJ94g9CnzDuA1+vqe3 ZhEH+VTG4w4FOvx2bp7eiReuIaYdHjzK1NrXBksJwhZGNsXCCJZhCy2eKQmIfPKQ1w7U /vAnrXa0fNehOyUtv1Z/1llB5nScFgkGemURkBS7aEs4daTpw2VjHnnGBRNarNOpKguq zW5iwYCVG83fjsHLlbMQTUHRgP4OZBh0uh9ZbrS2n76yrfuhq+y4yZb3pi4eoSbppBP2 SSxwoFXqsRr+BnyOo7Z4AdvGxeTlV6Ar7CWjau3r5uNq3BsbT7bQ8Ra5gYPQnWWWJc8y u4eg== X-Gm-Message-State: AODbwcBISpKS00tiRCVhr+7/U4nDIroEkF+pShTZuTcrIitKuJfUO3+B bCCJt8iljEuthLTakeagZl1y6I1YbxBs X-Received: by 10.98.9.91 with SMTP id e88mr34386102pfd.177.1496289570436; Wed, 31 May 2017 20:59:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.207.228 with HTTP; Wed, 31 May 2017 20:59:29 -0700 (PDT) In-Reply-To: References: From: Watson Ladd Date: Wed, 31 May 2017 20:59:30 -0700 Message-ID: To: David Noveck Cc: Spencer Dawkins at IETF , Phillip Hallam-Baker , NFSv4 , "secdir@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] [nfsv4] SECDIR Review of draft-ietf-nfsv4-umask-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 03:59:33 -0000 On Wed, May 31, 2017 at 6:23 AM, David Noveck wrote: > Phillip Hallam-Baker wrote >> They are not so much a security plan as a collection of random thoughts >> jotted down >> in haphazard fashion. > > This is fair criticism. I've looked through the Security Considerations > sections of RFCs 3530, 7530, and 5661 and the differences are minor. None > of these sections were written to provide a security plan, but tried to > describe, somewhat inelegantly, the evolution of NFS from its origins in a > LAN environment towards NFSv4 which attempted to provide some reasonable > security features. Any security needs were provided by RPCSECGSS, and not > by the protocol itself. > >> There is clearly no coherent model of what NFS security should achieve, >> what the >> threats are, what controls are deployed to control them > > An alternative would have been to define an entirely new protocol with a > real security plan covering these matters, but that wasn't the goal then. > If it had been, we would probably have a much more secure protocol that > nobody would deploy. What happened was that NFSv4 was defined requiring > implementation, but not use, of RPCSECGSS. Even today, many NFSv4 > deployments use AUTH_SYS and very few which use RPCSECGSS, use integrity or > privacy, because of performance issues. Security is provided by use of > physically isolated networks or VPNs. That was considered adequate when > RFCs 3530, 5661, and 7530 were written and approved. How does this address the sorts of problems associated with the NFS permissions model? Furthermore, this candy bar network (crunchy shell with gooey inside) is a real liability. It would be nice if we could make it easier to move away from. > > If it is appropriate to move the goal posts here, based on current needs, we > have to understand exactly what is being asked for, in order to see if > remediation is possible while maintaining continuity with the existing NFSv4 > protocol and implementations. Some possibilities: > > A clear security plan which defines the threats that NFSv4 addresses and is > clear about those it does not address (and so have to addressed by other > means). > A security plan plan defining the threats that NFSv4 should address, how > some of those are addressed by various NFSv4 minor versions, and others will > be by extensions to NFSv4.2 or later minor versions. I prefer the second, but it might never happen. The first is at least useful (when combined with what NFSv4 could address as shown by other systems of similar kind) > > Spencer Dawkins wrote: >> Speaking as the responsible AD, I'm thinking that the right thing to do, >> is for me to ask the NFSv4 >> working group to consider the issue you're raising, with the high-order >> bit question being whether >> it's time to revisit NFS security. > > If so, we need to better understand exactly what we need to do in this area > and are able to do while supporting adequately other uses of NFS, in more > controlled environments, where the concerns are different. > >> The working group is actively discussing a recharter, likely to be >> discussed in Prague, so it's >> the right time to ask the question. > > Yes. Right now, one of the bulleted items in the extensions section of my > proposed draft reads: > > Provide effective NFS response to increasing security challenges. > > It seems to me that the IESG might reasonably be skeptical of our attempt to > address new/increasing security challenges, given the level of > dissatisfaction with the base we are building on. > > My next draft will try to address the clarity needs regarding security in > the Maintenance section. In any case, the working group will have to > discuss these issues in Prague. As it is, we have allocated a total of 30 > minutes to the entire charter discussion, so there will probably only be > time to begin the discussion and not reach a conclusion. > >> Given that RFC 7530 is the umbrella RFC for all of NFSv4. > > Actually, there is no umbrella RFC for all of NFSv4, which is a definite > problem given reasonable precipitation expectations :-( > > RFC5661 is pretty clear about the the fact that it stands on its own. > > The only NFSv4 RFC that will apply to all of NFSv4 is the one that will > arise from the vesioning work. We could create others. > >> I'm thinking that's the right place to fix anything that needs fixing. > > I think that will depend on what we decide is fixable, but any substantive > securIty extensions would require definition in a new document. > > With regard to updating the Security Considerations section, we need to > address both NFSv4.0 and NFSv4.1, so I don't see an rfc7530bis in our > future. If we are able to provide an appropriate updated treatment, it > would have to be marked as updating RFCs 5661 and 7530. > > > > On Fri, May 26, 2017 at 12:00 PM, Spencer Dawkins at IETF > wrote: >> >> Hi, Phillip, >> >> (adding the NFSv4 working group mailing list, because the issue you raised >> in this review is relevant to pretty much all of NFSv4) >> >> On Thu, May 18, 2017 at 12:10 PM, Phillip Hallam-Baker >> wrote: >>> >>> Reviewer: >>> Phillip Hallam-Baker >>> >>> Review result: >>> OK but... >>> >>> >>> 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: Review of draft-ietf-nfsv4-umask-03 >>> Reviewer: >>> Phillip Hallam-Baker >>> >>> >>> >>> Review result: >>> OK but... >>> >>> >>> This particular draft looks OK to me. Aligning the semantics of NFS with >>> the semantics of the file system seems to me to be absolutely the way to go >>> forward. I am not sufficiently experienced in the semantics of NFS or Unix >>> as deployed to be able to offer an opinion on whether the draft achieves >>> that. However it appears that the author does. >>> >>> What is problematic here is that the Security Considerations in the draft >>> are essentially relying on those in rfc7530 which are woefully inadequate >>> given the critical role of NFS in Internet security. They are not so much a >>> security plan as a collection of random thoughts jotted down in haphazard >>> fashion. >>> >>> There is clearly no coherent model of what NFS security should achieve, >>> what the threats are, what controls are deployed to control them. Also note >>> that the main reason this review is late is that I have been dealing with >>> issues arising from WannaCry which used an SMB:1 exploit. Re-reading RFC7530 >>> in the light of that experience gives me grave concern. >> >> >> This is very interesting ... >> >> Speaking as the responsible AD, I'm thinking that the right thing to do, >> is for me to ask the NFSv4 working group to consider the issue you're >> raising, with the high-order bit question being whether it's time to revisit >> NFS security. The working group is actively discussing a recharter, likely >> to be discussed in Prague, so it's the right time to ask the question. >> >> Given that RFC 7530 is the umbrella RFC for all of NFSv4, I'm thinking >> that's the right place to fix anything that needs fixing. >> >> And thanks for your review. >> >> Spencer >> >> _______________________________________________ >> nfsv4 mailing list >> nfsv4@ietf.org >> https://www.ietf.org/mailman/listinfo/nfsv4 >> > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > -- "Man is born free, but everywhere he is in chains". --Rousseau.