From nobody Wed Apr 5 13:47:55 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 4C9411294AF; Wed, 5 Apr 2017 13:47:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks To: Cc: draft-ietf-httpbis-encryption-encoding.all@ietf.org, ietf@ietf.org, ietf-http-wg@w3.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149142527327.21912.5654685591478038284@ietfa.amsl.com> Date: Wed, 05 Apr 2017 13:47:53 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-httpbis-encryption-encoding-08 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, 05 Apr 2017 20:47:53 -0000 Reviewer: Robert Sparks Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Document : draft-ietf-httpbis-encryption-encoding-08 Summary: This document is ready for publication as Proposed Standard (except perhaps for one recommendation) This document defines a content encoding for encrypting the contents of an HTTP message that facilitates storing the encrypted contents and decrypting the content for rendering incrementally (before the full content is received). The draft is clear, and implementation should be straightforward. It's security considerations section is detailed. I did not verify the math that went into the provided examples. My only concern is that the document suggests it would be ok to use a counter to provide a unique salt value for each message. I suspect that provides the kind of information leak the draft discusses avoiding. I also pointed out a couple of nits to the editor, and those are addressed already in his working copy (on github). From nobody Wed Apr 5 15:33: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 46E0E127978; Wed, 5 Apr 2017 15:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYW9ZLF2jjCJ; Wed, 5 Apr 2017 15:32:50 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 5576A1294C8; Wed, 5 Apr 2017 15:32:43 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id p22so23910614qka.3; Wed, 05 Apr 2017 15:32:43 -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=yI0jB5gy9FBC1BAchxJ6qSMnSsEivOs4HzlVE5pTWzE=; b=VnYUbdIc+IGxcNj5F+dfvAka1rmR+h/hrxZNc+PR3TLqylBrA0zWk7HSICaylycrF1 M8O0SEMBDFJN6AqVb92S8qIuRi3jCwmYkyQDkpMJqdkH3PGBDZ7rzKc06XDN3TjIu+UW o8wCpT95U/oVJRY3Bqn2v5pkA7PfgBJRZBCJ0wyh+YXXG8YcP0I7FaXlmnfO/NL9W/al Q5nkEWoGuSqYa485/ixyCpw+JlqdOS2sx/Sctva0dadgEhQDHgGzSDIUsxe+F72/Vbci IDIRgkFlNd4ZNxxVCeuxcHMIotPBzuCB4EK3OfRPAYIeMXS0No1IYOB22XnUqcL80Dfj JOog== 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=yI0jB5gy9FBC1BAchxJ6qSMnSsEivOs4HzlVE5pTWzE=; b=XgZrNPLjka/38mL+Ojsa9Kw2A6RtrEqJSXHD6c8c0wj/Xjc8bgV/n2DMWt+7is10YM qV3804+uAOQ0B7mIm5DT2uu9O+fFJ3cPTKpw2MkOISImgV4nPJFHgB15qzpkGa4mznxj Z6kvHO0g8CT8LJznI/Q91QFMxjYHyQF35Cn/7mIZRL5p+uuT/dH7P9+gsCbS4T4OkC0v 6uQSvHcacUxdO5xHDuhq3w86vVN9+usvJiutiL8IyttZ3ZolvQ0/ra8pCm9o7HOYZgZe HInPfS+ELTrXIX2pOaWGZLA10R4Z19WnK1l1eQ3AfutEQexoskh03LEoNjUMK4x00SCy zfTw== X-Gm-Message-State: AFeK/H3Wzjnvxt2kPTbR6IMYXMtr1eRwufPHXiOVW7pGYO8TuzItf/5m8xSrcJ44ZzOOinjEIL8ziKUA2p/x6w== X-Received: by 10.55.104.88 with SMTP id d85mr8066225qkc.202.1491431562562; Wed, 05 Apr 2017 15:32:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Wed, 5 Apr 2017 15:32:42 -0700 (PDT) In-Reply-To: <149142527327.21912.5654685591478038284@ietfa.amsl.com> References: <149142527327.21912.5654685591478038284@ietfa.amsl.com> From: Martin Thomson Date: Thu, 6 Apr 2017 08:32:42 +1000 Message-ID: To: Robert Sparks Cc: "secdir@ietf.org" , draft-ietf-httpbis-encryption-encoding.all@ietf.org, "ietf@ietf.org" , HTTP Working Group Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-httpbis-encryption-encoding-08 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, 05 Apr 2017 22:32:52 -0000 On 6 April 2017 at 06:47, Robert Sparks wrote: > > My only concern is that the document suggests it would be ok to use a > counter to provide a unique salt value > for each message. I suspect that provides the kind of information leak > the draft discusses avoiding. Hi Robert, can you explain what sort of leakage you are concerned about? I mean, I can understand how you could construct the sequence of resources that were encrypted using a counter for the salt, but I don't know what that might imply. That said, I think that the counter thing can be removed. We require 128 bits of salt, which is a space that is large enough to select randomly from in perpetuity. From nobody Thu Apr 6 03:58:41 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 0FD4012943E; Thu, 6 Apr 2017 03:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzBshJo8_eER; Thu, 6 Apr 2017 03:58:31 -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 9BF0D12943B; Thu, 6 Apr 2017 03:58:30 -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 v36AwQFX000159 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Apr 2017 13:58:26 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v36AwQOT005451; Thu, 6 Apr 2017 13:58:26 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22758.8018.819433.930944@fireball.acr.fi> Date: Thu, 6 Apr 2017 13:58:26 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ippm-6man-pdm-option.all@ietf.org X-Edit-Time: 19 min X-Total-Time: 18 min Archived-At: Subject: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-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, 06 Apr 2017 10:58:33 -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. This is rereview of the performance and diagnostic metrics destination option document, and this version is much better than the previous one. The security considerations and the default settings are better now. I have one nit about the document. In the section 3.4.2 it talks about putting PDM header outside the ESP, and says that: As a completely new IP packet will be made, it means that PDM information for that packet does not contain any information from the inner packet, i.e. the PDM information will NOT be based on the transport layer (TCP, UDP, etc) ports etc in the inner header, but will be specific to the ESP flow. This is fine, but it should note, that in this case there is no 5-tuple available, as there is no SPORT or DPORT. With PDM option outside the ESP header, the system should use SADDR, DADDR and PROTC to identify the flow. In addition to that it could use the SPI pair to identify the flow. The problem with ESP is that there is really two unidirectional flows, i.e. one flow from node A to node B with SPI of X, and another flow from node B to node A with SPI of Y. Only one SPI value is stored in the packet, and it is not possible to know from the outside which SPI number X matches the SPI number Y, in case there are multiple ESP SAs between the peers. In case the PDM option processing is integrated to the ESP, then the PDM processing could consider the two unidirectional ESP flow as one bi-directional ESP flow, and combine the PDM information for them. The problem is that if PDM processing is not integrated in the ESP, it does not know the SPI numbers that form this pair, and if one end does this and other end does not (because its PDM processing is not integrated with ESP) then information not be that useful. Because of this it is be better just to say that we do not use SPI numbers when creating the flows, meaning we combined all ESP SAs between the peers to one flow. This means that we will simply use SADDR, DADDR and PROTC as selectors for the PDM flow. If there is multiple ESP SAs between the peers, the IPsec users its own policy rules to pick which traffic ends up in which ESP SA, thus it is completely possible that one TCP stream from host behind the IPsec gateway will be split in multiple ESP SAs. If using combined PDM statistics for all ESP traffic, then it does not matter how the IPsec splits traffic over multiple tunnels. So I think it could be good idea to add text like this to end of the paragraph above in section 3.4.2: In ESP case there is no 5-tuple available, as there is no port numbers, and that means that ESP flow should be identified only by using SADDR, DADDR and PROTOC. The SPI numbers SHOULD be ignored when considering what is the flow over which PDM information is measured. In summary I think this document is ready with nits. -- kivinen@iki.fi From nobody Thu Apr 6 04:41:04 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 051951294AF for ; Thu, 6 Apr 2017 04:41:03 -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.49.0 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <149147886301.21971.15743728623613452645.idtracker@ietfa.amsl.com> Date: Thu, 06 Apr 2017 04:41:03 -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, 06 Apr 2017 11:41:03 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-04-13 Reviewer LC end Draft Derek Atkins 2017-03-22 draft-ietf-i2nsf-problem-and-use-cases-11 Phillip Hallam-Baker 2017-02-24 draft-ietf-dmm-lma-controlled-mag-params-04 Hilarie Orman 2017-03-01 draft-ietf-6man-rfc2460bis-09 Vincent Roca 2017-04-07 draft-ietf-rtgwg-yang-key-chain-17 Joseph Salowey 2017-04-07 draft-ietf-isis-mi-bis-02 Rifaat Shekh-Yusef 2017-03-13 draft-mm-wg-effect-encrypt-09 For telechat 2017-04-27 Reviewer LC end Draft Russ Mundy 2017-04-18 draft-ietf-ipsecme-tcp-encaps-09 Last calls: Reviewer LC end Draft Ben Laurie 2017-03-02 draft-ietf-dprive-dtls-and-tls-profiles-08 Rich Salz 2017-04-06 draft-ietf-mmusic-dtls-sdp-22 Melinda Shore 2017-04-09 draft-ietf-core-coap-tcp-tls-07 Takeshi Takahashi 2017-04-18 draft-ietf-grow-bgp-reject-04 Sean Turner 2017-04-13 draft-ietf-dnssd-mdns-dns-interop-04 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-08 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Next in the reviewer rotation: David Waltermire Sam Weiler Brian Weis Klaas Wierenga Paul Wouters Liang Xia Tom Yu Dacheng Zhang Derek Atkins John Bradley From nobody Thu Apr 6 06:01: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 22A181294CA; Thu, 6 Apr 2017 06:00: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 6g5hobu0-b-E; Thu, 6 Apr 2017 06:00:52 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 63C3E126C83; Thu, 6 Apr 2017 06:00:52 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id z204so39347338vkd.1; Thu, 06 Apr 2017 06:00:52 -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=b2TN++1rZKMfUA46X6nEc3Me7qY5uKPQYwoFXnU28ug=; b=VOAiuUfKvat+9hfQj+nmmKZ4j0n/qWSpwTA2TE5Hi/LE7hrjGKSJj1zkgzjdwVCSBW Jhdev9k9d8SiuKKG1C+sQ2hgdp5ww3AOVi1N95v9Foe30iqFpY3+ks/QtcIZp9Wgw1TL QhslX+QNRR4nQMts7izlWDWl2XzAVu2JXFWCUnW67hRu4bmKJV+QS72/LRcYukCcqwMZ QkaM9E1+Yj/T+ODAY418c1hv91400uAX9fMZhAE/EzCn/eOKCMdVmR+IwAUz4eR5CbGd 6vwWcplrqjFQfLlPHiR7vGQrMuP15Xq4foDCEp75zFPjdrVKlDeJhLY+T6iUxvxn4EeX fePA== 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=b2TN++1rZKMfUA46X6nEc3Me7qY5uKPQYwoFXnU28ug=; b=HGm50qnI2QqH7upkJAppa4XRQAAeMPSHsS3MacGvP8hfnxInsDtaIT/xzzq0sfr8w2 7FTz4M4WrGSLJBoZpSMMLx/h74x7DH7So+p58DlQLVe+1ovmn8OM2j8bp2ml0n122jmY JQsfZ8d82Lk4tUW6Uk/Nng1z5BhraSUPYhck9I9uGM9eX/dhsD4u1F0ib6TWVmi0HJXn xYSrg1SZ1h1MJbMQRS3Qo4NcsIWpzhlk5jGd6L93XjrNnKNiNtg0SH0P4/YpqguXImCR x7XeEmp+hyt9gxxKFwIh5PYG4YU/9iNqVpuxGqw/xgR4Y/36qpvB/Rzu6d1P8jIcSubI pnVg== X-Gm-Message-State: AFeK/H1yda1vJijC6aMkscusd9b9Xv8/rpk18Sho90O767t2IMev/h8kMHP9+/tHFuVY1C+Fj3UEF4cLCHNT4g== X-Received: by 10.31.210.132 with SMTP id j126mr14661890vkg.95.1491483651227; Thu, 06 Apr 2017 06:00:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.85.82 with HTTP; Thu, 6 Apr 2017 06:00:50 -0700 (PDT) From: Rifaat Shekh-Yusef Date: Thu, 6 Apr 2017 09:00:50 -0400 Message-ID: To: secdir@ietf.org, The IESG , draft-mm-wg-effect-encrypt@ietf.org Content-Type: multipart/alternative; boundary=001a114e552438456e054c7f1985 Archived-At: Subject: [secdir] SecDir review of draft-mm-wg-effect-encrypt-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, 06 Apr 2017 13:00:54 -0000 --001a114e552438456e054c7f1985 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. Summary: *Ready with nits* The document describes security and management functions that might be impacted by the increased use of encryption. The goal of the document is to only list the potential problems, not to propose solutions to these problems. *nits:* 1. The document refers to an Appendix in multiples places, which is now section 7. 2. Page 18, second line: the word 'trusted' has quotes around it; is there a reason for that? Regards, Rifaat --001a114e552438456e054c7f1985 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security= directorate's=C2=A0
ongoing effort to review all IETF docume= nts being processed by the=C2=A0
IESG.=C2=A0 These comments were = written primarily for the benefit of the=C2=A0
security area dire= ctors.=C2=A0 Document editors and WG chairs should treat=C2=A0
th= ese comments just like any other last call comments.

Summary: Ready with nits

The= document describes security and management functions that might be=C2=A0
impacted by the increased use of encryption.
The g= oal of the document is to only list the potential problems, not to propose= =C2=A0
solutions to these problems.


=
nits:

1. The document refers to = an Appendix in multiples places, which is now section 7.=C2=A0
2.= Page 18, second line: the word 'trusted' has quotes around it; is = there a reason for that?

Regards,
=C2=A0= Rifaat


--001a114e552438456e054c7f1985-- From nobody Thu Apr 6 07:47:17 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 54A6F1294B9; Thu, 6 Apr 2017 07:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MZ4NyIdU-QA; Thu, 6 Apr 2017 07:47:13 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 BDA8C129457; Thu, 6 Apr 2017 07:47:13 -0700 (PDT) Received: from unescapeable.local ([47.186.26.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v36ElBKd026308 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 6 Apr 2017 09:47:12 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be unescapeable.local To: Martin Thomson References: <149142527327.21912.5654685591478038284@ietfa.amsl.com> Cc: "secdir@ietf.org" , draft-ietf-httpbis-encryption-encoding.all@ietf.org, "ietf@ietf.org" , HTTP Working Group From: Robert Sparks Message-ID: <1f550ddb-a279-ad2b-0599-c9ed2c95da09@nostrum.com> Date: Thu, 6 Apr 2017 09:47:08 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-httpbis-encryption-encoding-08 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, 06 Apr 2017 14:47:15 -0000 On 4/5/17 5:32 PM, Martin Thomson wrote: > On 6 April 2017 at 06:47, Robert Sparks wrote: >> My only concern is that the document suggests it would be ok to use a >> counter to provide a unique salt value >> for each message. I suspect that provides the kind of information leak >> the draft discusses avoiding. > Hi Robert, can you explain what sort of leakage you are concerned > about? I mean, I can understand how you could construct the sequence > of resources that were encrypted using a counter for the salt, but I > don't know what that might imply. Things like these: - A third party that could see that sequence would know if there were gaps. - If creation or transmission time can be approximated (perhaps via file stats), the third party can more quickly assess the rate of creation, and have a strong idea of when to look for the next one. Of course for both of those, the 3rd party would need to somehow know the content came from the same source, but it's easy to see systems built using this that would expose that. > > That said, I think that the counter thing can be removed. We require > 128 bits of salt, which is a space that is large enough to select > randomly from in perpetuity. That would be my personal preference. From nobody Thu Apr 6 08:10: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 24E12128959; Thu, 6 Apr 2017 08:10:20 -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 x4Ksx6V3Yw7o; Thu, 6 Apr 2017 08:10:18 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71EC4127863; Thu, 6 Apr 2017 08:10:18 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id 81so39134739pgh.2; Thu, 06 Apr 2017 08:10:18 -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=erRTB8HdWlSQAFIYW52YxeLnnYjnuH1bRQ9izjgvUfk=; b=dKi9pU7QEueuBzJLy9HLiNOT5Yj2hp2TbZe9wlKc2MgDfkpwh4a82OOzqJwNDhReUp xbE1OSbbtrMAjoBaMDXGzESBBUjR0ElruCQwwm4vUFyUuvfOSzhVQ67CBV467xbpUTJe repdHScbjk1JBXv7PhJvSD3lNlwIzIElkwPACC1q6FDL1obA5dEf3UFW0jClswnC7USW 858Jnuy0j5YJb3mErAZ2jvrHiI4fbq71jhhtfnlZ97FuoMmWhUywS48BLG6q9Is7xA7o MGnlRu0rcM2KAgbFnS9y21fo/fuwNfEFl2RDmU7w5T8LI1GtErqjhxMBjXgfRhlgffg+ S4ww== 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=erRTB8HdWlSQAFIYW52YxeLnnYjnuH1bRQ9izjgvUfk=; b=oqcwa4gJyBDmM9lFnifSviAAkaqu0c3JKdQqrKc26FP9FRCrWXz62NZVHJcR1Tyome HoR8+/zomB4/sNzHFNH4U4lt60lhyzL+U5tA8EKTgjE96bbeOlGV+YbDog49bBTdAYqE 4BSHBsL6mV6+YcL3gP67KbaAng6Tw+g4pMz5SBZDO2U+bPG1M0RFt8tAG8ucvR8PgClh WgDMM8ont68a08Nr6zTVAffu4SwRi8Wg3Igs/aOJqWcC2sXtJVxYE3uATDxEbqpb5Txj oFRPyaiqa5LBtbo2pSdWiM2dXyfCvQVzdDd88yX6Hb3eTm3hUTFJdcO3pHnclFRSPmPh /KSw== X-Gm-Message-State: AFeK/H1v9S5urF13dRAGVOpFYFLrTeq/qI5QdRgPIGmABgSxLPS/NZgTlivMGhuYPsl3pbOLS/GZiCF4eKj9qg== X-Received: by 10.84.241.134 with SMTP id b6mr3774196pll.107.1491491418003; Thu, 06 Apr 2017 08:10:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.128.141 with HTTP; Thu, 6 Apr 2017 08:09:36 -0700 (PDT) In-Reply-To: References: From: Kathleen Moriarty Date: Thu, 6 Apr 2017 11:09:36 -0400 Message-ID: To: Rifaat Shekh-Yusef Cc: "secdir@ietf.org" , The IESG , draft-mm-wg-effect-encrypt@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [secdir] SecDir review of draft-mm-wg-effect-encrypt-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, 06 Apr 2017 15:10:20 -0000 Hi Rifaat, Thanks for your review! We had #1 queued up for the next revision. Trusted had single quotes around it because it isn't the term of a product or well known term, but trusted by the organization. I don't like the word trust because it is loaded and used differently by many. If others think we should remove that or the RFC editor, that's fine. Thanks, Kathleen On Thu, Apr 6, 2017 at 9:00 AM, Rifaat Shekh-Yusef 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. > > Summary: Ready with nits > > The document describes security and management functions that might be > impacted by the increased use of encryption. > The goal of the document is to only list the potential problems, not to > propose > solutions to these problems. > > > nits: > > 1. The document refers to an Appendix in multiples places, which is now > section 7. > 2. Page 18, second line: the word 'trusted' has quotes around it; is there a > reason for that? > > Regards, > Rifaat > > -- Best regards, Kathleen From nobody Thu Apr 6 09:28: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 F26F2129562; Thu, 6 Apr 2017 09:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.396 X-Spam-Level: X-Spam-Status: No, score=-5.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLR6_gDuFQqd; Thu, 6 Apr 2017 09:28:01 -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 16D87126DC2; Thu, 6 Apr 2017 09:27:47 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v36GPtfv038741; Thu, 6 Apr 2017 12:27:42 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 29nqtnvfap-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Apr 2017 12:27:42 -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 v36GRe5U023423; Thu, 6 Apr 2017 12:27:42 -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 v36GRWAi023231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Apr 2017 12:27:37 -0400 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Thu, 6 Apr 2017 16:27:21 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 v36GRKJP013552; Thu, 6 Apr 2017 11:27:20 -0500 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.255.15]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v36GRG0T013299; Thu, 6 Apr 2017 11:27:16 -0500 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-green.research.att.com (Postfix) with ESMTP id 3B87FE0705; Thu, 6 Apr 2017 12:26:59 -0400 (EDT) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Thu, 6 Apr 2017 12:27:15 -0400 From: "MORTON, ALFRED C (AL)" To: Kathleen Moriarty , Rifaat Shekh-Yusef CC: "secdir@ietf.org" , The IESG , "draft-mm-wg-effect-encrypt@ietf.org" Thread-Topic: SecDir review of draft-mm-wg-effect-encrypt-09 Thread-Index: AQHSrtXZi2RTsrw8gkCNPdA1d/1fpqG4tP0A///RrjA= Date: Thu, 6 Apr 2017 16:27:14 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF25F6AA27@njmtexg5.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: [73.178.187.36] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-06_14:, , 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-1702020001 definitions=main-1704060133 Archived-At: Subject: Re: [secdir] SecDir review of draft-mm-wg-effect-encrypt-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, 06 Apr 2017 16:28:03 -0000 SGkgS2F0aGxlZW4gYW5kIFJpZmFhdCwNCg0KaW5zdGVhZCBvZiANCi4uLiBmb3J3YXJkIHBhY2tl dHMgdG8gJ3RydXN0ZWQnIHRvb2xzLCAuLi4NCndlIGNvdWxkIHNheQ0KLi4uIGZvcndhcmQgcGFj a2V0cyB0byBTUC1jb250cm9sbGVkIHRvb2xzLA0KDQp3aGljaCBzZWVtcyBjb3JyZWN0IGZvciB0 aGlzIHNlY3Rpb246DQozLjEuMi4gIFNQIENvbnRlbnQgTW9uaXRvcmluZyBvZiBBcHBsaWNhdGlv bnMNCg0KQWwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBLYXRobGVl biBNb3JpYXJ0eSBbbWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tXQ0KPiBT ZW50OiBUaHVyc2RheSwgQXByaWwgMDYsIDIwMTcgMTE6MTAgQU0NCj4gVG86IFJpZmFhdCBTaGVr aC1ZdXNlZg0KPiBDYzogc2VjZGlyQGlldGYub3JnOyBUaGUgSUVTRzsgZHJhZnQtbW0td2ctZWZm ZWN0LWVuY3J5cHRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFNlY0RpciByZXZpZXcgb2YgZHJh ZnQtbW0td2ctZWZmZWN0LWVuY3J5cHQtMDkNCj4gDQo+IEhpIFJpZmFhdCwNCj4gDQo+IFRoYW5r cyBmb3IgeW91ciByZXZpZXchICBXZSBoYWQgIzEgcXVldWVkIHVwIGZvciB0aGUgbmV4dCByZXZp c2lvbi4NCj4gVHJ1c3RlZCBoYWQgc2luZ2xlIHF1b3RlcyBhcm91bmQgaXQgYmVjYXVzZSBpdCBp c24ndCB0aGUgdGVybSBvZiBhDQo+IHByb2R1Y3Qgb3Igd2VsbCBrbm93biB0ZXJtLCBidXQgdHJ1 c3RlZCBieSB0aGUgb3JnYW5pemF0aW9uLiAgSSBkb24ndA0KPiBsaWtlIHRoZSB3b3JkIHRydXN0 IGJlY2F1c2UgaXQgaXMgbG9hZGVkIGFuZCB1c2VkIGRpZmZlcmVudGx5IGJ5IG1hbnkuDQo+IElm IG90aGVycyB0aGluayB3ZSBzaG91bGQgcmVtb3ZlIHRoYXQgb3IgdGhlIFJGQyBlZGl0b3IsIHRo YXQncyBmaW5lLg0KPiANCj4gVGhhbmtzLA0KPiBLYXRobGVlbg0KPiANCj4gT24gVGh1LCBBcHIg NiwgMjAxNyBhdCA5OjAwIEFNLCBSaWZhYXQgU2hla2gtWXVzZWYNCj4gPHJpZmFhdC5pZXRmQGdt YWlsLmNvbT4gd3JvdGU6DQo+ID4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFy dCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncw0KPiA+IG9uZ29pbmcgZWZmb3J0IHRvIHJl dmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZQ0KPiA+IElFU0cu ICBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBv ZiB0aGUNCj4gPiBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5k IFdHIGNoYWlycyBzaG91bGQgdHJlYXQNCj4gPiB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55 IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCj4gPg0KPiA+IFN1bW1hcnk6IFJlYWR5IHdpdGgg bml0cw0KPiA+DQo+ID4gVGhlIGRvY3VtZW50IGRlc2NyaWJlcyBzZWN1cml0eSBhbmQgbWFuYWdl bWVudCBmdW5jdGlvbnMgdGhhdCBtaWdodCBiZQ0KPiA+IGltcGFjdGVkIGJ5IHRoZSBpbmNyZWFz ZWQgdXNlIG9mIGVuY3J5cHRpb24uDQo+ID4gVGhlIGdvYWwgb2YgdGhlIGRvY3VtZW50IGlzIHRv IG9ubHkgbGlzdCB0aGUgcG90ZW50aWFsIHByb2JsZW1zLCBub3QNCj4gdG8NCj4gPiBwcm9wb3Nl DQo+ID4gc29sdXRpb25zIHRvIHRoZXNlIHByb2JsZW1zLg0KPiA+DQo+ID4NCj4gPiBuaXRzOg0K PiA+DQo+ID4gMS4gVGhlIGRvY3VtZW50IHJlZmVycyB0byBhbiBBcHBlbmRpeCBpbiBtdWx0aXBs ZXMgcGxhY2VzLCB3aGljaCBpcw0KPiBub3cNCj4gPiBzZWN0aW9uIDcuDQo+ID4gMi4gUGFnZSAx OCwgc2Vjb25kIGxpbmU6IHRoZSB3b3JkICd0cnVzdGVkJyBoYXMgcXVvdGVzIGFyb3VuZCBpdDsg aXMNCj4gdGhlcmUgYQ0KPiA+IHJlYXNvbiBmb3IgdGhhdD8NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ ID4gIFJpZmFhdA0KPiA+DQo+ID4NCj4gDQo+IA0KPiANCj4gLS0NCj4gDQo+IEJlc3QgcmVnYXJk cywNCj4gS2F0aGxlZW4NCg== From nobody Thu Apr 6 09:52:04 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 1EDEE12420B; Thu, 6 Apr 2017 09:51:58 -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 6zvEgoTJzQHA; Thu, 6 Apr 2017 09:51:56 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::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 3D4FB1200C5; Thu, 6 Apr 2017 09:51:56 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id 21so41698344pgg.1; Thu, 06 Apr 2017 09:51:56 -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=XjXO3aUTBK2edSCOJgjzC1OfXOvuG59xxzTHw4uejBI=; b=DzSjp6isIx+9OpQlXeVmAM+woNzmNxSsm9ov94445SiTgqumCss6RhXlhLF9kC9Fem LznOoOb/jWWl4OhV5Q0yLIjGIQcqVZPYJ1eHj8a866Rj4p3M9+rR9z6ldl3Zbb8MXwcD ufrbP5J/Bt9XPpz+tJXMi/jcM3Zmi+ycv17Ts6tpzIKBZ3al6PQBODV5pHc0gY504IUE vj/CceLgoIzp7u+4SjoajzqFIH64y3Tnt3RDm1OxoHw2fCbYQwO8aHbufOkWAoQEhWyU E/IJNQJSlzDZqqCiYZl1D5MURW6lQkaQ+xMv6TKXHpMRadxG4Cx+02I77v7PXKZEwsfg L6gg== 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=XjXO3aUTBK2edSCOJgjzC1OfXOvuG59xxzTHw4uejBI=; b=n8PCI6UqWmJdXkH8intQ7uirwSp/rAjgANlGzQ12ez5Ve0lVpzzNmVjQxLXizRNPSr V06MvHf9KE+ZiziUNw6Zdc4jkiLgeS/KC3EvhFeIikM3o4rqpOO5qXnuqP08IxqeDAaY 2XXo5QghUvWpOxqdaRx0VubbXJG0gREN9AooOfWfdSOfI72iXs9vySCGNMcJW600eMdP 1Hr9N+Zoh161z1MIoSnxs9AwCjIVu0wImOp+Roi8bTy0WkHBpj4SgjIcol/SmGGuykny OyrMFAxlfRGYBJR1m6+WWyEDiLC2nGvMDow83WMGXyQX+DomiuJauzhIVfKaduN09+aj M4tg== X-Gm-Message-State: AFeK/H3A7P1ud2dEfaqE/OGuCNVvVhxRCvBK3Dp32AyoWcUVDhC2RAIla5QifeTBSqIEOQf4kysQrbUuatPl9w== X-Received: by 10.99.126.13 with SMTP id z13mr35156798pgc.158.1491497515890; Thu, 06 Apr 2017 09:51:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.128.141 with HTTP; Thu, 6 Apr 2017 09:51:15 -0700 (PDT) In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF25F6AA27@njmtexg5.research.att.com> References: <4D7F4AD313D3FC43A053B309F97543CF25F6AA27@njmtexg5.research.att.com> From: Kathleen Moriarty Date: Thu, 6 Apr 2017 12:51:15 -0400 Message-ID: To: "MORTON, ALFRED C (AL)" Cc: Rifaat Shekh-Yusef , "secdir@ietf.org" , The IESG , "draft-mm-wg-effect-encrypt@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [secdir] SecDir review of draft-mm-wg-effect-encrypt-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, 06 Apr 2017 16:51:58 -0000 Hi Al, On Thu, Apr 6, 2017 at 12:27 PM, MORTON, ALFRED C (AL) wrote: > Hi Kathleen and Rifaat, > > instead of > ... forward packets to 'trusted' tools, ... > we could say > ... forward packets to SP-controlled tools, > I do like that better as it gets directly to the point of what the contributor intended, I think. > which seems correct for this section: > 3.1.2. SP Content Monitoring of Applications I'll make the update as I think I have the running draft with the appendix reference changes. Thank you! > > Al > >> -----Original Message----- >> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] >> Sent: Thursday, April 06, 2017 11:10 AM >> To: Rifaat Shekh-Yusef >> Cc: secdir@ietf.org; The IESG; draft-mm-wg-effect-encrypt@ietf.org >> Subject: Re: SecDir review of draft-mm-wg-effect-encrypt-09 >> >> Hi Rifaat, >> >> Thanks for your review! We had #1 queued up for the next revision. >> Trusted had single quotes around it because it isn't the term of a >> product or well known term, but trusted by the organization. I don't >> like the word trust because it is loaded and used differently by many. >> If others think we should remove that or the RFC editor, that's fine. >> >> Thanks, >> Kathleen >> >> On Thu, Apr 6, 2017 at 9:00 AM, Rifaat Shekh-Yusef >> 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. >> > >> > Summary: Ready with nits >> > >> > The document describes security and management functions that might be >> > impacted by the increased use of encryption. >> > The goal of the document is to only list the potential problems, not >> to >> > propose >> > solutions to these problems. >> > >> > >> > nits: >> > >> > 1. The document refers to an Appendix in multiples places, which is >> now >> > section 7. >> > 2. Page 18, second line: the word 'trusted' has quotes around it; is >> there a >> > reason for that? >> > >> > Regards, >> > Rifaat >> > >> > >> >> >> >> -- >> >> Best regards, >> Kathleen -- Best regards, Kathleen From nobody Thu Apr 6 10:00:11 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 297A6126CD8; Thu, 6 Apr 2017 10:00:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rich Salz To: Cc: draft-ietf-mmusic-dtls-sdp.all@ietf.org, ietf@ietf.org, mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149149800009.21962.16244679330016077024@ietfa.amsl.com> Date: Thu, 06 Apr 2017 10:00:00 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-mmusic-dtls-sdp-22 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, 06 Apr 2017 17:00:00 -0000 Reviewer: Rich Salz Review result: Has Nits The term "ufrag" should be explained, or at least have a reference on its first use. It seems important :) I think the "fingerprint" reference should be moved up to the bullet list in section 4, from the bullet list in 5.1 Sec 4 uses the term "cryptographic random function" which is not a common security term. (See https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator) I would just say "strong random function"; it's the number of random bits that counts. Or use CSPRNG as the term. In Sec 9, it seems like quoting all the old text is way too verbose. I would just say "replace with the following NEW TEXT" If it's not replacing an entire section, then say "the nnn paragraphs starting with xxxxx" or similar construct. From nobody Thu Apr 6 11:05:37 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 0CE401200C1; Thu, 6 Apr 2017 11:05:31 -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 WeKE9C65S0uF; Thu, 6 Apr 2017 11:05:29 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5BD912426E; Thu, 6 Apr 2017 11:05:28 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id z204so50115813vkd.1; Thu, 06 Apr 2017 11:05:28 -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=EwKKSCt1lg8HDGqCORZE2YmfYQdBZpL8JB/7v709AVg=; b=k8FqeTbZXQ0Jsu/rYEHlpMkM0sJkS2BaJ4Ybu2Z5jxTnEMh1KGSxUFLFJsNdwEYf2u 6FFKl5GYhbRQw3yCuTuZQ+9OGPsLNaV9N5yPHqEI13l709pOethqKgel10xWA3jmTFN4 G51J81aXYepnihzPel1Ycl7xzVOtBvymnZqZPFxUIu5s1N8hBxkULUMKGdPzzKUqcH28 sptsHmhEjJtw/ld4akoRgLHD/MhKJVnydYPq3kNa8C2OlrUNVeiR/NwVG9MTDtRhwUlY z/z3nmkv8ndYZ3j+IQwU4fRT5prZnetMsScehCpRQQGBeCx8euZ+WIWpiJQADSzL/fCx 7Tkg== 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=EwKKSCt1lg8HDGqCORZE2YmfYQdBZpL8JB/7v709AVg=; b=gkM7SDhYnDAmz/W4SqIYi/tIajOTCegM5jhkG0dc8LKKsVybydch8WuR/WF7BmyJcW ts5i80c6uHvOm38+zFD8Twf35QuKxIypW2cqHVqNHYp6oM+e5aQwVc1f1Hd8/ChSLQMP eRmHn+jFlIRVD9lEe0H0SmqYNDV7411HFYNCsBxuLX5Xm6VtGWWFPuUY/XbYALRnH7e7 NDG1nL3vuEaGdw4Rm3G/3maG9K1RYjnOP102zH9jzB2KL71oIsKv3aPIJt7MEmmYuITP XyN8eAmAK7VReJAqVc+yoY9TmWyE0h3C9EsURHqYbekL+CX63yfZwcIIUBozG0dXY786 e1dA== X-Gm-Message-State: AFeK/H3wixeAgjac9pOZiIQ8ZKySWnp/sTEC0qi+OoGamp90WutxjmfZ0JNFnu01q+hvhUcc9ESVYBf9+otyJg== X-Received: by 10.176.67.133 with SMTP id l5mr18239977ual.73.1491501927896; Thu, 06 Apr 2017 11:05:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.85.82 with HTTP; Thu, 6 Apr 2017 11:05:27 -0700 (PDT) In-Reply-To: References: <4D7F4AD313D3FC43A053B309F97543CF25F6AA27@njmtexg5.research.att.com> From: Rifaat Shekh-Yusef Date: Thu, 6 Apr 2017 14:05:27 -0400 Message-ID: To: Kathleen Moriarty Cc: "MORTON, ALFRED C (AL)" , "secdir@ietf.org" , The IESG , "draft-mm-wg-effect-encrypt@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c09dc5a982252054c835a0b Archived-At: Subject: Re: [secdir] SecDir review of draft-mm-wg-effect-encrypt-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, 06 Apr 2017 18:05:31 -0000 --94eb2c09dc5a982252054c835a0b Content-Type: text/plain; charset=UTF-8 Sounds good to me. Regards, Rifaat On Thu, Apr 6, 2017 at 12:51 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hi Al, > > On Thu, Apr 6, 2017 at 12:27 PM, MORTON, ALFRED C (AL) > wrote: > > Hi Kathleen and Rifaat, > > > > instead of > > ... forward packets to 'trusted' tools, ... > > we could say > > ... forward packets to SP-controlled tools, > > > > I do like that better as it gets directly to the point of what the > contributor intended, I think. > > > which seems correct for this section: > > 3.1.2. SP Content Monitoring of Applications > > I'll make the update as I think I have the running draft with the > appendix reference changes. > > Thank you! > > > > Al > > > >> -----Original Message----- > >> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] > >> Sent: Thursday, April 06, 2017 11:10 AM > >> To: Rifaat Shekh-Yusef > >> Cc: secdir@ietf.org; The IESG; draft-mm-wg-effect-encrypt@ietf.org > >> Subject: Re: SecDir review of draft-mm-wg-effect-encrypt-09 > >> > >> Hi Rifaat, > >> > >> Thanks for your review! We had #1 queued up for the next revision. > >> Trusted had single quotes around it because it isn't the term of a > >> product or well known term, but trusted by the organization. I don't > >> like the word trust because it is loaded and used differently by many. > >> If others think we should remove that or the RFC editor, that's fine. > >> > >> Thanks, > >> Kathleen > >> > >> On Thu, Apr 6, 2017 at 9:00 AM, Rifaat Shekh-Yusef > >> 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. > >> > > >> > Summary: Ready with nits > >> > > >> > The document describes security and management functions that might be > >> > impacted by the increased use of encryption. > >> > The goal of the document is to only list the potential problems, not > >> to > >> > propose > >> > solutions to these problems. > >> > > >> > > >> > nits: > >> > > >> > 1. The document refers to an Appendix in multiples places, which is > >> now > >> > section 7. > >> > 2. Page 18, second line: the word 'trusted' has quotes around it; is > >> there a > >> > reason for that? > >> > > >> > Regards, > >> > Rifaat > >> > > >> > > >> > >> > >> > >> -- > >> > >> Best regards, > >> Kathleen > > > > -- > > Best regards, > Kathleen > --94eb2c09dc5a982252054c835a0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sounds good to me.

Regards,
= =C2=A0Rifaat


On Thu, Apr 6, 2017 at 12:51 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
Hi Al,

On Thu, Apr 6, 2017 at 12:27 PM, MORTON, ALFRED C (AL) <acmorton@att.com> wrote:
> Hi Kathleen and Rifaat,
>
> instead of
> ... forward packets to 'trusted' tools, ...
> we could say
> ... forward packets to SP-controlled tools,
>

I do like that better as it gets directly to the point of what the contributor intended, I think.

> which seems correct for this section:
> 3.1.2.=C2=A0 SP Content Monitoring of Applications

I'll make the update as I think I have the running draft with th= e
appendix reference changes.

Thank you!
>
> Al
>
>> -----Original Message-----
>> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]
>> Sent: Thursday, April 06, 2017 11:10 AM
>> To: Rifaat Shekh-Yusef
>> Cc: secdir@ietf.org; The IE= SG; draft-mm-wg-effe= ct-encrypt@ietf.org
>> Subject: Re: SecDir review of draft-mm-wg-effect-encrypt-09
>>
>> Hi Rifaat,
>>
>> Thanks for your review!=C2=A0 We had #1 queued up for the next rev= ision.
>> Trusted had single quotes around it because it isn't the term = of a
>> product or well known term, but trusted by the organization.=C2=A0= I don't
>> like the word trust because it is loaded and used differently by m= any.
>> If others think we should remove that or the RFC editor, that'= s fine.
>>
>> Thanks,
>> Kathleen
>>
>> On Thu, Apr 6, 2017 at 9:00 AM, Rifaat Shekh-Yusef
>> <rifaat.ietf@gmail.com= > wrote:
>> > I have reviewed this document as part of the security directo= rate's
>> > ongoing effort to review all IETF documents being processed b= y the
>> > IESG.=C2=A0 These comments were written primarily for the ben= efit of the
>> > security area directors.=C2=A0 Document editors and WG chairs= should treat
>> > these comments just like any other last call comments.
>> >
>> > Summary: Ready with nits
>> >
>> > The document describes security and management functions that= might be
>> > impacted by the increased use of encryption.
>> > The goal of the document is to only list the potential proble= ms, not
>> to
>> > propose
>> > solutions to these problems.
>> >
>> >
>> > nits:
>> >
>> > 1. The document refers to an Appendix in multiples places, wh= ich is
>> now
>> > section 7.
>> > 2. Page 18, second line: the word 'trusted' has quote= s around it; is
>> there a
>> > reason for that?
>> >
>> > Regards,
>> >=C2=A0 Rifaat
>> >
>> >
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen



--

Best regards,
Kathleen

--94eb2c09dc5a982252054c835a0b-- From nobody Thu Apr 6 11:37: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 38B2E12741D; Thu, 6 Apr 2017 11:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLeYD19iKbOu; Thu, 6 Apr 2017 11:37:07 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 86DE2127775; Thu, 6 Apr 2017 11:37:06 -0700 (PDT) X-AuditID: c1b4fb2d-dadfe700000033e1-4c-58e68ace1958 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id F4.C3.13281.ECA86E85; Thu, 6 Apr 2017 20:37:04 +0200 (CEST) Received: from ESESSMB102.ericsson.se ([169.254.2.218]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0339.000; Thu, 6 Apr 2017 20:37:02 +0200 From: Christer Holmberg To: Rich Salz , "secdir@ietf.org" CC: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , "ietf@ietf.org" , "mmusic@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-mmusic-dtls-sdp-22 Thread-Index: AQHSrvc7Q+l4Ggm5cUSsh7p7Glw+qqG4q/Pg Date: Thu, 6 Apr 2017 18:37:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB51809@ESESSMB102.ericsson.se> References: <149149800009.21962.16244679330016077024@ietfa.amsl.com> In-Reply-To: <149149800009.21962.16244679330016077024@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbE9SvdC17MIg2NtWhY77u5gs3i2cT6L xdTlj1ks/m/pZLH4sPAhiwOrx+QjC5g9liz5yRTAFMVlk5Kak1mWWqRvl8CVcfbfBJaCV0IV 525MZ25gXCPUxcjJISFgItHQ/Zili5GLQ0hgPaPE+mtH2SCcxYwSB16/Ye1i5OBgE7CQ6P6n DdIgIuAqsa33MzNIDbPAQkaJ72c/MYIkhIESk08eYIQocpNY8eAkG4RtJLH08ipmEJtFQEVi z+yHzCAzeQV8JX5OB5spJOAi8f9uHyuIzQk0prd9B5jNKCAm8f3UGiYQm1lAXOLWk/lMEEcL SCzZc54ZwhaVePn4HyuErSSx9vB2FpDxzAKaEut36UO0KkpM6X7IDmLzCghKnJz5hGUCo+gs JFNnIXTMQtIxC0nHAkaWVYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiBEXRwy2/dHYyrXzse YhTgYFTi4U348SRCiDWxrLgy9xCjBAezkgiv+nugEG9KYmVValF+fFFpTmrxIUZpDhYlcV6H fRcihATSE0tSs1NTC1KLYLJMHJxSDYzafiEL/xjv2ey6MOeOtVybC8OW1eWnHzvdZj9+++zs G7M2x+xcYnMoui/zvUKcyMsX6455fb6n7z6nwDn/0JHv9r3/Hdjq/1248K9l8up625nFak2b 4w6E6Kmc1ubfayO6Zcuiee7yq4xCV82Xivcq+n06VL3U6M1TUaMFLqbSey6+7fedNrlSiaU4 I9FQi7moOBEAilxX65wCAAA= Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-mmusic-dtls-sdp-22 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, 06 Apr 2017 18:37:09 -0000 SGkgUmljaCwNCg0KVGhhbmtzIGZvciB5b3VyIHJldmlldyENCg0KTm90ZSB0aGF0LCBiYXNlZCBv biBkaXNjdXNzaW9ucyBpbiBDaGljYWdvLCB0aGUgZHJhZnQgd2lsbCBiZSBleHRlbmRlZCB0byBh bHNvIGNvdmVyIFRMUyBhc3NvY2lhdGlvbnMuIFNvLCBpdCBtYXkgZW5kIHVwIG9uIHlvdXIgdGFi bGUgYWdhaW4gYXQgc29tZSBwb2ludCA6KQ0KDQpOZXZlciB0aGUgbGVzcywgSSB3aWxsIHJlcGx5 IHRvIHlvdXIgY29tbWVudHMsIGJlY2F1c2Ugc29tZSBvZiB0aGVtIGFyZSBub3QgcmVsYXRlZCB0 byB0aGUgY2hhbmdlLg0KDQo+UmV2aWV3ZXI6IFJpY2ggU2Fseg0KPlJldmlldyByZXN1bHQ6IEhh cyBOaXRzDQo+DQo+VGhlIHRlcm0gInVmcmFnIiBzaG91bGQgYmUgZXhwbGFpbmVkLCBvciBhdCBs ZWFzdCBoYXZlIGEgcmVmZXJlbmNlIG9uIGl0cyBmaXJzdCB1c2UuICBJdCBzZWVtcyBpbXBvcnRh bnQgOikNCg0KSSB3aWxsIGFkZCBhIHJlZmVyZW5jZSB0byBkcmFmdC01MjQ1YmlzLg0KDQo+SSB0 aGluayB0aGUgImZpbmdlcnByaW50IiByZWZlcmVuY2Ugc2hvdWxkIGJlIG1vdmVkIHVwIHRvIHRo ZSBidWxsZXQgbGlzdCBpbiBzZWN0aW9uIDQsIGZyb20gdGhlIGJ1bGxldCBsaXN0IGluIDUuMQ0K DQpJIGFtIG5vdCBzdXJlLiBUaGUgYnVsbGV0IGxpc3QgaW4gc2VjdGlvbiA0IHRhbGtzIGFib3V0 IHRoZSBmaW5nZXJwcmludCBpbiBnZW5lcmFsLCB3aGlsZSB0aGUgYnVsbGV0IGxpc3QgaW4gNS4x IHRhbGtzIGFib3V0IHRoZSBmaW5nZXJwcmludCBhdHRyaWJ1dGUuDQoNCj5TZWMgNCB1c2VzIHRo ZSB0ZXJtICJjcnlwdG9ncmFwaGljIHJhbmRvbSBmdW5jdGlvbiIgd2hpY2ggaXMgbm90IGEgY29t bW9uIHNlY3VyaXR5IHRlcm0uICAoU2VlDQo+aHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kv Q3J5cHRvZ3JhcGhpY2FsbHlfc2VjdXJlX3BzZXVkb3JhbmRvbV9udW1iZXJfZ2VuZXJhdG9yKQ0K Pkkgd291bGQganVzdCBzYXkgInN0cm9uZyByYW5kb20gZnVuY3Rpb24iOyBpdCdzIHRoZSBudW1i ZXIgb2YgcmFuZG9tIGJpdHMgdGhhdCBjb3VudHMuICBPciB1c2UgQ1NQUk5HIGFzIHRoZSB0ZXJt Lg0KDQpJIHdpbGwgdXNlICJzdHJvbmcgcmFuZG9tIGZ1bmN0aW9uIi4NCg0KPkluIFNlYyA5LCBp dCBzZWVtcyBsaWtlIHF1b3RpbmcgYWxsIHRoZSBvbGQgdGV4dCBpcyB3YXkgdG9vIHZlcmJvc2Uu IA0KPkkgd291bGQganVzdCBzYXkgInJlcGxhY2Ugd2l0aCB0aGUgZm9sbG93aW5nIE5FVyBURVhU Ig0KPklmIGl0J3Mgbm90IHJlcGxhY2luZyBhbiBlbnRpcmUgc2VjdGlvbiwgdGhlbiBzYXkgInRo ZSBubm4gcGFyYWdyYXBocyBzdGFydGluZyB3aXRoIHh4eHh4IiBvciBzaW1pbGFyIGNvbnN0cnVj dC4NCg0KVGhpcyBjb21lcyB1cCBldmVyeXRoaW5nIGEgc2VjdGlvbiBpcyB1cGRhdGVkLiBTb21l IHBlb3BsZSBvbmx5IHdhbnQgdG8gdXBkYXRlZCBwYXJ0cywgd2hpbGUgb3RoZXJzIHdhbnQgdGhl IHdob2xlIHVwZGF0ZWQgc2VjdGlvbiAtIG5vIG1hdHRlciBob3cgbXVjaCBvciBsaXR0bGUgaGFz IGJlZW4gdXBkYXRlZC4gU28sIEknZCBsaWtlIHRvIGtlZXAgaXQgYXMgaXQgaXMuDQoNCk5vdGUs IGhvd2V2ZXIsIHRoYXQgYmFzZWQgb24gdGhlIGdlbi1hcnQgcmV2aWV3IEkgd2lsbCBwbGFjZSB0 aGUgdXBkYXRlcyBvZiBlYWNoIGluZGl2aWR1YWwgc2VjdGlvbiBpbiBhIHNlcGFyYXRlIHN1YiBz ZWN0aW9uIG9mIHRoZSBkcmFmdC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQo= From nobody Thu Apr 6 11:39: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 A32AE12949B; Thu, 6 Apr 2017 11:39:07 -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, 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 nh9lFdUhMNt8; Thu, 6 Apr 2017 11:39:05 -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 027A112941C; Thu, 6 Apr 2017 11:39:01 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v36IaV8C003449; Thu, 6 Apr 2017 19:38:57 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=W9wYQnNEMLT7AxPFEue4BiMpLKjygKMbW64GWvb7WjE=; b=Yg1cPPPQrjaXgWEI00gk7vjIdckqRyXWPB7gWj0Wp/VyZLfjSFdhkrcNSx+qjXiA8W4f 3zy5vVXDDcKr3PIjQ5vE0am3CAqk8oBdqJk0igexx1DhxO/aOcsOajrxvFFL7ePHSpg9 AKBiyxiTkC35GkTCG+h0SnLkEyaolg4Uld3gKU3y4eO1a7nNy8WKcv6/UQz0cO1e5Exf 0K4tfRnRGPogx22qlacuAdUA3j99gArBffzSOaulCHO07yFIdGKP8yvWwNGwvpfGRhWX 2E//+lWJfC28ny0ZSbPDa9Af+LmhLP6PU8rPIK0z/EJbAo3TBbBHL+xM7rRSJVOnH4SJ JA== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 29nrut0s7g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Apr 2017 19:38:56 +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 v36IZqV4015275; Thu, 6 Apr 2017 14:38:56 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 29j7hujnc6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 06 Apr 2017 14:38:56 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 6 Apr 2017 14:38:53 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Thu, 6 Apr 2017 14:38:53 -0400 From: "Salz, Rich" To: Christer Holmberg , "secdir@ietf.org" CC: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , "ietf@ietf.org" , "mmusic@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-mmusic-dtls-sdp-22 Thread-Index: AQHSrwTMt/3hOQnvJkaFTThgvFfUh6G4q8xQ Date: Thu, 6 Apr 2017 18:38:52 +0000 Message-ID: <4f01bce56f4c4bf7b9d800b70d8cf9f5@usma1ex-dag1mb1.msg.corp.akamai.com> References: <149149800009.21962.16244679330016077024@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CB51809@ESESSMB102.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB51809@ESESSMB102.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.153] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-06_14:, , 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-1702020001 definitions=main-1704060150 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-06_14:, , 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-1702020001 definitions=main-1704060150 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-mmusic-dtls-sdp-22 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, 06 Apr 2017 18:39:08 -0000 PiBOb3RlIHRoYXQsIGJhc2VkIG9uIGRpc2N1c3Npb25zIGluIENoaWNhZ28sIHRoZSBkcmFmdCB3 aWxsIGJlIGV4dGVuZGVkIHRvIGFsc28NCj4gY292ZXIgVExTIGFzc29jaWF0aW9ucy4gU28sIGl0 IG1heSBlbmQgdXAgb24geW91ciB0YWJsZSBhZ2FpbiBhdCBzb21lIHBvaW50IDopDQoNCjopDQog DQo+ID5JIHRoaW5rIHRoZSAiZmluZ2VycHJpbnQiIHJlZmVyZW5jZSBzaG91bGQgYmUgbW92ZWQg dXAgdG8gdGhlIGJ1bGxldA0KPiA+bGlzdCBpbiBzZWN0aW9uIDQsIGZyb20gdGhlIGJ1bGxldCBs aXN0IGluIDUuMQ0KPiANCj4gSSBhbSBub3Qgc3VyZS4gVGhlIGJ1bGxldCBsaXN0IGluIHNlY3Rp b24gNCB0YWxrcyBhYm91dCB0aGUgZmluZ2VycHJpbnQgaW4gZ2VuZXJhbCwNCj4gd2hpbGUgdGhl IGJ1bGxldCBsaXN0IGluIDUuMSB0YWxrcyBhYm91dCB0aGUgZmluZ2VycHJpbnQgYXR0cmlidXRl Lg0KDQpBaCwgb2theS4gIFBlcmhhcHMgc29tZSB3b3JkaW5nIGNhbiAgY2xlYXIgdGhhdCB1cD8g IE9yIG1heWJlICJmaW5nZXJwcmludCBhdHRyaWJ1dGUiIGFuZCwgd2hhdCwgImFzc29jaWF0aW9u IGZpbmdlcnByaW50IiA/DQoNClRoYW5rcyBmb3IgcmVhZGluZy4NCg== From nobody Thu Apr 6 16:43:24 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 5F7901296A8; Thu, 6 Apr 2017 16:43:17 -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 crCOzDrcwatp; Thu, 6 Apr 2017 16:43:15 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 CB29D129353; Thu, 6 Apr 2017 16:43:14 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id i34so49427719qtc.0; Thu, 06 Apr 2017 16:43:14 -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=XY6gqnWhTn9qsReIXslK7UK7sTSpxq4gnLVh5Zc6RyQ=; b=IXs8Tx0ub7UK0OB4YITtr333HwVVBQe3GylXLSEVj1PwjvwzjBP4yPJWycYN6XgyiV 0Dux0NuZLw8YKlmqTTQhcyr1B+lKR0j+UCDWA+5oumOOhCHnhFCOACUhHrL48zKMFX/C MDVfJRYQLbepcXP5Q0ixOZVsnjU+uMNNzIsxOdzo/LLUXqqxqHDF4hhKXqRqcRhJ9XFp nG7ezmuHbG7oDFhpaEwPIpIjY+vKDjyL3Rd0Sjx0tEdL67Y3qOi9D45ibQR82j45SP5l UYZAXnzr7fk0dIwQ66jcqFiSKwCY5nG87HMlTwwvLd5/UApEr00tmM9tQDTLsnGOy7RB J2cA== 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=XY6gqnWhTn9qsReIXslK7UK7sTSpxq4gnLVh5Zc6RyQ=; b=BDtmZi1F0N3528KOtvT+EfMAuOH1ErlzhX9ZdqtZUWn77b0oAE7U6te0++FFdJmLE7 KHUZEguSdYUdOcpQxO/2YVm2bY/adyiHlaNSXY63p6sajXpHLINTm2qkGzIAiLMOizh1 VHG9rp1TELy9F6B107rskp9KE3Y0mPuRkO5MJ39eT+xfUUzLVC9XlUCsemcXek+qAvZi MshnZh1xjuktJ1iDnQm91dn0BqFLzzTfVHcHyzxIIoWptKQOEQ60H3LqUEarnq3Zq374 tvk485vb+2qw1hjYN7BkKfyRyjPdimdSM3jSfQaHbPEp08wrYxm7B3i9rT1PSFPQ5Y+6 4k4Q== X-Gm-Message-State: AFeK/H1Ny1rS5Vlhy6/OKpPsNwZg69/0729VUzyGlQorqIyY/0r5U1SfZCaRsnj0rewDHQ1OwzdFLm5l16iJFA== X-Received: by 10.200.33.210 with SMTP id 18mr37476708qtz.159.1491522193900; Thu, 06 Apr 2017 16:43:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.203 with HTTP; Thu, 6 Apr 2017 16:43:13 -0700 (PDT) In-Reply-To: <1f550ddb-a279-ad2b-0599-c9ed2c95da09@nostrum.com> References: <149142527327.21912.5654685591478038284@ietfa.amsl.com> <1f550ddb-a279-ad2b-0599-c9ed2c95da09@nostrum.com> From: Martin Thomson Date: Fri, 7 Apr 2017 09:43:13 +1000 Message-ID: To: Robert Sparks Cc: "secdir@ietf.org" , draft-ietf-httpbis-encryption-encoding.all@ietf.org, "ietf@ietf.org" , HTTP Working Group Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-httpbis-encryption-encoding-08 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, 06 Apr 2017 23:43:17 -0000 On 7 April 2017 at 00:47, Robert Sparks wrote: >> >> That said, I think that the counter thing can be removed. We require >> 128 bits of salt, which is a space that is large enough to select >> randomly from in perpetuity. > > That would be my personal preference. Sold. https://github.com/httpwg/http-extensions/commit/8c31395609cdd2d1a91059fcbaa5a33fda622525 From nobody Fri Apr 7 09:59:04 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 4019112942F for ; Fri, 7 Apr 2017 09:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.086 X-Spam-Level: X-Spam-Status: No, score=-3.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 NEepVlPUBSUy for ; Fri, 7 Apr 2017 09:58:51 -0700 (PDT) Received: from nm19-vm6.bullet.mail.gq1.yahoo.com (nm19-vm6.bullet.mail.gq1.yahoo.com [98.136.217.29]) (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 4CB3C1296CE for ; Fri, 7 Apr 2017 09:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1491584325; bh=3EH4+WiYUx7P1eDdXjR64jVp3waqH6Y0SpaNbG6YShk=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=AYhRVGnH6WrQf+8dHEyE24iJBDnJLHMn6V3Z6mEog687JRbbaasWrk3QYrIOpgG8iZuxxCNeHgU/dNKCbNd0Sz2H2Mv5mFdAsUyskKV5PcatMXk295VYlxoCOusOXYYRe6EB1+82Vp2DZODN1TybqHlggeUYTBJ0YdMgGWn0bbhDZvnpSchhtpjmbFPv/rx3E4P+54Vb0fwY+PyN86x7oNKOWHpoX6nJW4+PEK+D/IBoElKTkTFEcitU/5RmbG8RHdd8ehrOrQ4Mm3vzF2E4PJOLw3rJWUw3rgJNsb/bURCyy1UtCcvrATODK/fFXYT8QzqJOfFQDTGUbnhllijsvA== Received: from [216.39.60.180] by nm19.bullet.mail.gq1.yahoo.com with NNFMP; 07 Apr 2017 16:58:45 -0000 Received: from [98.137.12.200] by tm16.bullet.mail.gq1.yahoo.com with NNFMP; 07 Apr 2017 16:58:45 -0000 Received: from [127.0.0.1] by omp1008.mail.gq1.yahoo.com with NNFMP; 07 Apr 2017 16:58:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 783573.76315.bm@omp1008.mail.gq1.yahoo.com X-YMail-OSG: jKjTSrsVM1kYyl8w.DlQPZkask7q85KK7u7jSY1n4kS6KWlrO3kzXrRUUJc0ifg hsskcZ0IVVo77GDy1jbXk_x0Yg0UkNtxmwJ1CV5H2.MTmcVeAl1G5WUmr3ZfagGWKBNuStupU3FZ mJdLn45pcHKrpd8t8uI.QsoRlfKYt6jiM9fs1YgcF2bHPH8eWUeZR94HJFajErt2dCqlU2WTaZZL 1uwDPI2TjrZ4Vp_QLDny1J4PYGUkhxBTvhUpeSNqiCKE16BwQoSHH3Vwo895tOj1Bnw0J1itlBCO SAAng9eVHZH.Im_uomjs6Bh.xHGPgBv7Txc9qcoa15hbu667JqHhZ73SnHNQSswibfwHuptJr78G fj19wCAfNdvpuSsbldoEvN5w86YKuL3hiWgCo3Ae1oa0TXHpWx5daLAyhnbPtrPPAHNGFNTPRSF. SgLVGbNkDU76wSDIWeAs8ZEpKbUFPNqlqOSUjd73z9tox8Oh3ZecUWlro7IudeUG03yYu97exwkb 6CEXTMeEBVj1QGXHiTcILTAYbeWVjWJ4qzsH5wZQI02bEDu4- Received: from jws300042.mail.gq1.yahoo.com by sendmailws111.mail.gq1.yahoo.com; Fri, 07 Apr 2017 16:58:45 +0000; 1491584325.401 Date: Fri, 7 Apr 2017 16:58:45 +0000 (UTC) From: Reply-To: To: , , , Tero Kivinen Message-ID: <1819867131.2096808.1491584325084@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <1819867131.2096808.1491584325084.ref@mail.yahoo.com> X-Mailer: WebService/1.1.9272 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-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, 07 Apr 2017 16:58:53 -0000 Tero, Thanks for your review. We have no problem with adding the text you suggest to the end of the appro= priate paragraph in section 3.4.2 > In ESP case there is no 5-tuple available, as there is no port numbers, a= nd that means that ESP flow should be > identified only by using SADDR, DADDR and PROTOC. The SPI numbers SHOULD = be ignored when considering what is the flow > over which PDM information is measured. Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 -------------------------------------------- On Thu, 4/6/17, Tero Kivinen wrote: Subject: Secdir review of draft-ietf-ippm-6man-pdm-option-09 To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ippm-6man-pdm-option.all@ie= tf.org Date: Thursday, April 6, 2017, 3:58 AM =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.=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. =20 This is rereview of the performance and diagnostic metrics destination option document, and this version is much better than the previous one. The security considerations and the default settings are better now. =20 I have one nit about the document. In the section 3.4.2 it talks about putting PDM header outside the ESP, and says that: =20 =C2=A0 As a completely new IP packet will be made, it means that PDM =C2=A0 information for that packet does not contain any information from the =C2=A0 inner packet, i.e. the PDM information will NOT be based on the =C2=A0 transport layer (TCP, UDP, etc) ports etc in the inner header, but =C2=A0 will be specific to the ESP flow.=20 =20 This is fine, but it should note, that in this case there is no 5-tuple available, as there is no SPORT or DPORT. With PDM option outside the ESP header, the system should use SADDR, DADDR and PROTC to identify the flow. =20 In addition to that it could use the SPI pair to identify the flow. The problem with ESP is that there is really two unidirectional flows, i.e. one flow from node A to node B with SPI of X, and another flow from node B to node A with SPI of Y. Only one SPI value is stored in the packet, and it is not possible to know from the outside which SPI number X matches the SPI number Y, in case there are multiple ESP SAs between the peers. =20 In case the PDM option processing is integrated to the ESP, then the PDM processing could consider the two unidirectional ESP flow as one bi-directional ESP flow, and combine the PDM information for them. The problem is that if PDM processing is not integrated in the ESP, it does not know the SPI numbers that form this pair, and if one end does this and other end does not (because its PDM processing is not integrated with ESP) then information not be that useful.=20 =20 Because of this it is be better just to say that we do not use SPI numbers when creating the flows, meaning we combined all ESP SAs between the peers to one flow. This means that we will simply use SADDR, DADDR and PROTC as selectors for the PDM flow. =20 If there is multiple ESP SAs between the peers, the IPsec users its own policy rules to pick which traffic ends up in which ESP SA, thus it is completely possible that one TCP stream from host behind the IPsec gateway will be split in multiple ESP SAs. If using combined PDM statistics for all ESP traffic, then it does not matter how the IPsec splits traffic over multiple tunnels. =20 So I think it could be good idea to add text like this to end of the paragraph above in section 3.4.2: =20 =C2=A0=C2=A0=C2=A0 In ESP case there is no 5-tuple available, as there is no =C2=A0=C2=A0=C2=A0 port numbers, and that means that ESP flow should be =C2=A0=C2=A0=C2=A0 identified only by using SADDR, DADDR and PROTOC. The SPI =C2=A0=C2=A0=C2=A0 numbers SHOULD be ignored when considering what is the flow =C2=A0=C2=A0=C2=A0 over which PDM information is measured. =20 In summary I think this document is ready with nits.=20 --=20 kivinen@iki.fi =20 From nobody Mon Apr 10 07:03: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 83AA0120046; Mon, 10 Apr 2017 07:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 S0Mpe5Aq7_y8; Mon, 10 Apr 2017 07:03:19 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2AF1128BB6; Mon, 10 Apr 2017 07:03:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.37,182,1488841200"; d="scan'208,217";a="268500973" Received: from demeter.inrialpes.fr ([194.199.28.3]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Apr 2017 16:03:16 +0200 From: Vincent Roca Content-Type: multipart/alternative; boundary="Apple-Mail=_ABD052CC-C615-4464-91A5-3687079AF97F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <7B34A968-7AC9-4CBA-9F84-61AB90EDF65F@inria.fr> Date: Mon, 10 Apr 2017 16:03:16 +0200 To: IESG , secdir@ietf.org, draft-ietf-rtgwg-yang-key-chain.all@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [secdir] Secdir review of draft-ietf-rtgwg-yang-key-chain-17 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, 10 Apr 2017 14:03:27 -0000 --Apple-Mail=_ABD052CC-C615-4464-91A5-3687079AF97F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, I have reviewed this document as part of the security directorate=E2=80=99= 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 ** Question: when saying: "When configured, the key-strings can be encrypted using the AES = Key Wrap algorithm" you do not provide any recommendation. I understand it is possible, = but is there any good reason to recommend it or do you believe the NETCONF access control = feature is sufficient? Are there environments where recommending it would be meaningful? I'd = like to have more information. This is a bit surprising when I compare with last paragraph where = keys are RECOMMENDED to be encrypted when stored within network devices. ** Minor comment: I don't see any good reason to separate paragraphs 2 = and 4. Other comments: ** section 1.2: it says: " o Brackets "[" and "]" enclose list keys." There may be a confusion with the term "keys" here (i.e., something = different from a cryptographic key). For instance, in section 3.3: | +--rw key-chain* [name] name is not a cryptographic key. ** section 2.2: there's something I don't understand. It says: 3. When the send lifetime of the new key becomes valid, the network devices within the domain of key chain will start sending the = new key. I have the feeling you mean that this new key will start to be used = for transmissions (instead of "start sending the new key"). Did I misunderstood = something? Cheers, Vincent --Apple-Mail=_ABD052CC-C615-4464-91A5-3687079AF97F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,

I have reviewed this document as part of the = security directorate=E2=80=99s 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

** = Question: when saying:

        "When configured, the key-strings = can be encrypted using the AES Key Wrap algorithm"

   you do not = provide any recommendation. I understand it is possible, but is there = any good
   reason to recommend it or do = you believe the NETCONF access control feature is sufficient?
   Are there environments where recommending it = would be meaningful? I'd like to have more
  =  information.
   This is a bit = surprising when I compare with last paragraph where keys are = RECOMMENDED
   to be encrypted when = stored within network devices.


** = Minor comment: I don't see any good reason to separate paragraphs 2 and = 4.


Other comments:

** section 1.2: it says:
        " o  Brackets "[" and "]" = enclose list keys."
   There may be a = confusion with the term "keys" here (i.e., something different = from
   a cryptographic key).

   For = instance, in section 3.3:
      =   |  +--rw key-chain* [name]
  =  name is not a cryptographic key.


** = section 2.2: there's something I don't understand. It says:
    3.  When the send lifetime of the new key = becomes valid, the network
      =   devices within the domain of key chain will start sending the = new
        key.

  I have the = feeling you mean that this new key will start to be used for = transmissions
  (instead of "start sending the = new key"). Did I misunderstood something?


Cheers,

  Vincent



= --Apple-Mail=_ABD052CC-C615-4464-91A5-3687079AF97F-- From nobody Mon Apr 10 07:51:18 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 9D80F120725; Mon, 10 Apr 2017 07:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 cb_UoAXcneVM; Mon, 10 Apr 2017 07:51:07 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDBF4129434; Mon, 10 Apr 2017 07:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13517; q=dns/txt; s=iport; t=1491835866; x=1493045466; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xv9KGO/1QjuTPDtWTxgup/32CtVYDpX8IDykBJ48KIM=; b=VSE7jdDcB9shzltPJbE6tpawuZeRPWCddp5onbF6+N1N3P2CLDSNaaMc /2k/ijKXftlONMITZ3s4hLXJJ7x9P5LymeUqoCASA0Kx+e7G6OtQ/RAOK AXu4SNICGFZ4LWq+WWLVfgIJkHH5vAEok4RTsFCDMXzTaNmdbQlkNf1CA M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAQB5mutY/4gNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm46K4FsB41ykUaIGogJhTSCD4YkAoNfPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQN5EAIBCBEDAQIZDwchERQJCAIEAQ0FiXcDFas0hygNgy0BAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEdi0CCUYIlFgIWhRcFiSyGPkGFdYYgOwGOG4Q9g1+NYos?= =?us-ascii?q?AiH8BHziBBVsVQYRbHIFjdYhSgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,182,1488844800"; d="scan'208,217";a="410024177" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Apr 2017 14:51:05 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v3AEp5EX024820 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Apr 2017 14:51:05 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 10 Apr 2017 10:51:04 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Mon, 10 Apr 2017 10:51:04 -0400 From: "Acee Lindem (acee)" To: Vincent Roca , IESG , "secdir@ietf.org" , "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-rtgwg-yang-key-chain-17 Thread-Index: AQHSsgOCIbru9yr36U22nYG50kP+YKG+r7UA Date: Mon, 10 Apr 2017 14:51:04 +0000 Message-ID: References: <7B34A968-7AC9-4CBA-9F84-61AB90EDF65F@inria.fr> In-Reply-To: <7B34A968-7AC9-4CBA-9F84-61AB90EDF65F@inria.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.197] Content-Type: multipart/alternative; boundary="_000_D5111166A8060aceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-rtgwg-yang-key-chain-17 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, 10 Apr 2017 14:51:09 -0000 --_000_D5111166A8060aceeciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Vincent, Thanks for your review. From: Vincent Roca > Date: Monday, April 10, 2017 at 10:03 AM To: IESG >, "secdir@ietf.org" >, "draft-ietf-rtgwg= -yang-key-chain.all@ietf.org" > Cc: Vincent Roca > Subject: Secdir review of draft-ietf-rtgwg-yang-key-chain-17 Resent-From: > Resent-To: Acee Lindem >, Jeffrey Zha= ng >, Derek Yeung >, Yingzhen Qu >, Ing-Wher Chen >, >, Jeff Tantsura >, >, Deborah Brunga= rd >, Alia Atlas >, Jeff Tantsura > Resent-Date: Monday, April 10, 2017 at 10:03 AM Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: ready with nits ** Question: when saying: "When configured, the key-strings can be encrypted using the AES Ke= y Wrap algorithm" you do not provide any recommendation. I understand it is possible, but = is there any good reason to recommend it or do you believe the NETCONF access control feat= ure is sufficient? Are there environments where recommending it would be meaningful? I'd li= ke to have more information. This is a bit surprising when I compare with last paragraph where keys a= re RECOMMENDED to be encrypted when stored within network devices. This was added after a conversation with Brian Weis who I believe is also o= n the directorate. At this time, we didn't avail NCAM. As one would surmise= , it was for additional security for the key strings themselves. I'm not op= posed to removing the feature completely since no one has implemented it an= d it is somewhat unwieldy to have to distribute the key-encryption password= out-of-band. ** Minor comment: I don't see any good reason to separate paragraphs 2 and = 4. Where? Other comments: ** section 1.2: it says: " o Brackets "[" and "]" enclose list keys." There may be a confusion with the term "keys" here (i.e., something diff= erent from a cryptographic key). For instance, in section 3.3: | +--rw key-chain* [name] name is not a cryptographic key. This is pretty much boiler plate text for YANG model trees. I guess I could= add the statement: "These YANG list keys should not be confused with the key-chain keys." ** section 2.2: there's something I don't understand. It says: 3. When the send lifetime of the new key becomes valid, the network devices within the domain of key chain will start sending the new key. I have the feeling you mean that this new key will start to be used for t= ransmissions (instead of "start sending the new key"). Did I misunderstood something? Absolutely, I will correct this. Thanks, Acee Cheers, Vincent --_000_D5111166A8060aceeciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Vincent, 

Thanks for your review. 

From: Vincent Roca <vincent.roca@inria.fr>
Date: Monday, April 10, 2017 at 10:= 03 AM
To: IESG <iesg@ietf.org>, "= secdir@ietf.org" <secdir@iet= f.org>, "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" <draft-= ietf-rtgwg-yang-key-chain.all@ietf.org>
Cc: Vincent Roca <vincent.roca@inria.fr>
Subject: Secdir review of draft-iet= f-rtgwg-yang-key-chain-17
Resent-From: <alias-bounces@ietf.org>
Resent-To: Acee Lindem <acee@cisco.com>, Jeffrey Zhang <zzhang@juniper.net>, Derek Yeung <= ;derek@arrcus.com>, Yingzhen Qu <yingzhen.qu@huaw= ei.com>, Ing-Wher Chen <Ing-Wher_Chen@jabil.com>, <chrisbowers.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com= >, <aretana@cisco.com>, D= eborah Brungard <db3546@att.com>= ;, Alia Atlas <akatlas@gmail.com>, Jeff Tantsura <jefftant.ietf= @gmail.com>
Resent-Date: Monday, April 10, 2017= at 10:03 AM

Hello,

I have reviewed this document as part of the security directorate’s o= ngoing
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

** Question: when saying:

        "When configured, the key-= strings can be encrypted using the AES Key Wrap algorithm"

   you do not provide any recommendation. I under= stand it is possible, but is there any good
   reason to recommend it or do you believe the N= ETCONF access control feature is sufficient?
   Are there environments where recommending it w= ould be meaningful? I'd like to have more
   information.
   This is a bit surprising when I compare with l= ast paragraph where keys are RECOMMENDED
   to be encrypted when stored within network dev= ices.

This was added after a conversation with Brian Weis who I believe is a= lso on the directorate. At this time, we didn’t avail NCAM. As one wo= uld surmise, it was for additional security for the key strings themselves.= I’m not opposed to removing the feature completely since no one has implemented it and it is somewhat unwieldy to = have to distribute the key-encryption password out-of-band. 



** Minor comment: I don't see any good reason to separate p= aragraphs 2 and 4.

Where? 


Other comments:

** section 1.2: it says:
        " o  Brackets "[= " and "]" enclose list keys."
   There may be a confusion with the term "k= eys" here (i.e., something different from
   a cryptographic key).

   For instance, in section 3.3:
        |  +--rw key-chain* [n= ame]
   name is not a cryptographic key.

This is pretty much boiler plate text for YANG model trees. I guess I = could add the statement: 

“These YANG list keys should not be confused with the key-chain = keys."


** section 2.2: there's something I don't understand. It sa= ys:
    3.  When the send lifetime of the new ke= y becomes valid, the network
        devices within the domain of ke= y chain will start sending the new
        key.

  I have the feeling you mean that this new key will s= tart to be used for transmissions
  (instead of "start sending the new key"). = Did I misunderstood something?

Absolutely, I will correct this. 

Thanks,
Acee 


Cheers,

  Vincent



 --_000_D5111166A8060aceeciscocom_-- From nobody Mon Apr 10 08:02:45 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 3D87C129502; Mon, 10 Apr 2017 08:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 ZsKjHYSr37WL; Mon, 10 Apr 2017 08:02:36 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46EBA129508; Mon, 10 Apr 2017 08:02:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.37,182,1488841200"; d="scan'208,217";a="268511961" Received: from demeter.inrialpes.fr ([194.199.28.3]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Apr 2017 17:02:33 +0200 From: Vincent Roca Message-Id: <342F77BA-C6E4-4865-9D98-A2923312D80A@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_CFF57026-EE97-4E13-BB0D-345CD88C5EBC" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 10 Apr 2017 17:02:33 +0200 In-Reply-To: Cc: Vincent Roca , IESG , "secdir@ietf.org" , "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" , "Brian Weis (bew)" To: "Acee Lindem (acee)" References: <7B34A968-7AC9-4CBA-9F84-61AB90EDF65F@inria.fr> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-rtgwg-yang-key-chain-17 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, 10 Apr 2017 15:02:38 -0000 --Apple-Mail=_CFF57026-EE97-4E13-BB0D-345CD88C5EBC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Acee, > Thanks for your review.=20 You=E2=80=99re welcome. > ** Question: when saying: >=20 > "When configured, the key-strings can be encrypted using the = AES Key Wrap algorithm" >=20 > you do not provide any recommendation. I understand it is possible, = but is there any good > reason to recommend it or do you believe the NETCONF access control = feature is sufficient? > Are there environments where recommending it would be meaningful? = I'd like to have more > information. > This is a bit surprising when I compare with last paragraph where = keys are RECOMMENDED > to be encrypted when stored within network devices. >=20 > This was added after a conversation with Brian Weis who I believe is = also on the directorate. At this time, we didn=E2=80=99t avail NCAM. As = one would surmise, it was for additional security for the key strings = themselves. I=E2=80=99m not opposed to removing the feature completely = since no one has implemented it and it is somewhat unwieldy to have to = distribute the key-encryption password out-of-band.=20 I don=E2=80=99t have any opinion on the topic, just asked the question. Let=E2=80=99s see what our ADs think. > ** Minor comment: I don't see any good reason to separate paragraphs 2 = and 4. >=20 > Where?=20 I forgot to mention, sorry. I was considering the =C2=AB Security = Considerations =C2=BB section. Re-ordering those two closely related paragraphs could make sense. > Other comments: >=20 > ** section 1.2: it says: > " o Brackets "[" and "]" enclose list keys." > There may be a confusion with the term "keys" here (i.e., something = different from > a cryptographic key). >=20 > For instance, in section 3.3: > | +--rw key-chain* [name] > name is not a cryptographic key. >=20 > This is pretty much boiler plate text for YANG model trees. I guess I = could add the statement:=20 >=20 > =E2=80=9CThese YANG list keys should not be confused with the = key-chain keys." >=20 Yes, in an I-D entirely devoted to key exchanges, using the key term = with a totally different meaning is error prone (it took me some time to identify the = point). > ** section 2.2: there's something I don't understand. It says: > 3. When the send lifetime of the new key becomes valid, the = network > devices within the domain of key chain will start sending the = new > key. >=20 > I have the feeling you mean that this new key will start to be used = for transmissions > (instead of "start sending the new key"). Did I misunderstood = something? >=20 > Absolutely, I will correct this.=20 That was a big mistake then.=20 It=E2=80=99s nice to see that SecDir reviews are useful. Cheers, Vincent --Apple-Mail=_CFF57026-EE97-4E13-BB0D-345CD88C5EBC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello Acee,

Thanks for your = review. 

You=E2=80=99re welcome.


**= Question: when saying:

        "When configured, the key-strings = can be encrypted using the AES Key Wrap algorithm"

   you do not = provide any recommendation. I understand it is possible, but is there = any good
   reason to recommend it or do = you believe the NETCONF access control feature is sufficient?
   Are there environments where recommending it = would be meaningful? I'd like to have more
  =  information.
   This is a bit = surprising when I compare with last paragraph where keys are = RECOMMENDED
   to be encrypted when = stored within network = devices.

This was = added after a conversation with Brian Weis who I believe is also on the = directorate. At this time, we didn=E2=80=99t avail NCAM. As one would = surmise, it was for additional security for the key strings themselves. = I=E2=80=99m not opposed to removing the feature completely since no one = has implemented it and it is somewhat unwieldy to have to distribute the = key-encryption password out-of-band. 

I don=E2=80=99t have any opinion on the topic, = just asked the question.
Let=E2=80=99s see what our ADs = think.


** Minor comment: I = don't see any good reason to separate paragraphs 2 and = 4.
Where? 

I= forgot to mention, sorry. I was considering the =C2=AB Security = Considerations =C2=BB section.
Re-ordering those two = closely related paragraphs could make sense.


Other comments:

** section 1.2: it says:
    =     " o  Brackets "[" and "]" enclose list = keys."
   There may be a confusion with = the term "keys" here (i.e., something different from
   a cryptographic key).

   For instance, in section = 3.3:
        |  +--rw = key-chain* [name]
   name is not a = cryptographic key.

This is = pretty much boiler plate text for YANG model trees. I guess I could add = the statement: 

=E2=80=9CTh= ese YANG list keys should not be confused with the key-chain = keys."

<= br class=3D"">
Yes, in an I-D entirely devoted to key = exchanges, using the key term with a totally
different meaning = is error prone (it took me some time to identify the = point).


** section 2.2: = there's something I don't understand. It says:
 =   3.  When the send lifetime of the new key becomes valid, = the network
        devices = within the domain of key chain will start sending the new
        key.

  I have the feeling you mean that = this new key will start to be used for transmissions
  (instead of "start sending the new key"). Did I = misunderstood = something?

Absolutely,= I will correct this. 

That was a big mistake = then. 
It=E2=80=99s nice to see that SecDir reviews are = useful.

Cheers,

  Vincent

= --Apple-Mail=_CFF57026-EE97-4E13-BB0D-345CD88C5EBC-- From nobody Mon Apr 10 08:15: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 579471294F6; Mon, 10 Apr 2017 08:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 sOC_61_Qx9Wj; Mon, 10 Apr 2017 08:15:03 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CA2D129549; Mon, 10 Apr 2017 08:14:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20408; q=dns/txt; s=iport; t=1491837288; x=1493046888; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lQ9PxPR1XrifjWiKnV9XPRh5lYpD+hxrqcIibFrrync=; b=dx+2+Go8yGcCdPg5NomXGB7J95WUqAKM/nE/qBWXKwunMxF0beQ/bAnp Dqssdh0u1hL7JoG2rjdA60bxScYwOTJTd4H5dAKUNkhdRWw41tln4MBj+ c8c4+a8eQ5joaoTL8GV2oiawqZ3Ejv2h9wMd3XmeU6SWol5olI+SZp6VY E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQCXoOtY/4sNJK1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJuOiuBbAeNcpFHlVeCD4YkAoNgPxgBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQN5EAIBCBEDAQIZCAcHMhQJCAIEDgWKD6shimMBAQEBAQEBAQIBAQEBAQEBA?= =?us-ascii?q?QEBAR2LQIQuSC6FFwWPakGFdYZbAZJYkUGTfwEfOIEFWxVBhFscgWN1iFKBDQE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.37,182,1488844800"; d="scan'208,217";a="409503411" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Apr 2017 15:14:47 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v3AFEkse019525 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Apr 2017 15:14:46 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 10 Apr 2017 11:14:46 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Mon, 10 Apr 2017 11:14:46 -0400 From: "Acee Lindem (acee)" To: Vincent Roca CC: IESG , "secdir@ietf.org" , "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" , "Brian Weis (bew)" Thread-Topic: Secdir review of draft-ietf-rtgwg-yang-key-chain-17 Thread-Index: AQHSsgOCIbru9yr36U22nYG50kP+YKG+r7UAgABGSID//8A6AA== Date: Mon, 10 Apr 2017 15:14:46 +0000 Message-ID: References: <7B34A968-7AC9-4CBA-9F84-61AB90EDF65F@inria.fr> <342F77BA-C6E4-4865-9D98-A2923312D80A@inria.fr> In-Reply-To: <342F77BA-C6E4-4865-9D98-A2923312D80A@inria.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.197] Content-Type: multipart/alternative; boundary="_000_D51117B0A8083aceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-rtgwg-yang-key-chain-17 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, 10 Apr 2017 15:15:05 -0000 --_000_D51117B0A8083aceeciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Vincent, From: Vincent Roca > Date: Monday, April 10, 2017 at 11:02 AM To: Acee Lindem > Cc: Vincent Roca >, IES= G >, "secdir@ietf.org" >, "draft-ietf-rtgwg-yang-k= ey-chain.all@ietf.org"= >, "Brian Weis (bew)" > Subject: Re: Secdir review of draft-ietf-rtgwg-yang-key-chain-17 Hello Acee, Thanks for your review. You're welcome. ** Question: when saying: "When configured, the key-strings can be encrypted using the AES Ke= y Wrap algorithm" you do not provide any recommendation. I understand it is possible, but = is there any good reason to recommend it or do you believe the NETCONF access control feat= ure is sufficient? Are there environments where recommending it would be meaningful? I'd li= ke to have more information. This is a bit surprising when I compare with last paragraph where keys a= re RECOMMENDED to be encrypted when stored within network devices. This was added after a conversation with Brian Weis who I believe is also o= n the directorate. At this time, we didn't avail NCAM. As one would surmise= , it was for additional security for the key strings themselves. I'm not op= posed to removing the feature completely since no one has implemented it an= d it is somewhat unwieldy to have to distribute the key-encryption password= out-of-band. I don't have any opinion on the topic, just asked the question. Let's see what our ADs think. Note that I meant NCACM (RFC 6536). Yes, lets see the opinions here. I beli= eve that RFC 6536 will be substantially more widely implemented and deploye= d than RFC 5649. ** Minor comment: I don't see any good reason to separate paragraphs 2 and = 4. Where? I forgot to mention, sorry. I was considering the =AB Security Consideratio= ns =BB section. Re-ordering those two closely related paragraphs could make sense. Yes - I will combine them. The first two paragraphs are recent boiler plate= paragraphs for the "Security Considerations" in all YANG model drafts. Other comments: ** section 1.2: it says: " o Brackets "[" and "]" enclose list keys." There may be a confusion with the term "keys" here (i.e., something diff= erent from a cryptographic key). For instance, in section 3.3: | +--rw key-chain* [name] name is not a cryptographic key. This is pretty much boiler plate text for YANG model trees. I guess I could= add the statement: "These YANG list keys should not be confused with the key-chain keys." Yes, in an I-D entirely devoted to key exchanges, using the key term with a= totally different meaning is error prone (it took me some time to identify the poin= t). ** section 2.2: there's something I don't understand. It says: 3. When the send lifetime of the new key becomes valid, the network devices within the domain of key chain will start sending the new key. I have the feeling you mean that this new key will start to be used for t= ransmissions (instead of "start sending the new key"). Did I misunderstood something? Absolutely, I will correct this. That was a big mistake then. It's nice to see that SecDir reviews are useful. Cheers, Vincent --_000_D51117B0A8083aceeciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Vincent, 

From: Vincent Roca <vincent.roca@inria.fr>
Date: Monday, April 10, 2017 at 11:= 02 AM
To: Acee Lindem <acee@cisco.com>
Cc: Vincent Roca <vincent.roca@inria.fr>, IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draf= t-ietf-rtgwg-yang-key-chain.all@ietf.org" <draft-ietf-rtgwg-yang-key-chain= .all@ietf.org>, "Brian Weis (bew)" <bew@cisco.com>
Subject: Re: Secdir review of draft= -ietf-rtgwg-yang-key-chain-17

Hello Acee,

Thanks for your review. 

You’re welcome.


** Question: when saying:

        "When configured, the key-= strings can be encrypted using the AES Key Wrap algorithm"

   you do not provide any recommendation. I under= stand it is possible, but is there any good
   reason to recommend it or do you believe the N= ETCONF access control feature is sufficient?
   Are there environments where recommending it w= ould be meaningful? I'd like to have more
   information.
   This is a bit surprising when I compare with l= ast paragraph where keys are RECOMMENDED
   to be encrypted when stored within network dev= ices.

This was added after a conversation with Brian Weis who I believe is also o= n the directorate. At this time, we didn’t avail NCAM. As one would s= urmise, it was for additional security for the key strings themselves. I= 217;m not opposed to removing the feature completely since no one has implemented it and it is somewhat unwieldy to have to dis= tribute the key-encryption password out-of-band. 

I don’t have any opinion on the topic, just asked the question.<= /div>
Let’s see what our ADs think.

Note that I meant NCACM (RFC 6536). Yes, lets see the opinions here. I= believe that RFC 6536 will be substantially more widely implemented and de= ployed than RFC 5649. 


** Minor comment: I don't see any good reason to separate p= aragraphs 2 and 4.

Where? 

I forgot to mention, sorry. I was considering the =AB Security Co= nsiderations =BB section.
Re-ordering those two closely related paragraphs could make sense.

Yes – I will combine them. The first two paragraphs are recent b= oiler plate paragraphs for the “Security Considerations” in all= YANG model drafts. 


Other comments:

** section 1.2: it says:
        " o  Brackets "[= " and "]" enclose list keys."
   There may be a confusion with the term "k= eys" here (i.e., something different from
   a cryptographic key).

   For instance, in section 3.3:
        |  +--rw key-chain* [n= ame]
   name is not a cryptographic key.

This is pretty much boiler plate text for YANG model trees. I guess I could= add the statement: 

“These YANG list keys should not be confused with the key-chain keys.= "


Yes, in an I-D entirely devoted to key exchanges, using the key term w= ith a totally
different meaning is error prone (it took me some time to identify the= point).


** section 2.2: there's something I don't understand. It sa= ys:
    3.  When the send lifetime of the new ke= y becomes valid, the network
        devices within the domain of ke= y chain will start sending the new
        key.

  I have the feeling you mean that this new key will s= tart to be used for transmissions
  (instead of "start sending the new key"). = Did I misunderstood something?

Absolutely, I will correct this. 

That was a big mistake then. 
It’s nice to see that SecDir reviews are useful.

Cheers,

  Vincent

 --_000_D51117B0A8083aceeciscocom_-- From nobody Mon Apr 10 13:16:58 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 6BDDB126DC2; Mon, 10 Apr 2017 13:16:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey To: Cc: isis-wg@ietf.org, iesg@ietf.org, draft-ietf-isis-mi-bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149185541631.3069.18371935891180367330@ietfa.amsl.com> Date: Mon, 10 Apr 2017 13:16:56 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-isis-mi-bis-02 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: Mon, 10 Apr 2017 20:16:56 -0000 Reviewer: Joseph Salowey Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document does not explicitly discuss the use-cases for multi instance IS-IS. Is this intended to be used a security mechanism for isolation? The document should provide some guidance here. If the mechanism is intended as an isolation mechanism for security then I think more guidance is appropriate. For example, in this case shouldn't each instance have its own authentication configuration? If it is not intended as a security mechanism then the document probably say so. From nobody Mon Apr 10 14:29: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 58A35126BF7; Mon, 10 Apr 2017 14:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 Qy8qlavvYO72; Mon, 10 Apr 2017 14:29:03 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE1CF126CC7; Mon, 10 Apr 2017 14:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2190; q=dns/txt; s=iport; t=1491859742; x=1493069342; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Qhyama8WPo2ruAKNH7J/24JDX+CPIv69v9aXIBSrFn4=; b=FA3B3PckwkiBzIXanKz8pK0K2yfgjFISMjrAWHQIJvrmD3GgsQxmBK3v KjA0/vWhqZmpK4g4BI4mLoGLmkU/z7DaXW1pJ5kC23ZMmkxzmczvn7xyX 3or24DhDRR6E1felMQsbhTC1kHp4zBpepaDrBb55+kgMS+X8iGTQjRkOn Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D6AQCn+OtY/4MNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1OBbAeDX4oTkUiVV4IPhiQCGoNOPxgBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQMjEUUMBAIBCA4DBAEBAwIjAwICAjAUAQgIAgQBDQUIigepC4ImiwEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEdgQuFRYRwh1yCXwEEliCGWwGST4IIhS6KFJN/AR8?= =?us-ascii?q?4gQVbFYcbdYhSgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,183,1488844800"; d="scan'208";a="406425815" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Apr 2017 21:28:53 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v3ALSrjC028215 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Apr 2017 21:28:53 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 10 Apr 2017 16:28:52 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Mon, 10 Apr 2017 16:28:52 -0500 From: "Les Ginsberg (ginsberg)" To: Joseph Salowey , "secdir@ietf.org" CC: "isis-wg@ietf.org" , "iesg@ietf.org" , "draft-ietf-isis-mi-bis.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-isis-mi-bis-02 Thread-Index: AQHSsjdoqwxVNfAN00mB3vcmaDA1DqG/HafQ Date: Mon, 10 Apr 2017 21:28:52 +0000 Message-ID: <59da15bc7fa64e9281b94a2694919105@XCH-ALN-001.cisco.com> References: <149185541631.3069.18371935891180367330@ietfa.amsl.com> In-Reply-To: <149185541631.3069.18371935891180367330@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.67.234] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-isis-mi-bis-02 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, 10 Apr 2017 21:29:04 -0000 Sm9zZXBoIC0NCg0KVGhhbnggZm9yIHRoZSByZXZpZXcuDQoNClRoZSBpbnRyb2R1Y3Rpb24gZGVm aW5lcyB0aGUgcHVycG9zZXMoc2ljKSBvZiB0aGUgZXh0ZW5zaW9ucyAuIFBsZWFzZSByZXJlYWQg dGhhdCBhbmQgbGV0IG1lIGtub3cgaWYgeW91IHN0aWxsIGhhdmUgY29uY2VybnMuDQoNClRoZSBl eHRlbnNpb25zIGFyZSBub3QgZm9yIHNlY3VyaXR5IHB1cnBvc2VzIC0gYXMgYSBtYXR0ZXIgb2Yg cHJpbmNpcGxlIEkgYW0gY29uY2VybmVkIGlmIGEgbmV3IHJlcXVpcmVtZW50IG9mIGV2ZXJ5IGRy YWZ0IGlzIHRvIGV4cGxpY2l0bHkgc3RhdGUgYWxsIHRoZSB0aGluZ3MgdGhhdCBpdCBpcyBub3Qg aW50ZW5kZWQgdG8gZG8uIDotKQ0KDQogICBMZXMNCg0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb3NlcGggU2Fsb3dleSBbbWFpbHRvOmpvZUBzYWxvd2V5Lm5l dF0NCj4gU2VudDogTW9uZGF5LCBBcHJpbCAxMCwgMjAxNyAxOjE3IFBNDQo+IFRvOiBzZWNkaXJA aWV0Zi5vcmcNCj4gQ2M6IGlzaXMtd2dAaWV0Zi5vcmc7IGllc2dAaWV0Zi5vcmc7IGRyYWZ0LWll dGYtaXNpcy1taS1iaXMuYWxsQGlldGYub3JnDQo+IFN1YmplY3Q6IFNlY2RpciBsYXN0IGNhbGwg cmV2aWV3IG9mIGRyYWZ0LWlldGYtaXNpcy1taS1iaXMtMDINCj4gDQo+IFJldmlld2VyOiBKb3Nl cGggU2Fsb3dleQ0KPiBSZXZpZXcgcmVzdWx0OiBIYXMgSXNzdWVzDQo+IA0KPiBJIGhhdmUgcmV2 aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdz IG9uZ29pbmcNCj4gZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJv Y2Vzc2VkIGJ5IHRoZSBJRVNHLiAgVGhlc2UNCj4gY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1h cmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWENCj4gZGlyZWN0b3JzLiAg RG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50 cw0KPiBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCj4gDQo+IFRoZSBk b2N1bWVudCBkb2VzIG5vdCBleHBsaWNpdGx5IGRpc2N1c3MgdGhlIHVzZS1jYXNlcyBmb3IgbXVs dGkgaW5zdGFuY2UgSVMtDQo+IElTLiAgSXMgdGhpcyBpbnRlbmRlZCB0byBiZSB1c2VkIGEgc2Vj dXJpdHkgbWVjaGFuaXNtIGZvciBpc29sYXRpb24/ICBUaGUNCj4gZG9jdW1lbnQgc2hvdWxkIHBy b3ZpZGUgc29tZSBndWlkYW5jZSBoZXJlLg0KPiANCj4gSWYgdGhlIG1lY2hhbmlzbSBpcyBpbnRl bmRlZCBhcyBhbiBpc29sYXRpb24gbWVjaGFuaXNtIGZvciBzZWN1cml0eQ0KPiB0aGVuIEkgdGhp bmsgbW9yZSBndWlkYW5jZSBpcyBhcHByb3ByaWF0ZS4gICBGb3IgZXhhbXBsZSwgaW4gdGhpcyBj YXNlDQo+IHNob3VsZG4ndCBlYWNoIGluc3RhbmNlIGhhdmUgaXRzIG93biBhdXRoZW50aWNhdGlv biBjb25maWd1cmF0aW9uPw0KPiANCj4gSWYgaXQgaXMgbm90IGludGVuZGVkIGFzIGEgc2VjdXJp dHkgbWVjaGFuaXNtIHRoZW4gdGhlIGRvY3VtZW50IHByb2JhYmx5IHNheQ0KPiBzby4NCj4gDQoN Cg== From nobody Tue Apr 11 08:16:07 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 6356812EAB0; Tue, 11 Apr 2017 08:15:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner To: Cc: dnssd@ietf.org, ietf@ietf.org, draft-ietf-dnssd-mdns-dns-interop.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149192374936.15734.41201323624268863@ietfa.amsl.com> Date: Tue, 11 Apr 2017 08:15:49 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dnssd-mdns-dns-interop-04 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, 11 Apr 2017 15:15:49 -0000 Reviewer: Sean Turner Review result: Ready The draft is short and well written. The security considerations is also brief, but I agree with its basic point "This memo presents some requirements for future development, but does not specify anything." The persistent "visual confusability" consideration wrt internationalized domain names is duly noted as a consideration. In my opinion, the security considerations as written is appropriate and sufficient; other DNSSD WG protocol-focused drafts have more extensive security considerations and it is better to grind the security axe against those documents rather than here. From nobody Tue Apr 11 14:32: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 9955A12EBDA; Tue, 11 Apr 2017 14:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, PP_MIME_FAKE_ASCII_TEXT=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 d9MBGrNTCoXL; Tue, 11 Apr 2017 14:32:01 -0700 (PDT) Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D96F12EB22; Tue, 11 Apr 2017 14:32:01 -0700 (PDT) Received: from in02.mta.xmission.com ([166.70.13.52]) by out03.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1cy3OK-0003U5-8N; Tue, 11 Apr 2017 15:32:00 -0600 Received: from [72.250.219.84] (helo=rumpleteazer.rhmr.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1cy3OI-0000Cy-JM; Tue, 11 Apr 2017 15:32:00 -0600 Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v3BLVR6v017435; Tue, 11 Apr 2017 15:31:27 -0600 Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id v3BLVQTB017431; Tue, 11 Apr 2017 15:31:26 -0600 Date: Tue, 11 Apr 2017 15:31:26 -0600 Message-Id: <201704112131.v3BLVQTB017431@rumpleteazer.rhmr.com> From: "Hilarie Orman" Reply-To: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org Cc: draft-ietf-6man-rfc2460bis@ietf.org X-XM-SPF: eid=1cy3OI-0000Cy-JM; ; ; mid=<201704112131.v3BLVQTB017431@rumpleteazer.rhmr.com>; ; ; hst=in02.mta.xmission.com; ; ; ip=72.250.219.84; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-AID: U2FsdGVkX1/AWLp4p1ZfI2s5vHuOu7Oq X-SA-Exim-Connect-IP: 72.250.219.84 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ****;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 1350 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 2.5 (0.2%), b_tie_ro: 1.75 (0.1%), parse: 0.69 (0.1%), extract_message_metadata: 3.0 (0.2%), get_uri_detail_list: 0.78 (0.1%), tests_pri_-1000: 2.8 (0.2%), tests_pri_-950: 1.30 (0.1%), tests_pri_-900: 1.01 (0.1%), tests_pri_-400: 15 (1.1%), check_bayes: 14 (1.0%), b_tokenize: 4.2 (0.3%), b_tok_get_all: 4.1 (0.3%), b_comp_prob: 1.79 (0.1%), b_tok_touch_all: 2.5 (0.2%), b_finish: 0.50 (0.0%), tests_pri_0: 1318 (97.6%), check_dkim_signature: 0.42 (0.0%), check_dkim_adsp: 40 (3.0%), tests_pri_500: 3.4 (0.3%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Archived-At: Subject: [secdir] Secdir review draft-ietf-6man-rfc2460bis-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: Tue, 11 Apr 2017 21:32:02 -0000 Security review of Internet Protocol, Version 6 (IPv6) Specification draft-ietf-6man-rfc2460bis-09 Do not be alarmed. 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 the IPv6 specification. Recent modifications have clarified how to process extension headers. The security considerations are brief and have not changed: IPv6 ... has security properties similar to IPv4. Risks of corruption, forgery, and interception of packets, resulting in the exposure of private information, may be mitigated by use of the Security Architecture for the Internet Protocol [RFC4301] or encryption at higher layers of the protocol stack. I wonder if the only security consideration for IP is the risk of exposure of private information? Of course not. But, I suppose that's not in scope of this review. One thing worth mentioning about the changes re header processing is that is contributes to security by reducing complexity and reducing the attack surface. Hilarie From nobody Tue Apr 11 22:23:12 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 7C7CB12947A for ; Tue, 11 Apr 2017 22:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.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 Q7OkcguCa5G2 for ; Tue, 11 Apr 2017 22:23:09 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 69E84129405 for ; Tue, 11 Apr 2017 22:23:09 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id i5so8512759pfc.2 for ; Tue, 11 Apr 2017 22:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CLp50fAFCP4fMjgmmiGq8ogaM7D/vXEas5/KcoEXPG8=; b=esmV2vBTM0jVlltwd8efoyZ97leQ6gGOUKXaCew6Qmxd3JHcOa6ugO5vPHB0hCvX6R kYg1YjdHF4CQsOhIMRWICQZenXxj+upq1ikH58PWgLiCYnTqGLH/0JpFEtMm59+mDvOX lEAkvFeGL6jXZwpF1FgnX+kNEQD5UYOeIZDOTOdq4AKAJtYxw+oY+0014wtjqpKYnRiW zjS42h4J4a03QZ4kRCa8RTBvgMCyTXj17T0EJSDYmBsSXlj88zE4bEqEmV4W0iPmWn/r bpYYuhRKcQMDJ7ZHmqkRKroSOucsi9LlyFcHctBD+TGX68M4YBlIdaiHTSx+1FZ/iYqn brvQ== 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=CLp50fAFCP4fMjgmmiGq8ogaM7D/vXEas5/KcoEXPG8=; b=Z0H/1b0+PR2CpaXSZ9WqxUwHfSqqy9KU57y1fU8eB62ClXcaVKgrRW4e234T4k4/3c 09Oa3gdBlvb/Z+nXxhqlMDUEP40c/mtofLpj13TT5ZnRwCso9ITwslq6S2KQbTW28B4I SkqMg32VMo8AAdbZXKgGSJN5AvZeNPOhZfnvLmOqDeFnrcT/MeeFhdkmDlqqXbpP+VjN NqVV81axEVogbSjbmnsvrsCiSAur2gEnhQTbHgukSYgn+PG+H10cDZzWuKjy6yFFQHby POzpKt+AzuMSPzv6bo4m+sYOapcO/L4+fVmRnCmlcWEIPRcTqwYqgfOID3M3hf/tDd5x y5Qg== X-Gm-Message-State: AFeK/H2XpNo150bITapSqieXoBbEBFjNnalG4Q1Cg/pJPmwediw6vmLfHpATUfD/q2dBDAlKJEYjbM8qTa988Q== X-Received: by 10.84.198.3 with SMTP id o3mr46077572pld.45.1491974588977; Tue, 11 Apr 2017 22:23:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.183.7 with HTTP; Tue, 11 Apr 2017 22:22:48 -0700 (PDT) In-Reply-To: <59da15bc7fa64e9281b94a2694919105@XCH-ALN-001.cisco.com> References: <149185541631.3069.18371935891180367330@ietfa.amsl.com> <59da15bc7fa64e9281b94a2694919105@XCH-ALN-001.cisco.com> From: Joseph Salowey Date: Tue, 11 Apr 2017 22:22:48 -0700 Message-ID: To: "Les Ginsberg (ginsberg)" Cc: "secdir@ietf.org" , "isis-wg@ietf.org" , "iesg@ietf.org" , "draft-ietf-isis-mi-bis.all@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c18938e63e727054cf16752 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-isis-mi-bis-02 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, 12 Apr 2017 05:23:11 -0000 --94eb2c18938e63e727054cf16752 Content-Type: text/plain; charset=UTF-8 I reread the introduction and it does mention isolating resources, but not explicitly for security purposes. I'm going to push back a bit on it being a new requirement to discuss what is and is not intended. We have had a security considerations section in documents for a long time. The draft redirects security considerations to other documents which primarily talk about authenticating messages. The draft does include some discussion of being able to select authentication parameters based on IID. While this is important, it doesn't really discuss why you would use this protection with multi-instance IS-IS or what is different. The document could include a statement that considerations to do with using multi-instance IS-IS as a security isolation mechanism is outside the scope of the document or, better yet, describe what the considerations unique to multi-instance IS-IS are. Since the primary uses do not have to do with using this enhancement as a security mechanism I don't think it will cause great harm to publish the document as is. Cheers, Joe On Mon, Apr 10, 2017 at 2:28 PM, Les Ginsberg (ginsberg) wrote: > Joseph - > > Thanx for the review. > > The introduction defines the purposes(sic) of the extensions . Please > reread that and let me know if you still have concerns. > > The extensions are not for security purposes - as a matter of principle I > am concerned if a new requirement of every draft is to explicitly state all > the things that it is not intended to do. :-) > > Les > > > > > > -----Original Message----- > > From: Joseph Salowey [mailto:joe@salowey.net] > > Sent: Monday, April 10, 2017 1:17 PM > > To: secdir@ietf.org > > Cc: isis-wg@ietf.org; iesg@ietf.org; draft-ietf-isis-mi-bis.all@ietf.org > > Subject: Secdir last call review of draft-ietf-isis-mi-bis-02 > > > > Reviewer: Joseph Salowey > > Review result: Has Issues > > > > I have reviewed this document as part of the security directorate's > ongoing > > effort to review all IETF documents being processed by the IESG. These > > comments were written primarily for the benefit of the security area > > directors. Document editors and WG chairs should treat these comments > > just like any other last call comments. > > > > The document does not explicitly discuss the use-cases for multi > instance IS- > > IS. Is this intended to be used a security mechanism for isolation? The > > document should provide some guidance here. > > > > If the mechanism is intended as an isolation mechanism for security > > then I think more guidance is appropriate. For example, in this case > > shouldn't each instance have its own authentication configuration? > > > > If it is not intended as a security mechanism then the document probably > say > > so. > > > > --94eb2c18938e63e727054cf16752 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I reread the introduction and it does mention isolating re= sources, but not explicitly for security purposes.=C2=A0 I'm going to p= ush back a bit on it being a new requirement to discuss what is and is not = intended. =C2=A0 We have had a security considerations section in documents= for a long time. =C2=A0 The draft redirects security considerations to oth= er documents which primarily talk about authenticating messages. =C2=A0 The= draft does include some discussion of being able to select authentication = parameters based on IID.=C2=A0 While this is important, it doesn't real= ly discuss why you would use this protection with multi-instance IS-IS or w= hat is different. =C2=A0

The document could include= a statement that considerations to do with using multi-instance=C2=A0IS-IS= as a security isolation mechanism is outside the scope of the document or,= better yet, describe what the considerations unique to multi-instance=C2= =A0IS-IS are. =C2=A0 Since the primary uses do not have to do with using th= is enhancement as a security mechanism I don't think it will cause grea= t harm to publish the document as is. =C2=A0

Cheers,

Joe




On Mon, Apr 10, 2017 at 2:28 PM, Les Ginsberg (ginsberg) <ginsberg@= cisco.com> wrote:
Joseph -=

Thanx for the review.

The introduction defines the purposes(sic) of the extensions . Please rerea= d that and let me know if you still have concerns.

The extensions are not for security purposes - as a matter of principle I a= m concerned if a new requirement of every draft is to explicitly state all = the things that it is not intended to do. :-)

=C2=A0 =C2=A0Les




> -----Original Message-----
> From: Joseph Salowey [mailto:joe@sa= lowey.net]
> Sent: Monday, April 10, 2017 1:17 PM
> To: secdir@ietf.org
> Cc: isis-wg@ietf.org; iesg@ietf.org; draft-ietf-isis-mi-bis.all@ietf.org
> Subject: Secdir last call review of draft-ietf-isis-mi-bis-02
>
> Reviewer: Joseph Salowey
> Review result: Has Issues
>
> I have reviewed this document as part of the security directorate'= s ongoing
> effort to review all IETF documents being processed by the IESG.=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 com= ments
> just like any other last call comments.
>
> The document does not explicitly discuss the use-cases for multi insta= nce IS-
> IS.=C2=A0 Is this intended to be used a security mechanism for isolati= on?=C2=A0 The
> document should provide some guidance here.
>
> If the mechanism is intended as an isolation mechanism for security > then I think more guidance is appropriate.=C2=A0 =C2=A0For example, in= this case
> shouldn't each instance have its own authentication configuration?=
>
> If it is not intended as a security mechanism then the document probab= ly say
> so.
>


--94eb2c18938e63e727054cf16752-- From nobody Tue Apr 11 23:44:48 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 4E3AD127275; Tue, 11 Apr 2017 23:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 qB-v4L6HkxQv; Tue, 11 Apr 2017 23:44:43 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 048B81289C3; Tue, 11 Apr 2017 23:44:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.37,189,1488841200"; d="scan'208,217";a="220157433" Received: from demeter.inrialpes.fr ([194.199.28.3]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Apr 2017 08:44:39 +0200 From: Vincent Roca Message-Id: <4E48D017-68C1-41C1-A7B8-6F09C22D2859@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_915C8989-7FFA-4504-A7F9-6D4F186E7F28" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 12 Apr 2017 08:44:39 +0200 In-Reply-To: Cc: Vincent Roca , IESG , "secdir@ietf.org" , "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" , "Brian Weis (bew)" To: "Acee Lindem (acee)" References: <7B34A968-7AC9-4CBA-9F84-61AB90EDF65F@inria.fr> <342F77BA-C6E4-4865-9D98-A2923312D80A@inria.fr> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-rtgwg-yang-key-chain-17 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, 12 Apr 2017 06:44:46 -0000 --Apple-Mail=_915C8989-7FFA-4504-A7F9-6D4F186E7F28 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Acee, Thanks for the update of your document: = https://tools.ietf.org/html/draft-ietf-rtgwg-yang-key-chain-18 = I missed it when reading your previous version, but using MD5 and HMAC = SHA 1 in the examples of appendix A is a very bad idea that will trigger negative comments = from IESG. Please remove them. Furthermore you=E2=80=99ll also be in line with your new recommendations = of Section 5. Cheers, Vincent > Le 10 avr. 2017 =C3=A0 17:14, Acee Lindem (acee) a = =C3=A9crit : >=20 > Hi Vincent,=20 >=20 > From: Vincent Roca > > Date: Monday, April 10, 2017 at 11:02 AM > To: Acee Lindem > > Cc: Vincent Roca >, IESG >, "secdir@ietf.org " = >, = "draft-ietf-rtgwg-yang-key-chain.all@ietf.org = " = >, "Brian Weis = (bew)" > > Subject: Re: Secdir review of draft-ietf-rtgwg-yang-key-chain-17 >=20 > Hello Acee, >=20 >> Thanks for your review.=20 >=20 > You=E2=80=99re welcome. >=20 >=20 >> ** Question: when saying: >>=20 >> "When configured, the key-strings can be encrypted using the = AES Key Wrap algorithm" >>=20 >> you do not provide any recommendation. I understand it is = possible, but is there any good >> reason to recommend it or do you believe the NETCONF access = control feature is sufficient? >> Are there environments where recommending it would be meaningful? = I'd like to have more >> information. >> This is a bit surprising when I compare with last paragraph where = keys are RECOMMENDED >> to be encrypted when stored within network devices. >>=20 >> This was added after a conversation with Brian Weis who I believe is = also on the directorate. At this time, we didn=E2=80=99t avail NCAM. As = one would surmise, it was for additional security for the key strings = themselves. I=E2=80=99m not opposed to removing the feature completely = since no one has implemented it and it is somewhat unwieldy to have to = distribute the key-encryption password out-of-band.=20 >=20 > I don=E2=80=99t have any opinion on the topic, just asked the = question. > Let=E2=80=99s see what our ADs think. >=20 > Note that I meant NCACM (RFC 6536). Yes, lets see the opinions here. I = believe that RFC 6536 will be substantially more widely implemented and = deployed than RFC 5649.=20 >=20 >=20 >> ** Minor comment: I don't see any good reason to separate paragraphs = 2 and 4. >>=20 >> Where?=20 >=20 > I forgot to mention, sorry. I was considering the =C2=AB Security = Considerations =C2=BB section. > Re-ordering those two closely related paragraphs could make sense. >=20 > Yes =E2=80=93 I will combine them. The first two paragraphs are recent = boiler plate paragraphs for the =E2=80=9CSecurity Considerations=E2=80=9D = in all YANG model drafts.=20 >=20 >=20 >> Other comments: >>=20 >> ** section 1.2: it says: >> " o Brackets "[" and "]" enclose list keys." >> There may be a confusion with the term "keys" here (i.e., = something different from >> a cryptographic key). >>=20 >> For instance, in section 3.3: >> | +--rw key-chain* [name] >> name is not a cryptographic key. >>=20 >> This is pretty much boiler plate text for YANG model trees. I guess I = could add the statement:=20 >>=20 >> =E2=80=9CThese YANG list keys should not be confused with the = key-chain keys." >>=20 >=20 > Yes, in an I-D entirely devoted to key exchanges, using the key term = with a totally > different meaning is error prone (it took me some time to identify the = point). >=20 >=20 >> ** section 2.2: there's something I don't understand. It says: >> 3. When the send lifetime of the new key becomes valid, the = network >> devices within the domain of key chain will start sending the = new >> key. >>=20 >> I have the feeling you mean that this new key will start to be used = for transmissions >> (instead of "start sending the new key"). Did I misunderstood = something? >>=20 >> Absolutely, I will correct this.=20 >=20 > That was a big mistake then.=20 > It=E2=80=99s nice to see that SecDir reviews are useful. >=20 > Cheers, >=20 > Vincent >=20 --Apple-Mail=_915C8989-7FFA-4504-A7F9-6D4F186E7F28 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello Acee,

Thanks for the update of your document: https://tools.ietf.org/html/draft-ietf-rtgwg-yang-key-chain-18<= /a>

I missed = it when reading your previous version, but using MD5 and HMAC SHA 1 in = the examples
of appendix A is a very bad idea that = will trigger negative comments from IESG. Please remove them.
Furthermore you=E2=80=99ll also be in line with your new = recommendations of Section 5.

Cheers,

  Vincent


Le 10 avr. 2017 =C3=A0 17:14, Acee Lindem (acee) <acee@cisco.com> a = =C3=A9crit :

=
Hi Vincent, 

From: Vincent Roca = <vincent.roca@inria.fr>
Date: Monday, April = 10, 2017 at 11:02 AM
To: Acee Lindem = <acee@cisco.com> Cc: Vincent Roca = <vincent.roca@inria.fr>, IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" <draft-ietf-rtgwg-yang-key-chain.all@ietf.org>, "Brian = Weis (bew)" <bew@cisco.com>
Subject: Re: Secdir = review of draft-ietf-rtgwg-yang-key-chain-17

Hello Acee,

Thanks for your review. 

You=E2=80=99re welcome.


** Question: when saying:

        "When configured, the = key-strings can be encrypted using the AES Key Wrap algorithm"

   you do not provide any recommendation. I = understand it is possible, but is there any good
   reason to recommend it or do you believe = the NETCONF access control feature is sufficient?
   Are there environments where recommending = it would be meaningful? I'd like to have more
   information.
   This is a bit surprising when I compare = with last paragraph where keys are RECOMMENDED
   to be encrypted when stored within network = devices.

This was added after a conversation with Brian Weis who I believe is = also on the directorate. At this time, we didn=E2=80=99t avail NCAM. As = one would surmise, it was for additional security for the key strings = themselves. I=E2=80=99m not opposed to removing the feature completely since no one has implemented it and it is somewhat unwieldy to have to = distribute the key-encryption password out-of-band. 

I don=E2=80=99t have any opinion on the topic, just = asked the question.
Let=E2=80=99s see what our ADs think.

Note that I meant NCACM (RFC 6536). Yes, lets see the = opinions here. I believe that RFC 6536 will be substantially more widely = implemented and deployed than RFC 5649. 


** Minor comment: I don't see any good reason to = separate paragraphs 2 and 4.

Where? 

I forgot to mention, sorry. I was considering the = =C2=AB Security Considerations =C2=BB section.
Re-ordering those two closely related paragraphs could = make sense.

Yes =E2=80=93 I will combine them. The first two = paragraphs are recent boiler plate paragraphs for the =E2=80=9CSecurity = Considerations=E2=80=9D in all YANG model drafts. 


Other comments:

** section 1.2: it says:
        " o  Brackets "[" and = "]" enclose list keys."
   There may be a confusion with the term = "keys" here (i.e., something different from
   a cryptographic key).

   For instance, in section 3.3:
        |  +--rw key-chain* = [name]
   name is not a cryptographic key.

This is pretty much boiler plate text for YANG model trees. I guess I = could add the statement: 

=E2=80=9CThese YANG list keys should not be confused with the key-chain = keys."


Yes, in an I-D entirely devoted to key exchanges, using = the key term with a totally
different meaning is error prone (it took me some time = to identify the point).


** section 2.2: there's something I don't understand. It = says:
    3.  When the send lifetime of the new = key becomes valid, the network
        devices within the domain of = key chain will start sending the new
        key.

  I have the feeling you mean that this new key = will start to be used for transmissions
  (instead of "start sending the new key"). Did I = misunderstood something?

Absolutely, I will correct this. 

That was a big mistake then. 
It=E2=80=99s nice to see that SecDir reviews are = useful.

Cheers,

  Vincent

= --Apple-Mail=_915C8989-7FFA-4504-A7F9-6D4F186E7F28-- From nobody Wed Apr 12 07:23: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 C8A2D129B8D; Wed, 12 Apr 2017 07:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 9MeV1SvQ0_VX; Wed, 12 Apr 2017 07:23:27 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38C7C12948A; Wed, 12 Apr 2017 07:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35157; q=dns/txt; s=iport; t=1492007007; x=1493216607; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MTKvlMEOOdKpSy9seqkp2BfUO+RHCp89xG9wQysuI6w=; b=hz86GPskIWxQpHBkluOklPK6e9bgmxZ/p0aaheiFuoOnAmLlmer3LduG YGj+27Grjfz7cY+ciEiEvLqaa2/JSbazvfq3wxIztxCl9qMLm7xBzH+WF e/zu7JixE5Ljk/d8pxY3aNRYurQ9vU5xuBqFMgEiJeLk9lVEedahKog8y c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C5AQD1Nu5Y/51dJa1SChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJuZWGBCweDX4oTkVGVWYIPLIV4AhqDXz8YAQIBAQEBAQEBayi?= =?us-ascii?q?FFQEBAQEDI1YQAgEIEQMBAhkIBwMCAgIwFAkIAgQOBYoWDqhFgiaKeQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFiC6DF4QuSC6COIJfBY9xhjaGYwGHAYtfgX+FLoo?= =?us-ascii?q?XiGWHBiWDcQEfOIEFWxVBhFsBG4FjdYgVgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,191,1488844800"; d="scan'208,217";a="232055995" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Apr 2017 14:23:26 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v3CENPXH030094 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Apr 2017 14:23:25 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 12 Apr 2017 10:23:25 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 12 Apr 2017 10:23:25 -0400 From: "Acee Lindem (acee)" To: Vincent Roca CC: IESG , "secdir@ietf.org" , "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" , "Brian Weis (bew)" Thread-Topic: Secdir review of draft-ietf-rtgwg-yang-key-chain-17 Thread-Index: AQHSsgOCIbru9yr36U22nYG50kP+YKG+r7UAgABGSID//8A6AIAC2VOAgAA9GYA= Date: Wed, 12 Apr 2017 14:23:24 +0000 Message-ID: References: <7B34A968-7AC9-4CBA-9F84-61AB90EDF65F@inria.fr> <342F77BA-C6E4-4865-9D98-A2923312D80A@inria.fr> <4E48D017-68C1-41C1-A7B8-6F09C22D2859@inria.fr> In-Reply-To: <4E48D017-68C1-41C1-A7B8-6F09C22D2859@inria.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.197] Content-Type: multipart/alternative; boundary="_000_D513AFBCA853Daceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-rtgwg-yang-key-chain-17 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, 12 Apr 2017 14:23:35 -0000 --_000_D513AFBCA853Daceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVmluY2VudCwNCg0KSeKAmXZlIHVwZGF0ZWQgdGhlIGV4YW1wbGVzIHRvIHJlZmVyZW5jZSBo bWFjLXNoYS0yNTYgYW5kIGhtYWMtc2hhLTUxMi4gVGhlIHJlYXNvbnMgdGhlIG9sZGVyIChhbmQg dnVsbmVyYWJsZSkgYWxnb3JpdGhtIHdlcmUgcmVmZXJlbmNlZCBpbiBleGFtcGxlcyBpcyB0aGF0 IHRoaXMgaXMgd2hhdCAgaXMgYmVpbmcgdXNlZCBieSBjdXJyZW50IGFwcGxpY2F0aW9ucy4gSG93 ZXZlciwgdGhlcmUgaXMgbm8gcmVhc29uIG5vdCB0byB1c2UgdGhlIGJldHRlciBhbGdvcml0aG1z IChlLmcuLCBSRkMgNzQ3NCkuDQoNClRoYW5rcywNCkFjZWUNCg0KRnJvbTogVmluY2VudCBSb2Nh IDx2aW5jZW50LnJvY2FAaW5yaWEuZnI8bWFpbHRvOnZpbmNlbnQucm9jYUBpbnJpYS5mcj4+DQpE YXRlOiBXZWRuZXNkYXksIEFwcmlsIDEyLCAyMDE3IGF0IDI6NDQgQU0NClRvOiBBY2VlIExpbmRl bSA8YWNlZUBjaXNjby5jb208bWFpbHRvOmFjZWVAY2lzY28uY29tPj4NCkNjOiBWaW5jZW50IFJv Y2EgPHZpbmNlbnQucm9jYUBpbnJpYS5mcjxtYWlsdG86dmluY2VudC5yb2NhQGlucmlhLmZyPj4s IElFU0cgPGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+PiwgInNlY2RpckBpZXRm Lm9yZzxtYWlsdG86c2VjZGlyQGlldGYub3JnPiIgPHNlY2RpckBpZXRmLm9yZzxtYWlsdG86c2Vj ZGlyQGlldGYub3JnPj4sICJkcmFmdC1pZXRmLXJ0Z3dnLXlhbmcta2V5LWNoYWluLmFsbEBpZXRm Lm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1ydGd3Zy15YW5nLWtleS1jaGFpbi5hbGxAaWV0Zi5vcmc+ IiA8ZHJhZnQtaWV0Zi1ydGd3Zy15YW5nLWtleS1jaGFpbi5hbGxAaWV0Zi5vcmc8bWFpbHRvOmRy YWZ0LWlldGYtcnRnd2cteWFuZy1rZXktY2hhaW4uYWxsQGlldGYub3JnPj4sICJCcmlhbiBXZWlz IChiZXcpIiA8YmV3QGNpc2NvLmNvbTxtYWlsdG86YmV3QGNpc2NvLmNvbT4+DQpTdWJqZWN0OiBS ZTogU2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLXJ0Z3dnLXlhbmcta2V5LWNoYWluLTE3DQoN CkhlbGxvIEFjZWUsDQoNClRoYW5rcyBmb3IgdGhlIHVwZGF0ZSBvZiB5b3VyIGRvY3VtZW50OiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGd3Zy15YW5nLWtleS1jaGFp bi0xOA0KDQpJIG1pc3NlZCBpdCB3aGVuIHJlYWRpbmcgeW91ciBwcmV2aW91cyB2ZXJzaW9uLCBi dXQgdXNpbmcgTUQ1IGFuZCBITUFDIFNIQSAxIGluIHRoZSBleGFtcGxlcw0Kb2YgYXBwZW5kaXgg QSBpcyBhIHZlcnkgYmFkIGlkZWEgdGhhdCB3aWxsIHRyaWdnZXIgbmVnYXRpdmUgY29tbWVudHMg ZnJvbSBJRVNHLiBQbGVhc2UgcmVtb3ZlIHRoZW0uDQpGdXJ0aGVybW9yZSB5b3XigJlsbCBhbHNv IGJlIGluIGxpbmUgd2l0aCB5b3VyIG5ldyByZWNvbW1lbmRhdGlvbnMgb2YgU2VjdGlvbiA1Lg0K DQpDaGVlcnMsDQoNCiAgVmluY2VudA0KDQoNCkxlIDEwIGF2ci4gMjAxNyDDoCAxNzoxNCwgQWNl ZSBMaW5kZW0gKGFjZWUpIDxhY2VlQGNpc2NvLmNvbTxtYWlsdG86YWNlZUBjaXNjby5jb20+PiBh IMOpY3JpdCA6DQoNCkhpIFZpbmNlbnQsDQoNCkZyb206IFZpbmNlbnQgUm9jYSA8dmluY2VudC5y b2NhQGlucmlhLmZyPG1haWx0bzp2aW5jZW50LnJvY2FAaW5yaWEuZnI+Pg0KRGF0ZTogTW9uZGF5 LCBBcHJpbCAxMCwgMjAxNyBhdCAxMTowMiBBTQ0KVG86IEFjZWUgTGluZGVtIDxhY2VlQGNpc2Nv LmNvbTxtYWlsdG86YWNlZUBjaXNjby5jb20+Pg0KQ2M6IFZpbmNlbnQgUm9jYSA8dmluY2VudC5y b2NhQGlucmlhLmZyPG1haWx0bzp2aW5jZW50LnJvY2FAaW5yaWEuZnI+PiwgSUVTRyA8aWVzZ0Bp ZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz4+LCAic2VjZGlyQGlldGYub3JnPG1haWx0bzpz ZWNkaXJAaWV0Zi5vcmc+IiA8c2VjZGlyQGlldGYub3JnPG1haWx0bzpzZWNkaXJAaWV0Zi5vcmc+ PiwgImRyYWZ0LWlldGYtcnRnd2cteWFuZy1rZXktY2hhaW4uYWxsQGlldGYub3JnPG1haWx0bzpk cmFmdC1pZXRmLXJ0Z3dnLXlhbmcta2V5LWNoYWluLmFsbEBpZXRmLm9yZz4iIDxkcmFmdC1pZXRm LXJ0Z3dnLXlhbmcta2V5LWNoYWluLmFsbEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1ydGd3 Zy15YW5nLWtleS1jaGFpbi5hbGxAaWV0Zi5vcmc+PiwgIkJyaWFuIFdlaXMgKGJldykiIDxiZXdA Y2lzY28uY29tPG1haWx0bzpiZXdAY2lzY28uY29tPj4NClN1YmplY3Q6IFJlOiBTZWNkaXIgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtcnRnd2cteWFuZy1rZXktY2hhaW4tMTcNCg0KSGVsbG8gQWNlZSwN Cg0KVGhhbmtzIGZvciB5b3VyIHJldmlldy4NCg0KWW914oCZcmUgd2VsY29tZS4NCg0KDQoqKiBR dWVzdGlvbjogd2hlbiBzYXlpbmc6DQoNCiAgICAgICAgIldoZW4gY29uZmlndXJlZCwgdGhlIGtl eS1zdHJpbmdzIGNhbiBiZSBlbmNyeXB0ZWQgdXNpbmcgdGhlIEFFUyBLZXkgV3JhcCBhbGdvcml0 aG0iDQoNCiAgIHlvdSBkbyBub3QgcHJvdmlkZSBhbnkgcmVjb21tZW5kYXRpb24uIEkgdW5kZXJz dGFuZCBpdCBpcyBwb3NzaWJsZSwgYnV0IGlzIHRoZXJlIGFueSBnb29kDQogICByZWFzb24gdG8g cmVjb21tZW5kIGl0IG9yIGRvIHlvdSBiZWxpZXZlIHRoZSBORVRDT05GIGFjY2VzcyBjb250cm9s IGZlYXR1cmUgaXMgc3VmZmljaWVudD8NCiAgIEFyZSB0aGVyZSBlbnZpcm9ubWVudHMgd2hlcmUg cmVjb21tZW5kaW5nIGl0IHdvdWxkIGJlIG1lYW5pbmdmdWw/IEknZCBsaWtlIHRvIGhhdmUgbW9y ZQ0KICAgaW5mb3JtYXRpb24uDQogICBUaGlzIGlzIGEgYml0IHN1cnByaXNpbmcgd2hlbiBJIGNv bXBhcmUgd2l0aCBsYXN0IHBhcmFncmFwaCB3aGVyZSBrZXlzIGFyZSBSRUNPTU1FTkRFRA0KICAg dG8gYmUgZW5jcnlwdGVkIHdoZW4gc3RvcmVkIHdpdGhpbiBuZXR3b3JrIGRldmljZXMuDQoNClRo aXMgd2FzIGFkZGVkIGFmdGVyIGEgY29udmVyc2F0aW9uIHdpdGggQnJpYW4gV2VpcyB3aG8gSSBi ZWxpZXZlIGlzIGFsc28gb24gdGhlIGRpcmVjdG9yYXRlLiBBdCB0aGlzIHRpbWUsIHdlIGRpZG7i gJl0IGF2YWlsIE5DQU0uIEFzIG9uZSB3b3VsZCBzdXJtaXNlLCBpdCB3YXMgZm9yIGFkZGl0aW9u YWwgc2VjdXJpdHkgZm9yIHRoZSBrZXkgc3RyaW5ncyB0aGVtc2VsdmVzLiBJ4oCZbSBub3Qgb3Bw b3NlZCB0byByZW1vdmluZyB0aGUgZmVhdHVyZSBjb21wbGV0ZWx5IHNpbmNlIG5vIG9uZSBoYXMg aW1wbGVtZW50ZWQgaXQgYW5kIGl0IGlzIHNvbWV3aGF0IHVud2llbGR5IHRvIGhhdmUgdG8gZGlz dHJpYnV0ZSB0aGUga2V5LWVuY3J5cHRpb24gcGFzc3dvcmQgb3V0LW9mLWJhbmQuDQoNCkkgZG9u 4oCZdCBoYXZlIGFueSBvcGluaW9uIG9uIHRoZSB0b3BpYywganVzdCBhc2tlZCB0aGUgcXVlc3Rp b24uDQpMZXTigJlzIHNlZSB3aGF0IG91ciBBRHMgdGhpbmsuDQoNCk5vdGUgdGhhdCBJIG1lYW50 IE5DQUNNIChSRkMgNjUzNikuIFllcywgbGV0cyBzZWUgdGhlIG9waW5pb25zIGhlcmUuIEkgYmVs aWV2ZSB0aGF0IFJGQyA2NTM2IHdpbGwgYmUgc3Vic3RhbnRpYWxseSBtb3JlIHdpZGVseSBpbXBs ZW1lbnRlZCBhbmQgZGVwbG95ZWQgdGhhbiBSRkMgNTY0OS4NCg0KDQoqKiBNaW5vciBjb21tZW50 OiBJIGRvbid0IHNlZSBhbnkgZ29vZCByZWFzb24gdG8gc2VwYXJhdGUgcGFyYWdyYXBocyAyIGFu ZCA0Lg0KDQpXaGVyZT8NCg0KSSBmb3Jnb3QgdG8gbWVudGlvbiwgc29ycnkuIEkgd2FzIGNvbnNp ZGVyaW5nIHRoZSDCqyBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyDCuyBzZWN0aW9uLg0KUmUtb3Jk ZXJpbmcgdGhvc2UgdHdvIGNsb3NlbHkgcmVsYXRlZCBwYXJhZ3JhcGhzIGNvdWxkIG1ha2Ugc2Vu c2UuDQoNClllcyDigJMgSSB3aWxsIGNvbWJpbmUgdGhlbS4gVGhlIGZpcnN0IHR3byBwYXJhZ3Jh cGhzIGFyZSByZWNlbnQgYm9pbGVyIHBsYXRlIHBhcmFncmFwaHMgZm9yIHRoZSDigJxTZWN1cml0 eSBDb25zaWRlcmF0aW9uc+KAnSBpbiBhbGwgWUFORyBtb2RlbCBkcmFmdHMuDQoNCg0KT3RoZXIg Y29tbWVudHM6DQoNCioqIHNlY3Rpb24gMS4yOiBpdCBzYXlzOg0KICAgICAgICAiIG8gIEJyYWNr ZXRzICJbIiBhbmQgIl0iIGVuY2xvc2UgbGlzdCBrZXlzLiINCiAgIFRoZXJlIG1heSBiZSBhIGNv bmZ1c2lvbiB3aXRoIHRoZSB0ZXJtICJrZXlzIiBoZXJlIChpLmUuLCBzb21ldGhpbmcgZGlmZmVy ZW50IGZyb20NCiAgIGEgY3J5cHRvZ3JhcGhpYyBrZXkpLg0KDQogICBGb3IgaW5zdGFuY2UsIGlu IHNlY3Rpb24gMy4zOg0KICAgICAgICB8ICArLS1ydyBrZXktY2hhaW4qIFtuYW1lXQ0KICAgbmFt ZSBpcyBub3QgYSBjcnlwdG9ncmFwaGljIGtleS4NCg0KVGhpcyBpcyBwcmV0dHkgbXVjaCBib2ls ZXIgcGxhdGUgdGV4dCBmb3IgWUFORyBtb2RlbCB0cmVlcy4gSSBndWVzcyBJIGNvdWxkIGFkZCB0 aGUgc3RhdGVtZW50Og0KDQrigJxUaGVzZSBZQU5HIGxpc3Qga2V5cyBzaG91bGQgbm90IGJlIGNv bmZ1c2VkIHdpdGggdGhlIGtleS1jaGFpbiBrZXlzLiINCg0KDQpZZXMsIGluIGFuIEktRCBlbnRp cmVseSBkZXZvdGVkIHRvIGtleSBleGNoYW5nZXMsIHVzaW5nIHRoZSBrZXkgdGVybSB3aXRoIGEg dG90YWxseQ0KZGlmZmVyZW50IG1lYW5pbmcgaXMgZXJyb3IgcHJvbmUgKGl0IHRvb2sgbWUgc29t ZSB0aW1lIHRvIGlkZW50aWZ5IHRoZSBwb2ludCkuDQoNCg0KKiogc2VjdGlvbiAyLjI6IHRoZXJl J3Mgc29tZXRoaW5nIEkgZG9uJ3QgdW5kZXJzdGFuZC4gSXQgc2F5czoNCiAgICAzLiAgV2hlbiB0 aGUgc2VuZCBsaWZldGltZSBvZiB0aGUgbmV3IGtleSBiZWNvbWVzIHZhbGlkLCB0aGUgbmV0d29y aw0KICAgICAgICBkZXZpY2VzIHdpdGhpbiB0aGUgZG9tYWluIG9mIGtleSBjaGFpbiB3aWxsIHN0 YXJ0IHNlbmRpbmcgdGhlIG5ldw0KICAgICAgICBrZXkuDQoNCiAgSSBoYXZlIHRoZSBmZWVsaW5n IHlvdSBtZWFuIHRoYXQgdGhpcyBuZXcga2V5IHdpbGwgc3RhcnQgdG8gYmUgdXNlZCBmb3IgdHJh bnNtaXNzaW9ucw0KICAoaW5zdGVhZCBvZiAic3RhcnQgc2VuZGluZyB0aGUgbmV3IGtleSIpLiBE aWQgSSBtaXN1bmRlcnN0b29kIHNvbWV0aGluZz8NCg0KQWJzb2x1dGVseSwgSSB3aWxsIGNvcnJl Y3QgdGhpcy4NCg0KVGhhdCB3YXMgYSBiaWcgbWlzdGFrZSB0aGVuLg0KSXTigJlzIG5pY2UgdG8g c2VlIHRoYXQgU2VjRGlyIHJldmlld3MgYXJlIHVzZWZ1bC4NCg0KQ2hlZXJzLA0KDQogIFZpbmNl bnQNCg0KDQo= --_000_D513AFBCA853Daceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <38A484C686DE404DB9DA716E72915A56@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBWaW5jZW50 LCZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SeKAmXZlIHVwZGF0ZWQgdGhl IGV4YW1wbGVzIHRvIHJlZmVyZW5jZSBobWFjLXNoYS0yNTYgYW5kIGhtYWMtc2hhLTUxMi4gVGhl IHJlYXNvbnMgdGhlIG9sZGVyIChhbmQgdnVsbmVyYWJsZSkgYWxnb3JpdGhtIHdlcmUgcmVmZXJl bmNlZCBpbiBleGFtcGxlcyBpcyB0aGF0IHRoaXMgaXMgd2hhdCAmbmJzcDtpcyBiZWluZyB1c2Vk IGJ5IGN1cnJlbnQgYXBwbGljYXRpb25zLiBIb3dldmVyLCB0aGVyZSBpcyBubyByZWFzb24gbm90 IHRvIHVzZSB0aGUgYmV0dGVyDQogYWxnb3JpdGhtcyAoZS5nLiwgUkZDIDc0NzQpLiZuYnNwOzwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj5BY2VlJm5i c3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNU SU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0 ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsg Qk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxF RlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xp ZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPlZpbmNlbnQgUm9jYSAmbHQ7PGEg aHJlZj0ibWFpbHRvOnZpbmNlbnQucm9jYUBpbnJpYS5mciI+dmluY2VudC5yb2NhQGlucmlhLmZy PC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFu PldlZG5lc2RheSwgQXByaWwgMTIsIDIwMTcgYXQgMjo0NCBBTTxicj4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkFjZWUgTGluZGVtICZsdDs8YSBocmVmPSJtYWls dG86YWNlZUBjaXNjby5jb20iPmFjZWVAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj5WaW5jZW50IFJvY2EgJmx0OzxhIGhyZWY9 Im1haWx0bzp2aW5jZW50LnJvY2FAaW5yaWEuZnIiPnZpbmNlbnQucm9jYUBpbnJpYS5mcjwvYT4m Z3Q7LCBJRVNHICZsdDs8YSBocmVmPSJtYWlsdG86aWVzZ0BpZXRmLm9yZyI+aWVzZ0BpZXRmLm9y ZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3JnIj5zZWNkaXJA aWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3JnIj5z ZWNkaXJAaWV0Zi5vcmc8L2E+Jmd0OywNCiAmcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0 Zi1ydGd3Zy15YW5nLWtleS1jaGFpbi5hbGxAaWV0Zi5vcmciPmRyYWZ0LWlldGYtcnRnd2cteWFu Zy1rZXktY2hhaW4uYWxsQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRy YWZ0LWlldGYtcnRnd2cteWFuZy1rZXktY2hhaW4uYWxsQGlldGYub3JnIj5kcmFmdC1pZXRmLXJ0 Z3dnLXlhbmcta2V5LWNoYWluLmFsbEBpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDtCcmlhbiBXZWlz IChiZXcpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YmV3QGNpc2NvLmNvbSI+YmV3QGNpc2Nv LmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6 IDwvc3Bhbj5SZTogU2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLXJ0Z3dnLXlhbmcta2V5LWNo YWluLTE3PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1B Q19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1 YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3Bh Y2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhl bGxvIEFjZWUsDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5UaGFua3MgZm9yIHRoZSB1cGRhdGUgb2YgeW91ciBkb2N1bWVudDombmJzcDs8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGd3Zy15YW5nLWtleS1j aGFpbi0xOCIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt cnRnd2cteWFuZy1rZXktY2hhaW4tMTg8L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIG1pc3NlZCBpdCB3aGVuIHJlYWRpbmcgeW91 ciBwcmV2aW91cyB2ZXJzaW9uLCBidXQgdXNpbmcgTUQ1IGFuZCBITUFDIFNIQSAxIGluIHRoZSBl eGFtcGxlczwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5vZiBhcHBlbmRpeCBBIGlzIGEgdmVyeSBiYWQg aWRlYSB0aGF0IHdpbGwgdHJpZ2dlciBuZWdhdGl2ZSBjb21tZW50cyBmcm9tIElFU0cuIFBsZWFz ZSByZW1vdmUgdGhlbS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RnVydGhlcm1vcmUgeW914oCZbGwg YWxzbyBiZSBpbiBsaW5lIHdpdGggeW91ciBuZXcgcmVjb21tZW5kYXRpb25zIG9mIFNlY3Rpb24g NS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPkNoZWVycyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPiZuYnNwOyBWaW5jZW50PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFj ZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRp diBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7 IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7Ij4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj5MZSAxMCBhdnIuIDIwMTcgw6AgMTc6MTQsIEFjZWUgTGluZGVtIChhY2Vl KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFjZWVAY2lzY28uY29tIiBjbGFzcz0iIj5hY2VlQGNpc2Nv LmNvbTwvYT4mZ3Q7IGEgw6ljcml0IDo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFu Z2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVh ay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+SGkgVmluY2VudCwmbmJzcDs8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NS Q19CT0RZX1NFQ1RJT04iIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGli cmk7IGZvbnQtc2l6ZTogMTFwdDsgdGV4dC1hbGlnbjogbGVmdDsgYm9yZGVyLXdpZHRoOiAxcHQg bWVkaXVtIG1lZGl1bTsgYm9yZGVyLXN0eWxlOiBzb2xpZCBub25lIG5vbmU7IHBhZGRpbmc6IDNw dCAwaW4gMGluOyBib3JkZXItdG9wLWNvbG9yOiByZ2IoMTgxLCAxOTYsIDIyMyk7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIiBjbGFzcz0iIj5Gcm9tOiA8L3NwYW4+ VmluY2VudCBSb2NhICZsdDs8YSBocmVmPSJtYWlsdG86dmluY2VudC5yb2NhQGlucmlhLmZyIiBj bGFzcz0iIj52aW5jZW50LnJvY2FAaW5yaWEuZnI8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIiBjbGFzcz0iIj5EYXRlOiA8L3NwYW4+TW9uZGF5LCBB cHJpbCAxMCwgMjAxNyBhdCAxMTowMiBBTTxiciBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIiBjbGFzcz0iIj5UbzogPC9zcGFuPkFjZWUgTGluZGVtICZsdDs8YSBocmVm PSJtYWlsdG86YWNlZUBjaXNjby5jb20iIGNsYXNzPSIiPmFjZWVAY2lzY28uY29tPC9hPiZndDs8 YnIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCIgY2xhc3M9IiI+Q2M6 IDwvc3Bhbj5WaW5jZW50IFJvY2EgJmx0OzxhIGhyZWY9Im1haWx0bzp2aW5jZW50LnJvY2FAaW5y aWEuZnIiIGNsYXNzPSIiPnZpbmNlbnQucm9jYUBpbnJpYS5mcjwvYT4mZ3Q7LCBJRVNHICZsdDs8 YSBocmVmPSJtYWlsdG86aWVzZ0BpZXRmLm9yZyIgY2xhc3M9IiI+aWVzZ0BpZXRmLm9yZzwvYT4m Z3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3JnIiBjbGFzcz0iIj5zZWNk aXJAaWV0Zi5vcmc8L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpzZWNkaXJAaWV0Zi5v cmciIGNsYXNzPSIiPnNlY2RpckBpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWls dG86ZHJhZnQtaWV0Zi1ydGd3Zy15YW5nLWtleS1jaGFpbi5hbGxAaWV0Zi5vcmciIGNsYXNzPSIi PmRyYWZ0LWlldGYtcnRnd2cteWFuZy1rZXktY2hhaW4uYWxsQGlldGYub3JnPC9hPiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtcnRnd2cteWFuZy1rZXktY2hhaW4uYWxsQGll dGYub3JnIiBjbGFzcz0iIj5kcmFmdC1pZXRmLXJ0Z3dnLXlhbmcta2V5LWNoYWluLmFsbEBpZXRm Lm9yZzwvYT4mZ3Q7LA0KICZxdW90O0JyaWFuIFdlaXMgKGJldykmcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpiZXdAY2lzY28uY29tIiBjbGFzcz0iIj5iZXdAY2lzY28uY29tPC9hPiZndDs8YnIg Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCIgY2xhc3M9IiI+U3ViamVj dDogPC9zcGFuPlJlOiBTZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcnRnd2cteWFuZy1rZXkt Y2hhaW4tMTc8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tR VU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAg NTsgTUFSR0lOOjAgMCAwIDU7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtp dC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij5IZWxsbyBBY2VlLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KVGhhbmtzIGZvciB5b3VyIHJldmlldy4mbmJzcDs8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+WW914oCZcmUgd2VsY29tZS48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj48c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxlPSJm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxl PSJwYWRkaW5nOiAwcHggMHB4IDBweCA1cHg7IG1hcmdpbjogMHB4IDBweCAwcHggNXB4OyIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0id29yZC13cmFwOiBi cmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazog YWZ0ZXItd2hpdGUtc3BhY2U7Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPioqIFF1 ZXN0aW9uOiB3aGVuIHNheWluZzo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtX aGVuIGNvbmZpZ3VyZWQsIHRoZSBrZXktc3RyaW5ncyBjYW4gYmUgZW5jcnlwdGVkIHVzaW5nIHRo ZSBBRVMgS2V5IFdyYXAgYWxnb3JpdGhtJnF1b3Q7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7eW91IGRvIG5vdCBw cm92aWRlIGFueSByZWNvbW1lbmRhdGlvbi4gSSB1bmRlcnN0YW5kIGl0IGlzIHBvc3NpYmxlLCBi dXQgaXMgdGhlcmUgYW55IGdvb2Q8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO3Jl YXNvbiB0byByZWNvbW1lbmQgaXQgb3IgZG8geW91IGJlbGlldmUgdGhlIE5FVENPTkYgYWNjZXNz IGNvbnRyb2wgZmVhdHVyZSBpcyBzdWZmaWNpZW50PzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJz cDsgJm5ic3A7QXJlIHRoZXJlIGVudmlyb25tZW50cyB3aGVyZSByZWNvbW1lbmRpbmcgaXQgd291 bGQgYmUgbWVhbmluZ2Z1bD8gSSdkIGxpa2UgdG8gaGF2ZSBtb3JlPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPiZuYnNwOyAmbmJzcDtpbmZvcm1hdGlvbi48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7 ICZuYnNwO1RoaXMgaXMgYSBiaXQgc3VycHJpc2luZyB3aGVuIEkgY29tcGFyZSB3aXRoIGxhc3Qg cGFyYWdyYXBoIHdoZXJlIGtleXMgYXJlIFJFQ09NTUVOREVEPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PiZuYnNwOyAmbmJzcDt0byBiZSBlbmNyeXB0ZWQgd2hlbiBzdG9yZWQgd2l0aGluIG5ldHdvcmsg ZGV2aWNlcy48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIi Pjwvc3Bhbj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+ DQpUaGlzIHdhcyBhZGRlZCBhZnRlciBhIGNvbnZlcnNhdGlvbiB3aXRoIEJyaWFuIFdlaXMgd2hv IEkgYmVsaWV2ZSBpcyBhbHNvIG9uIHRoZSBkaXJlY3RvcmF0ZS4gQXQgdGhpcyB0aW1lLCB3ZSBk aWRu4oCZdCBhdmFpbCBOQ0FNLiBBcyBvbmUgd291bGQgc3VybWlzZSwgaXQgd2FzIGZvciBhZGRp dGlvbmFsIHNlY3VyaXR5IGZvciB0aGUga2V5IHN0cmluZ3MgdGhlbXNlbHZlcy4gSeKAmW0gbm90 IG9wcG9zZWQgdG8gcmVtb3ZpbmcgdGhlIGZlYXR1cmUgY29tcGxldGVseQ0KIHNpbmNlIG5vIG9u ZSBoYXMgaW1wbGVtZW50ZWQgaXQgYW5kIGl0IGlzIHNvbWV3aGF0IHVud2llbGR5IHRvIGhhdmUg dG8gZGlzdHJpYnV0ZSB0aGUga2V5LWVuY3J5cHRpb24gcGFzc3dvcmQgb3V0LW9mLWJhbmQuJm5i c3A7PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGRvbuKAmXQgaGF2ZSBhbnkgb3BpbmlvbiBvbiB0aGUgdG9w aWMsIGp1c3QgYXNrZWQgdGhlIHF1ZXN0aW9uLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5MZXTigJlz IHNlZSB3aGF0IG91ciBBRHMgdGhpbmsuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5Ob3RlIHRoYXQgSSBtZWFudCBOQ0FDTSAoUkZDIDY1MzYpLiBZZXMs IGxldHMgc2VlIHRoZSBvcGluaW9ucyBoZXJlLiBJIGJlbGlldmUgdGhhdCBSRkMgNjUzNiB3aWxs IGJlIHN1YnN0YW50aWFsbHkgbW9yZSB3aWRlbHkgaW1wbGVtZW50ZWQgYW5kIGRlcGxveWVkIHRo YW4gUkZDIDU2NDkuJm5ic3A7PC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04i IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NL UVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAw IDU7IE1BUkdJTjowIDAgMCA1OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJr aXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9T RUNUSU9OIiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9C TE9DS1FVT1RFIiBzdHlsZT0icGFkZGluZzogMHB4IDBweCAwcHggNXB4OyBtYXJnaW46IDBweCAw cHggMHB4IDVweDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiIgc3R5 bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Vi a2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4qKiBNaW5vciBjb21tZW50OiBJIGRvbid0IHNlZSBhbnkgZ29vZCByZWFzb24g dG8gc2VwYXJhdGUgcGFyYWdyYXBocyAyIGFuZCA0LjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGlu ZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+PC9zcGFuPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCldoZXJlPyZuYnNwOzwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSBm b3Jnb3QgdG8gbWVudGlvbiwgc29ycnkuIEkgd2FzIGNvbnNpZGVyaW5nIHRoZSDCqyZuYnNwO1Nl Y3VyaXR5IENvbnNpZGVyYXRpb25zJm5ic3A7wrsgc2VjdGlvbi48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+UmUtb3JkZXJpbmcgdGhvc2UgdHdvIGNsb3NlbHkgcmVsYXRlZCBwYXJhZ3JhcGhzIGNvdWxk IG1ha2Ugc2Vuc2UuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L3NwYW4+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5ZZXMg4oCTIEkgd2lsbCBjb21iaW5lIHRoZW0uIFRoZSBmaXJzdCB0d28gcGFyYWdyYXBo cyBhcmUgcmVjZW50IGJvaWxlciBwbGF0ZSBwYXJhZ3JhcGhzIGZvciB0aGUg4oCcU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnPigJ0gaW4gYWxsIFlBTkcgbW9kZWwgZHJhZnRzLiZuYnNwOzwvZGl2Pg0K PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGlk PSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6 ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRl LXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiIgc3R5bGU9ImZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YmxvY2txdW90 ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9InBhZGRpbmc6 IDBweCAwcHggMHB4IDVweDsgbWFyZ2luOiAwcHggMHB4IDBweCA1cHg7IiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7 IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0 ZS1zcGFjZTsiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T3RoZXIgY29tbWVudHM6 PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4qKiBzZWN0aW9uIDEuMjogaXQgc2F5czo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90OyBvICZuYnNwO0JyYWNrZXRzICZxdW90O1smcXVvdDsg YW5kICZxdW90O10mcXVvdDsgZW5jbG9zZSBsaXN0IGtleXMuJnF1b3Q7PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPiZuYnNwOyAmbmJzcDtUaGVyZSBtYXkgYmUgYSBjb25mdXNpb24gd2l0aCB0aGUgdGVy bSAmcXVvdDtrZXlzJnF1b3Q7IGhlcmUgKGkuZS4sIHNvbWV0aGluZyBkaWZmZXJlbnQgZnJvbTwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7YSBjcnlwdG9ncmFwaGljIGtleSkuPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4m bmJzcDsgJm5ic3A7Rm9yIGluc3RhbmNlLCBpbiBzZWN0aW9uIDMuMzo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7JiM0MzstLXJ3IGtleS1j aGFpbiogW25hbWVdPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtuYW1lIGlzIG5v dCBhIGNyeXB0b2dyYXBoaWMga2V5LjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0 YW50OyIgY2xhc3M9IiI+PC9zcGFuPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IiBjbGFzcz0iIj4NClRoaXMgaXMgcHJldHR5IG11Y2ggYm9pbGVyIHBsYXRlIHRleHQgZm9y IFlBTkcgbW9kZWwgdHJlZXMuIEkgZ3Vlc3MgSSBjb3VsZCBhZGQgdGhlIHN0YXRlbWVudDombmJz cDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+ DQrigJxUaGVzZSBZQU5HIGxpc3Qga2V5cyBzaG91bGQgbm90IGJlIGNvbmZ1c2VkIHdpdGggdGhl IGtleS1jaGFpbiBrZXlzLiZxdW90OzwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNU SU9OIiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9D S1FVT1RFIiBzdHlsZT0icGFkZGluZzogMHB4IDBweCAwcHggNXB4OyBtYXJnaW46IDBweCAwcHgg MHB4IDVweDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9 IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0 LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvc3Bhbj48L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5ZZXMsIGluIGFuIEktRCBlbnRpcmVseSBkZXZv dGVkIHRvIGtleSBleGNoYW5nZXMsIHVzaW5nIHRoZSBrZXkgdGVybSB3aXRoIGEgdG90YWxseTwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5kaWZmZXJlbnQgbWVhbmluZyBpcyBlcnJvciBwcm9uZSAoaXQg dG9vayBtZSBzb21lIHRpbWUgdG8gaWRlbnRpZnkgdGhlIHBvaW50KS48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj48c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxl PSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0 eWxlPSJwYWRkaW5nOiAwcHggMHB4IDBweCA1cHg7IG1hcmdpbjogMHB4IDBweCAwcHggNXB4OyIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0id29yZC13cmFw OiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVh azogYWZ0ZXItd2hpdGUtc3BhY2U7Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPioq IHNlY3Rpb24gMi4yOiB0aGVyZSdzIHNvbWV0aGluZyBJIGRvbid0IHVuZGVyc3RhbmQuIEl0IHNh eXM6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgMy4gJm5ic3A7V2hlbiB0aGUg c2VuZCBsaWZldGltZSBvZiB0aGUgbmV3IGtleSBiZWNvbWVzIHZhbGlkLCB0aGUgbmV0d29yazwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGV2aWNlcyB3 aXRoaW4gdGhlIGRvbWFpbiBvZiBrZXkgY2hhaW4gd2lsbCBzdGFydCBzZW5kaW5nIHRoZSBuZXc8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGtleS48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZu YnNwOyBJIGhhdmUgdGhlIGZlZWxpbmcgeW91IG1lYW4gdGhhdCB0aGlzIG5ldyBrZXkgd2lsbCBz dGFydCB0byBiZSB1c2VkIGZvciB0cmFuc21pc3Npb25zPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZu YnNwOyAoaW5zdGVhZCBvZiAmcXVvdDtzdGFydCBzZW5kaW5nIHRoZSBuZXcga2V5JnF1b3Q7KS4g RGlkIEkgbWlzdW5kZXJzdG9vZCBzb21ldGhpbmc/PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5l ICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj48L3NwYW4+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KQWJzb2x1dGVseSwgSSB3aWxsIGNvcnJlY3QgdGhpcy4m bmJzcDs8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYXQgd2FzIGEgYmlnIG1pc3Rha2UgdGhlbi4mbmJzcDs8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SXTigJlzIG5pY2UgdG8gc2VlIHRoYXQgU2VjRGlyIHJldmll d3MgYXJlIHVzZWZ1bC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPkNoZWVycyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyBWaW5jZW50PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_D513AFBCA853Daceeciscocom_-- From nobody Wed Apr 12 07:28:45 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 A42EB129BB3; Wed, 12 Apr 2017 07:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 BzrmLR7JRuDh; Wed, 12 Apr 2017 07:28:33 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA711294A6; Wed, 12 Apr 2017 07:27:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.37,191,1488841200"; d="scan'208,217";a="268819068" Received: from demeter.inrialpes.fr ([194.199.28.3]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Apr 2017 16:27:37 +0200 From: Vincent Roca Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3AEA075E-A344-4ED4-A308-EC61D88F5EA8" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 12 Apr 2017 16:27:36 +0200 In-Reply-To: Cc: Vincent Roca , IESG , "secdir@ietf.org" , "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" , "Brian Weis (bew)" To: "Acee Lindem (acee)" References: <7B34A968-7AC9-4CBA-9F84-61AB90EDF65F@inria.fr> <342F77BA-C6E4-4865-9D98-A2923312D80A@inria.fr> <4E48D017-68C1-41C1-A7B8-6F09C22D2859@inria.fr> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-rtgwg-yang-key-chain-17 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, 12 Apr 2017 14:28:37 -0000 --Apple-Mail=_3AEA075E-A344-4ED4-A308-EC61D88F5EA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Perfect. Thanks Acee. Vincent > Le 12 avr. 2017 =C3=A0 16:23, Acee Lindem (acee) a = =C3=A9crit : >=20 > Hi Vincent,=20 >=20 > I=E2=80=99ve updated the examples to reference hmac-sha-256 and = hmac-sha-512. The reasons the older (and vulnerable) algorithm were = referenced in examples is that this is what is being used by current = applications. However, there is no reason not to use the better = algorithms (e.g., RFC 7474).=20 >=20 > Thanks, > Acee=20 >=20 > From: Vincent Roca > > Date: Wednesday, April 12, 2017 at 2:44 AM > To: Acee Lindem > > Cc: Vincent Roca >, IESG >, "secdir@ietf.org " = >, = "draft-ietf-rtgwg-yang-key-chain.all@ietf.org = " = >, "Brian Weis = (bew)" > > Subject: Re: Secdir review of draft-ietf-rtgwg-yang-key-chain-17 >=20 > Hello Acee, >=20 > Thanks for the update of your document: = https://tools.ietf.org/html/draft-ietf-rtgwg-yang-key-chain-18 = >=20 > I missed it when reading your previous version, but using MD5 and HMAC = SHA 1 in the examples > of appendix A is a very bad idea that will trigger negative comments = from IESG. Please remove them. > Furthermore you=E2=80=99ll also be in line with your new = recommendations of Section 5. >=20 > Cheers, >=20 > Vincent >=20 >=20 >> Le 10 avr. 2017 =C3=A0 17:14, Acee Lindem (acee) > a =C3=A9crit : >>=20 >> Hi Vincent,=20 >>=20 >> From: Vincent Roca > >> Date: Monday, April 10, 2017 at 11:02 AM >> To: Acee Lindem > >> Cc: Vincent Roca >, IESG >, "secdir@ietf.org " = >, = "draft-ietf-rtgwg-yang-key-chain.all@ietf.org = " = >, "Brian Weis = (bew)" > >> Subject: Re: Secdir review of draft-ietf-rtgwg-yang-key-chain-17 >>=20 >> Hello Acee, >>=20 >>> Thanks for your review.=20 >>=20 >> You=E2=80=99re welcome. >>=20 >>=20 >>> ** Question: when saying: >>>=20 >>> "When configured, the key-strings can be encrypted using the = AES Key Wrap algorithm" >>>=20 >>> you do not provide any recommendation. I understand it is = possible, but is there any good >>> reason to recommend it or do you believe the NETCONF access = control feature is sufficient? >>> Are there environments where recommending it would be meaningful? = I'd like to have more >>> information. >>> This is a bit surprising when I compare with last paragraph where = keys are RECOMMENDED >>> to be encrypted when stored within network devices. >>>=20 >>> This was added after a conversation with Brian Weis who I believe is = also on the directorate. At this time, we didn=E2=80=99t avail NCAM. As = one would surmise, it was for additional security for the key strings = themselves. I=E2=80=99m not opposed to removing the feature completely = since no one has implemented it and it is somewhat unwieldy to have to = distribute the key-encryption password out-of-band.=20 >>=20 >> I don=E2=80=99t have any opinion on the topic, just asked the = question. >> Let=E2=80=99s see what our ADs think. >>=20 >> Note that I meant NCACM (RFC 6536). Yes, lets see the opinions here. = I believe that RFC 6536 will be substantially more widely implemented = and deployed than RFC 5649.=20 >>=20 >>=20 >>> ** Minor comment: I don't see any good reason to separate paragraphs = 2 and 4. >>>=20 >>> Where?=20 >>=20 >> I forgot to mention, sorry. I was considering the =C2=AB Security = Considerations =C2=BB section. >> Re-ordering those two closely related paragraphs could make sense. >>=20 >> Yes =E2=80=93 I will combine them. The first two paragraphs are = recent boiler plate paragraphs for the =E2=80=9CSecurity = Considerations=E2=80=9D in all YANG model drafts.=20 >>=20 >>=20 >>> Other comments: >>>=20 >>> ** section 1.2: it says: >>> " o Brackets "[" and "]" enclose list keys." >>> There may be a confusion with the term "keys" here (i.e., = something different from >>> a cryptographic key). >>>=20 >>> For instance, in section 3.3: >>> | +--rw key-chain* [name] >>> name is not a cryptographic key. >>>=20 >>> This is pretty much boiler plate text for YANG model trees. I guess = I could add the statement:=20 >>>=20 >>> =E2=80=9CThese YANG list keys should not be confused with the = key-chain keys." >>>=20 >>=20 >> Yes, in an I-D entirely devoted to key exchanges, using the key term = with a totally >> different meaning is error prone (it took me some time to identify = the point). >>=20 >>=20 >>> ** section 2.2: there's something I don't understand. It says: >>> 3. When the send lifetime of the new key becomes valid, the = network >>> devices within the domain of key chain will start sending = the new >>> key. >>>=20 >>> I have the feeling you mean that this new key will start to be = used for transmissions >>> (instead of "start sending the new key"). Did I misunderstood = something? >>>=20 >>> Absolutely, I will correct this.=20 >>=20 >> That was a big mistake then.=20 >> It=E2=80=99s nice to see that SecDir reviews are useful. >>=20 >> Cheers, >>=20 >> Vincent >>=20 >=20 --Apple-Mail=_3AEA075E-A344-4ED4-A308-EC61D88F5EA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Perfect.
Thanks Acee.

  Vincent

Le = 12 avr. 2017 =C3=A0 16:23, Acee Lindem (acee) <acee@cisco.com> a = =C3=A9crit :

=
Hi Vincent, 

I=E2=80=99ve updated the examples to reference = hmac-sha-256 and hmac-sha-512. The reasons the older (and vulnerable) = algorithm were referenced in examples is that this is what  is = being used by current applications. However, there is no reason not to = use the better algorithms (e.g., RFC 7474). 

Thanks,
Acee 

From: Vincent Roca = <vincent.roca@inria.fr>
Date: Wednesday, = April 12, 2017 at 2:44 AM
To: Acee Lindem = <acee@cisco.com> Cc: Vincent Roca = <vincent.roca@inria.fr>, IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" <draft-ietf-rtgwg-yang-key-chain.all@ietf.org>, "Brian = Weis (bew)" <bew@cisco.com>
Subject: Re: Secdir = review of draft-ietf-rtgwg-yang-key-chain-17

Hello Acee,

Thanks for the update of your document: https://tools.ietf.org/html/draft-ietf-rtgwg-yang-key-chain-18<= /a>

I missed it when reading your previous version, but = using MD5 and HMAC SHA 1 in the examples
of appendix A is a very bad idea that will trigger = negative comments from IESG. Please remove them.
Furthermore you=E2=80=99ll also be in line with your new = recommendations of Section 5.

Cheers,

  Vincent


Le 10 avr. 2017 =C3=A0 17:14, Acee Lindem (acee) <acee@cisco.com> a = =C3=A9crit :

Hi Vincent, 

From: Vincent Roca = <vincent.roca@inria.fr>
Date: Monday, April = 10, 2017 at 11:02 AM
To: Acee Lindem = <acee@cisco.com> Cc: Vincent Roca = <vincent.roca@inria.fr>, IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" <draft-ietf-rtgwg-yang-key-chain.all@ietf.org>, "Brian Weis (bew)" <bew@cisco.com>
Subject: Re: Secdir = review of draft-ietf-rtgwg-yang-key-chain-17

Hello Acee,

Thanks for your review. 

You=E2=80=99re welcome.


** Question: when saying:

        "When configured, the = key-strings can be encrypted using the AES Key Wrap algorithm"

   you do not provide any recommendation. I = understand it is possible, but is there any good
   reason to recommend it or do you believe = the NETCONF access control feature is sufficient?
   Are there environments where recommending = it would be meaningful? I'd like to have more
   information.
   This is a bit surprising when I compare = with last paragraph where keys are RECOMMENDED
   to be encrypted when stored within network = devices.

This was added after a conversation with Brian Weis who I believe is = also on the directorate. At this time, we didn=E2=80=99t avail NCAM. As = one would surmise, it was for additional security for the key strings = themselves. I=E2=80=99m not opposed to removing the feature completely since no one has implemented it and it is somewhat unwieldy to have to = distribute the key-encryption password out-of-band. 

I don=E2=80=99t have any opinion on the topic, just = asked the question.
Let=E2=80=99s see what our ADs think.

Note that I meant NCACM (RFC 6536). Yes, lets see the = opinions here. I believe that RFC 6536 will be substantially more widely = implemented and deployed than RFC 5649. 


** Minor comment: I don't see any good reason to = separate paragraphs 2 and 4.

Where? 

I forgot to mention, sorry. I was considering the = =C2=AB Security Considerations =C2=BB section.
Re-ordering those two closely related paragraphs could = make sense.

Yes =E2=80=93 I will combine them. The first two = paragraphs are recent boiler plate paragraphs for the =E2=80=9CSecurity = Considerations=E2=80=9D in all YANG model drafts. 


Other comments:

** section 1.2: it says:
        " o  Brackets "[" and = "]" enclose list keys."
   There may be a confusion with the term = "keys" here (i.e., something different from
   a cryptographic key).

   For instance, in section 3.3:
        |  +--rw key-chain* = [name]
   name is not a cryptographic key.

This is pretty much boiler plate text for YANG model trees. I guess I = could add the statement: 

=E2=80=9CThese YANG list keys should not be confused with the key-chain = keys."


Yes, in an I-D entirely devoted to key exchanges, using = the key term with a totally
different meaning is error prone (it took me some time = to identify the point).


** section 2.2: there's something I don't understand. It = says:
    3.  When the send lifetime of the new = key becomes valid, the network
        devices within the domain of = key chain will start sending the new
        key.

  I have the feeling you mean that this new key = will start to be used for transmissions
  (instead of "start sending the new key"). Did I = misunderstood something?

Absolutely, I will correct this. 

That was a big mistake then. 
It=E2=80=99s nice to see that SecDir reviews are = useful.

Cheers,

  Vincent

= --Apple-Mail=_3AEA075E-A344-4ED4-A308-EC61D88F5EA8-- From nobody Thu Apr 13 06:23:00 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 BAA1012946B for ; Thu, 13 Apr 2017 06:22:59 -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.49.0 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <149208977975.15788.8415104714840648580.idtracker@ietfa.amsl.com> Date: Thu, 13 Apr 2017 06:22:59 -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, 13 Apr 2017 13:23:00 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-04-13 Reviewer LC end Draft Phillip Hallam-Baker 2017-02-24 draft-ietf-dmm-lma-controlled-mag-params-04 For telechat 2017-04-27 Reviewer LC end Draft Derek Atkins 2017-03-22 draft-ietf-i2nsf-problem-and-use-cases-12 Russ Mundy 2017-04-18 draft-ietf-ipsecme-tcp-encaps-09 Rifaat Shekh-Yusef R2017-03-01 draft-ietf-6man-rfc1981bis-06 David Waltermire None draft-ietf-isis-l2bundles-04 Brian Weis 2017-03-10 draft-bchv-rfc6890bis-06 Last calls: Reviewer LC end Draft Ben Laurie 2017-03-02 draft-ietf-dprive-dtls-and-tls-profiles-09 Melinda Shore 2017-04-09 draft-ietf-core-coap-tcp-tls-07 Takeshi Takahashi 2017-04-18 draft-ietf-grow-bgp-reject-05 Klaas Wierenga 2017-04-21 draft-ietf-grow-large-communities-usage-05 Paul Wouters 2017-04-21 draft-ietf-core-links-json-07 Liang Xia 2017-04-20 draft-ietf-avtcore-rfc5285-bis-09 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-08 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Next in the reviewer rotation: Tom Yu Dacheng Zhang Derek Atkins John Bradley Shaun Cooley Alan DeKok Donald Eastlake Shawn Emery Stephen Farrell Daniel Franke From nobody Fri Apr 14 10:53:09 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 AE8A4120725; Fri, 14 Apr 2017 10:53:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Weis To: Cc: draft-bchv-rfc6890bis.all@ietf.org, iesg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149219238158.15851.11445565927708323216@ietfa.amsl.com> Date: Fri, 14 Apr 2017 10:53:01 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-bchv-rfc6890bis-06 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, 14 Apr 2017 17:53:02 -0000 Reviewer: Brian Weis 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 five page document clarifies that the intent of the term "global" in RFC 6809 is for a special-purpose address to be "globally reachable". It also corrects some errors in the IANA Special-Purpose Address Registries. Since the scope of "global" is clarified rather than changed, there does not seem to be any additional security considerations. None of the error corrections introduce additional security considerations either. The authors obviously came to the same conclusion since they did not include a Security Considerations section. This does not concern me personally, and I'll leave it for the Security ADs to determine if they prefer one added that states "there are no security considerations". I consider the document Ready. Brian Weis From nobody Sun Apr 16 20:07:24 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 90D01126DEE; Sun, 16 Apr 2017 20:07:22 -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 VTwG2tHOltI4; Sun, 16 Apr 2017 20:07:20 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90576124217; Sun, 16 Apr 2017 20:07:20 -0700 (PDT) Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id v3H37JJc080605; Mon, 17 Apr 2017 12:07:19 +0900 (JST) Received: from mail1.nict.go.jp (mail1.nict.go.jp [133.243.18.14]) by gw1.nict.go.jp with ESMTP id v3H37JX2080591; Mon, 17 Apr 2017 12:07:19 +0900 (JST) Received: from VAIO (unknown [133.243.30.60]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail1.nict.go.jp (NICT Mail Spool Server1) with ESMTPS id 02091AC59; Mon, 17 Apr 2017 12:07:18 +0900 (JST) From: "Takeshi Takahashi" To: , , Date: Mon, 17 Apr 2017 12:07:11 +0900 Message-ID: <004d01d2b727$b4e6d540$1eb47fc0$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ja Thread-Index: AdK3J1UT0IHrgr8vTFu5NxLJUeusiQ== X-Virus-Scanned: clamav-milter 0.98.7 at zenith1 X-Virus-Status: Clean Archived-At: Subject: [secdir] Secdir review of draft-ietf-grow-bgp-reject-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, 17 Apr 2017 03:07:22 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. [overall feeling on this draft] ready [overview] This document defines the default behavior of a BGP speaker when there is no import or export policy associated with an External BGP session. This document is very concise. I do not have any discussion issues. Thank you. Take From nobody Mon Apr 17 06:21:25 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 BBAA412ECA3; Mon, 17 Apr 2017 06:21:23 -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 f3pW3ZNGnT9a; Mon, 17 Apr 2017 06:21:21 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 51A7412ECA1; Mon, 17 Apr 2017 06:21:21 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id q78so29560579vke.3; Mon, 17 Apr 2017 06:21:21 -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=H+bbnpXbz7d/dLLaUQcxc8b3YtRHjeHuFWy21Oi21yg=; b=BC7lsUgZmykw71w9p5uFB2T3Op/XlC29ycmkIhsB1XMMaswiqtn66JZQP5vYqgQQLs 4RzHtMxQ+NM3CO1lA7NKA5sbzbGnwRamDLWVqRhhg/aDjt8yCRsHK9k+klM4BRl+DNuk /y5YrmLe3svAdwWJUsyAw9VAFLchI5THXveMuanPBKqb4RRpD4f8dwM19/T06U81HCG6 JwhQgQaR1cmLmyQDgZP6H2G+tPlNmIXrkKrYtxWnuIUmB36QpugAGruDr9EL05XhOaT+ t/MkZ5zAVVBlmebu4auVTU5yU2urlX9leR7lADoXLbHre2NQ0uFGpmePXWEmOFiGUf1E 5jpg== 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=H+bbnpXbz7d/dLLaUQcxc8b3YtRHjeHuFWy21Oi21yg=; b=hMKP0/SKnUiNyWts/iC1SKT0uajY1qXrsGC6e0bnHF/3CfBzD+oTeg/llP5YgcQyEv amJ6Ce43O9zN3JPjeVMja0wl9imH/KqmxJI/HP+A32b5rMc6WIVRgae6iDx2HZBmnWqC tBbOJEpv/g1zJ6zvgjN3fJGhUdJvFO1ljY+CYnZSeswlg7ROVhVfSYusD9/WaHno+5nw fwcYo8ImggW6+9uAzWyRG+xHkvPGb9Zwg3KvpBnvJVVAHboboMqqBWRFNFPqf4/XvjPR jKkDscyCdpjcAELPCVIzzql6CPup5/LIBsjjB7y9v5Lr4dl5m8nM8geT6ryUr9JYSXgd bqoQ== X-Gm-Message-State: AN3rC/7JqmtfTVYSlYSYTVCu0AFcGQdpgNb4KUlXANdi6bBjSepVp+bp 9WJRX4GCMH1n9KyQj6DXPIOVOZQyUM6R X-Received: by 10.31.128.4 with SMTP id b4mr606267vkd.88.1492435280372; Mon, 17 Apr 2017 06:21:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.80.17 with HTTP; Mon, 17 Apr 2017 06:21:20 -0700 (PDT) From: Rifaat Shekh-Yusef Date: Mon, 17 Apr 2017 09:21:20 -0400 Message-ID: To: draft-ietf-6man-rfc1981bis@ietf.org, secdir@ietf.org, The IESG Content-Type: multipart/alternative; boundary=001a1142a312bca8c6054d5caaaa Archived-At: Subject: [secdir] SecDir review of draft-ietf-6man-rfc1981bis-06 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, 17 Apr 2017 13:21:24 -0000 --001a1142a312bca8c6054d5caaaa 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. Summary: Ready with issues The Security Considerations section describes the possible implications of a malicious party sending false ICMPv6 Packet Too Big messages and reasonable ways to mitigate their impact. The section also discusses the implication of filtering valid ICMPv6 Packet Too Big messages, which is one of the limitation of this mechanism, and points to a more robust alternative. Issues ====== Issue 1 - The Security Considerations section, page 14: The first paragraph is discussing the case of malicious party stopping a victim from receiving legitimate Packet Too Big messages. The second paragraph is discussing the filtering of such packets and implies the potential implication of "black holing". It seems to me that in both of these use cases "black holing" is possible, and should be clearly stated as such. Issue 2 - Section 4, 5th paragraph: Should the term "near future" be clearly defined here? Nits ==== Page 6, first paragraph: Drop the "to" before the word "appear" Regards, Rifaat --001a1142a312bca8c6054d5caaaa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of th= e security directorate's
ongoing effort to review all IETF do= cuments being processed by the
IESG.=C2=A0 These comments were wr= itten 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.

Summary: = Ready with issues


The Security Cons= iderations section describes the possible implications of
a malic= ious party sending false ICMPv6 Packet Too Big messages and
reaso= nable ways to mitigate their impact.

The section a= lso discusses the implication of filtering valid ICMPv6
Packet To= o Big messages, which is one of the limitation of this mechanism,
and points to a more robust alternative.


Issues
=3D=3D=3D=3D=3D=3D

Issue 1= - The Security Considerations section, page 14:

T= he first paragraph is discussing the case of malicious party stopping a
victim from receiving legitimate Packet Too Big messages. The second=
paragraph is discussing the filtering of such packets and implie= s the
potential implication of "black holing".

It seems to me that in both of these use cases "black= holing" is possible,
and should be clearly stated as such.<= /div>


Issue 2 - Section 4, 5th paragraph:=

Should the term "near future" be clearl= y defined here?


Nits
=3D= =3D=3D=3D

Page 6, first paragraph:
Drop = the "to" before the word "appear"

<= div>Regards,
=C2=A0Rifaat


--001a1142a312bca8c6054d5caaaa-- From nobody Mon Apr 17 09:22:50 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 C4EB91315AD; Mon, 17 Apr 2017 09:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bD7RZKe_7fC; Mon, 17 Apr 2017 09:22:47 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::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 7F8FB1315E8; Mon, 17 Apr 2017 09:22:29 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id d79so9706773wmi.2; Mon, 17 Apr 2017 09:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=oSSiGpHTat+CnYzWAaKqQ/D8oD82ixPbZiSupKFmeuY=; b=A2FqYX7mV/CHKumHlJbTNhAQyFMBODDYnzvfoPJsB1HDObfIiac0GhbDXl5Fbdmj4p I14YP8wkYUntsLT0wTYwtmhOrSOx4XCNh+kIhsrDL2EhWPN9MSiU/IGfDg/CotPS/kDW nOjw+lVOVMP1E37u0rF/C+hjOscCTtO/OQmDpLX3hU4FJGXbnj4AsuRIGxDTh1M4VAUF npGszWCEsqOKoFEYnKNYnGCdvv0P5AOGaT+kYCJZR2ei6AfiGpH8EDQ6tLmFKp8H3DGm feGjz8rwSAZ89uNpj1KYKsPdfNreUSBkmZoZxs5zNt624GTM+omETt+iSWAibujQfAUX 6pEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=oSSiGpHTat+CnYzWAaKqQ/D8oD82ixPbZiSupKFmeuY=; b=IlTW4LnL1PVjNCrFen/3PfNaCyLlGPTpj9/1O4hn3ZkLuaIVUuGxemPtGgGx6qdLtK qifVQPH/7SYl6TIU8oUGikxG3IrhJSbaN5ancLAmvxtbvuLju9dqwIZ8MOp9IEGrQ8W5 IquAU8GS13DL83zM8dOah9exb/SIQKXH41zuGnaRQxIKpZofwPqL/K6oDDtLxNZlSvRP DmMwRXrcVH7op3RxN6ZLwsMKyAS30ig4c/pNhqkqHyl/npdwKZOmZ4/ncW9UIhcVYAkC XG+4s6++92/ViGm0CCwbuaB76rEABrqN1N0Zftd5PQsSQX/M5cU+r7Of5RU0qHpb8+I4 FIQA== X-Gm-Message-State: AN3rC/5cbraOEzVjdlqvzfkz0jeyBa3/fuCm8Ls65kFu/DEjJ/e1AKNt T6kr11jJHthWol2I8XQ= X-Received: by 10.28.20.85 with SMTP id 82mr9711119wmu.59.1492446148055; Mon, 17 Apr 2017 09:22:28 -0700 (PDT) Received: from ?IPv6:2601:647:4d01:db10:7138:5797:ecde:70ca? ([2601:647:4d01:db10:7138:5797:ecde:70ca]) by smtp.gmail.com with ESMTPSA id z84sm11036148wmh.27.2017.04.17.09.22.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 09:22:26 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9AC639EE-E2DF-4F5C-B64B-0CCB72297B54"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 17 Apr 2017 09:22:20 -0700 In-Reply-To: Cc: Bob Hinden , draft-ietf-6man-rfc1981bis@ietf.org, secdir@ietf.org, IESG To: Rifaat Shekh-Yusef References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] SecDir review of draft-ietf-6man-rfc1981bis-06 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, 17 Apr 2017 16:22:49 -0000 --Apple-Mail=_9AC639EE-E2DF-4F5C-B64B-0CCB72297B54 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Rafaat, Thanks for the review. Comments below. Bob > On Apr 17, 2017, at 6:21 AM, Rifaat Shekh-Yusef = 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 > Summary: Ready with issues >=20 >=20 > The Security Considerations section describes the possible = implications of > a malicious party sending false ICMPv6 Packet Too Big messages and > reasonable ways to mitigate their impact. >=20 > The section also discusses the implication of filtering valid ICMPv6 > Packet Too Big messages, which is one of the limitation of this = mechanism, > and points to a more robust alternative. >=20 >=20 > Issues > =3D=3D=3D=3D=3D=3D >=20 > Issue 1 - The Security Considerations section, page 14: >=20 > The first paragraph is discussing the case of malicious party stopping = a > victim from receiving legitimate Packet Too Big messages. The second > paragraph is discussing the filtering of such packets and implies the > potential implication of "black holing". >=20 > It seems to me that in both of these use cases "black holing" is = possible, > and should be clearly stated as such. How about if I add the following after the two indented paragraphs = describing the attacks: Both of these attacks can cause a black hole connections, that is, = the TCP three-way handshake completes correctly but the connection hangs when data is transferred. >=20 >=20 > Issue 2 - Section 4, 5th paragraph: >=20 > Should the term "near future" be clearly defined here? I think the text is clear given the sentences that follow. The text is = trying not to be too descriptive given that implementations will differ. = It could say things like =E2=80=9Cquickly=E2=80=9D =E2=80=9Cas soon as = possible=E2=80=9D, etc., but I think that=E2=80=99s all about the same. >=20 >=20 > Nits > =3D=3D=3D=3D >=20 > Page 6, first paragraph: > Drop the "to" before the word =E2=80=9Cappear" Thanks, will fix. >=20 > Regards, > Rifaat >=20 >=20 --Apple-Mail=_9AC639EE-E2DF-4F5C-B64B-0CCB72297B54 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY9Ou9AAoJEK7rdBF357uo8a4H/jo1qBvbqL6W4bwaxW2gO9oL v0ht7g6v/dnYmaCxivE1U5yPCCyK34eoU4wlDaCiHt4Y0k7v0CV/SnQwB4YysNAR 3bJ2erjaNkf1B9Lo+Ew/vjRaTcMMWuG7No1LQ1mQuPNHtMeYJikBhomWjxBWYnUY 4wvQO7uJ4lRb6xbZIwHkeNy7BQqgEstQWhE5+cBs5eGHVsevF1fv4wjGIo2R3zlv HTDHW+6xfOXrr4UjGo2QnDI1Q1H6cy3TDoKeTmNidhsm3TG/qqLVlsV7mopTE4gY rIe9KSAX/TMDF1IIoPoNfL6dKMFAZB8i1gvlC142fJKUeeEkdN3D+obkqa2G2g8= =D5NJ -----END PGP SIGNATURE----- --Apple-Mail=_9AC639EE-E2DF-4F5C-B64B-0CCB72297B54-- From nobody Mon Apr 17 10:31: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 421331316E2; Mon, 17 Apr 2017 10:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOPBm7fc0PRf; Mon, 17 Apr 2017 10:31:26 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE1AA1293DA; Mon, 17 Apr 2017 10:31:24 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id q26so77201666uaa.0; Mon, 17 Apr 2017 10:31:24 -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=i9S31sBmdw6QBl9cUYFgRWYytndphSRI+jLbu4FerYI=; b=sA8AA3tX8cvzKhIpsNIxkhGOr2CraQKCu5cVDkLELaT3tCrnBcjvM3piHquU79AIkB vgGWVFtwh4ia/XzJRgz5V8DK6DBLpcQJUN6cEtgzbJmtSoeIGAgcqEUgVjxawXFXDb5G 66ho3b4xVyWXIqHNLarWj3dv4/O7GwfxCiWaylqtwsKgpm+6N8jhZmsf0RoB+MYxDOuG cdJQrU5WRCi3kz1YlTXuGeSFfTdvwXVMClJ9QkgBoeWx1KUuFP2XWq4icxxre9PGBO3C hySLzWW05O0MvRjWJijSfny4xAzB585T5U3YcCfmg+G+nTAsNt7ngn5uNRcF/VAgpSsP MMKQ== 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=i9S31sBmdw6QBl9cUYFgRWYytndphSRI+jLbu4FerYI=; b=blBM9y1w/TWjWtqiKnKYeIzBSch3qlpJVM70YOuyWDYQewWaem4HDEMQn2sUr4gq0h ETKDwYtvKpFMxoQsjK4vxXCmeYpdUHtRKOZL4t7qN0O4Y1KqWihCSypNtLaG7gDTiA5b jZAplRnQlTTpPWUixMvKQvPaJdcfL6x2eta7X5C73YNqV/CUo5btJWqPr16RNh404JWt gn+4UmLDXfB00ahrvMVM/qB7UQfYYg9dtReAk8Typel98TuF25L+BZXX4T+tz50wQg1x akBFkLyAIXLpKnw0MQmMieYHtaAVXk2k9h6KZZWpWeNyG1FKIX8Qm0SrRGHQEIUP5ffN oeXg== X-Gm-Message-State: AN3rC/5Q1w8FvtVxf6m4Tr3wy0bk3CQpwSU0/oYEy5J1d9X67Y8SPQMz JldWrkLxc38ztXbmzMYr7VNRh6zcRw== X-Received: by 10.159.37.248 with SMTP id 111mr10105657uaf.146.1492450283997; Mon, 17 Apr 2017 10:31:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.80.17 with HTTP; Mon, 17 Apr 2017 10:31:23 -0700 (PDT) In-Reply-To: References: From: Rifaat Shekh-Yusef Date: Mon, 17 Apr 2017 13:31:23 -0400 Message-ID: To: Bob Hinden Cc: draft-ietf-6man-rfc1981bis@ietf.org, secdir@ietf.org, IESG Content-Type: multipart/alternative; boundary=001a113d1b9805d047054d602978 Archived-At: Subject: Re: [secdir] SecDir review of draft-ietf-6man-rfc1981bis-06 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, 17 Apr 2017 17:31:28 -0000 --001a113d1b9805d047054d602978 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Apr 17, 2017 at 12:22 PM, Bob Hinden wrote: > Rafaat, > > Thanks for the review. Comments below. > > Bob > > > On Apr 17, 2017, at 6:21 AM, Rifaat Shekh-Yusef > 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. > > > > Summary: Ready with issues > > > > > > The Security Considerations section describes the possible implications > of > > a malicious party sending false ICMPv6 Packet Too Big messages and > > reasonable ways to mitigate their impact. > > > > The section also discusses the implication of filtering valid ICMPv6 > > Packet Too Big messages, which is one of the limitation of this > mechanism, > > and points to a more robust alternative. > > > > > > Issues > > =3D=3D=3D=3D=3D=3D > > > > Issue 1 - The Security Considerations section, page 14: > > > > The first paragraph is discussing the case of malicious party stopping = a > > victim from receiving legitimate Packet Too Big messages. The second > > paragraph is discussing the filtering of such packets and implies the > > potential implication of "black holing". > > > > It seems to me that in both of these use cases "black holing" is > possible, > > and should be clearly stated as such. > > How about if I add the following after the two indented paragraphs > describing the attacks: > > Both of these attacks can cause a black hole connections, that is, the > TCP three-way handshake completes correctly but the connection hangs > when data is transferred. > > Sounds reasonable. > > > > > > > Issue 2 - Section 4, 5th paragraph: > > > > Should the term "near future" be clearly defined here? > > I think the text is clear given the sentences that follow. The text is > trying not to be too descriptive given that implementations will differ. > It could say things like =E2=80=9Cquickly=E2=80=9D =E2=80=9Cas soon as p= ossible=E2=80=9D, etc., but I > think that=E2=80=99s all about the same. > > Yeah, I see what you mean, which makes sense. But I am still trying to make sense of the first sentence, especially the "*MUST attempt*" part. Is the part from "a node MUST attempt" until "near future" needed? Anyway, this is a minor issue, because as you pointed out the following sentence clearly defines what must be done by the node. Regards, Rifaat > > > > > Nits > > =3D=3D=3D=3D > > > > Page 6, first paragraph: > > Drop the "to" before the word =E2=80=9Cappear" > > Thanks, will fix. > > > > > > Regards, > > Rifaat > > > > > > --001a113d1b9805d047054d602978 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 17, 2017 at 12:22 PM, Bob Hinden <bob.hinden@gmail.com<= /a>> wrote:
= Rafaat,

Thanks for the review.=C2=A0 Comments below.

Bob

> On Apr 17, 2017, at 6:21 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> 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.=C2=A0 These comments were written primarily for the benefit of t= he
> security area directors.=C2=A0 Document editors and WG chairs should t= reat
> these comments just like any other last call comments.
>
> Summary: Ready with issues
>
>
> The Security Considerations section describes the possible implication= s of
> a malicious party sending false ICMPv6 Packet Too Big messages and
> reasonable ways to mitigate their impact.
>
> The section also discusses the implication of filtering valid ICMPv6 > Packet Too Big messages, which is one of the limitation of this mechan= ism,
> and points to a more robust alternative.
>
>
> Issues
> =3D=3D=3D=3D=3D=3D
>
> Issue 1 - The Security Considerations section, page 14:
>
> The first paragraph is discussing the case of malicious party stopping= a
> victim from receiving legitimate Packet Too Big messages. The second > paragraph is discussing the filtering of such packets and implies the<= br> > potential implication of "black holing".
>
> It seems to me that in both of these use cases "black holing"= ; is possible,
> and should be clearly stated as such.

How about if I add the following after the two indented paragraphs d= escribing the attacks:

=C2=A0 =C2=A0Both of these attacks can cause a black hole connections, that= is, the
=C2=A0 =C2=A0TCP three-way handshake completes correctly but the connection= hangs
=C2=A0 =C2=A0when data is transferred.


Sounds r= easonable.
=C2=A0

>
>
> Issue 2 - Section 4, 5th paragraph:
>
> Should the term "near future" be clearly defined here?

I think the text is clear given the sentences that follow.=C2=A0 The= text is trying not to be too descriptive given that implementations will d= iffer.=C2=A0 =C2=A0It could say things like =E2=80=9Cquickly=E2=80=9D =E2= =80=9Cas soon as possible=E2=80=9D, etc., but I think that=E2=80=99s all ab= out the same.


Yeah, I = see what you mean, which makes sense.

But I am sti= ll trying to make sense of the first sentence, especially the "MUST= attempt" part.=C2=A0
Is the part from "a node MUST= attempt" until "near future" needed?

Anyway, this is a minor issue, because as you pointed out the following = sentence clearly defines what must be done by the node.

Regards,
=C2=A0Rifaat





>
>
> Nits
> =3D=3D=3D=3D
>
> Page 6, first paragraph:
> Drop the "to" before the word =E2=80=9Cappear"

Thanks, will fix.


>
> Regards,
>=C2=A0 Rifaat
>
>


--001a113d1b9805d047054d602978-- From nobody Mon Apr 17 10:43: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 DF1931316FF; Mon, 17 Apr 2017 10:43:01 -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 2tBI5oCN1sEC; Mon, 17 Apr 2017 10:43:00 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::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 ED58F1316FB; Mon, 17 Apr 2017 10:42:59 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id c55so87267684wrc.3; Mon, 17 Apr 2017 10:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=OBJ2fnnlUGE7PpqsSRLPJUHRiMyNHPsXHZ1SFEe5dFc=; b=PwgBzpK5J/BtkWFPeUrqcrGNzaPuDHqwv/jyUUgodSixDBpTfKuKDoxXulV21D1Exl eyWFyJb10SuP1c8t4KbMRWaLsvU7uit7PdIZqpKToVUN1k1u9tT/aU1BtWS4K3XL3j3K 9AOS9t76uDf8CM+59Xp5iVXTfnetoFQWHkcPdBwdGI/oB8wreF3c8Ijh1PYkszDH51z0 t5aRqZ0QbFaY2YjVVtGY1UO9Rc7i19n1sZEFpFVFg5G5mLfDS6Wh25LnTSLfZQ69c/mt PZE/CuJS16W6hVENX4D7SkmHEft8tfvFApj3qgvH/HVXIm/AtTGeSjPlKH/39552QyJK yFoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=OBJ2fnnlUGE7PpqsSRLPJUHRiMyNHPsXHZ1SFEe5dFc=; b=kN6UuYI/MRQdrW+R7QLuGT9xXJCYHiAxnrVgVIwbqLTBqd3JKoRbwKcElibf03vy9M 7IZ2KOg/1YX3eDkOSlE5gJ047G6kjbpQoZQgVPopikjytIDSKi5vemgqgBqz55pfU1hz vzfRwyQKTvx6wQEvUraUBnYPYPOyK9JfzSmTXkkNjXeBPAmAORdptzuQ4GOfTH9nx2Bl N1eo7Q+sBGxqU9g1gr79TD5kx5coKRHD/Y6PuPd9sCj6q9UjS/JuX1aWJxZUakBmphQJ f1LFIX332RQCO5hVn0phqMsXBFW5oVzkMOxMMeFDhLVsQZvHkrqmGacM/Apq8Dao1W3+ FjAw== X-Gm-Message-State: AN3rC/4JvFyM+Wp1Ni6cXSnkISzRBqjalMyFV41nEnjiXPJjT7mui2h8 o4D0Rrt0eL3WGDOrei0= X-Received: by 10.223.161.130 with SMTP id u2mr18717421wru.203.1492450978421; Mon, 17 Apr 2017 10:42:58 -0700 (PDT) Received: from ?IPv6:2601:647:4d01:db10:7138:5797:ecde:70ca? ([2601:647:4d01:db10:7138:5797:ecde:70ca]) by smtp.gmail.com with ESMTPSA id u206sm11329189wmg.20.2017.04.17.10.42.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 10:42:57 -0700 (PDT) From: Bob Hinden Message-Id: <31D1A9CD-FF14-4B24-B486-CE0C07C9F562@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_453C0148-52D3-4E62-9317-0848C59380C5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 17 Apr 2017 10:42:52 -0700 In-Reply-To: Cc: Bob Hinden , draft-ietf-6man-rfc1981bis@ietf.org, secdir@ietf.org, IESG To: Rifaat Shekh-Yusef References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] SecDir review of draft-ietf-6man-rfc1981bis-06 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, 17 Apr 2017 17:43:02 -0000 --Apple-Mail=_453C0148-52D3-4E62-9317-0848C59380C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Rifaat, > On Apr 17, 2017, at 10:31 AM, Rifaat Shekh-Yusef = wrote: >=20 >=20 >=20 > On Mon, Apr 17, 2017 at 12:22 PM, Bob Hinden = wrote: > Rafaat, >=20 > Thanks for the review. Comments below. >=20 > Bob >=20 > > On Apr 17, 2017, at 6:21 AM, Rifaat Shekh-Yusef = 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. > > > > Summary: Ready with issues > > > > > > The Security Considerations section describes the possible = implications of > > a malicious party sending false ICMPv6 Packet Too Big messages and > > reasonable ways to mitigate their impact. > > > > The section also discusses the implication of filtering valid ICMPv6 > > Packet Too Big messages, which is one of the limitation of this = mechanism, > > and points to a more robust alternative. > > > > > > Issues > > =3D=3D=3D=3D=3D=3D > > > > Issue 1 - The Security Considerations section, page 14: > > > > The first paragraph is discussing the case of malicious party = stopping a > > victim from receiving legitimate Packet Too Big messages. The second > > paragraph is discussing the filtering of such packets and implies = the > > potential implication of "black holing". > > > > It seems to me that in both of these use cases "black holing" is = possible, > > and should be clearly stated as such. >=20 > How about if I add the following after the two indented paragraphs = describing the attacks: >=20 > Both of these attacks can cause a black hole connections, that is, = the > TCP three-way handshake completes correctly but the connection = hangs > when data is transferred. >=20 >=20 > Sounds reasonable. Good, I will include that in the next version. >=20 >=20 > > > > > > Issue 2 - Section 4, 5th paragraph: > > > > Should the term "near future" be clearly defined here? >=20 > I think the text is clear given the sentences that follow. The text = is trying not to be too descriptive given that implementations will = differ. It could say things like =E2=80=9Cquickly=E2=80=9D =E2=80=9Cas = soon as possible=E2=80=9D, etc., but I think that=E2=80=99s all about = the same. >=20 >=20 > Yeah, I see what you mean, which makes sense. >=20 > But I am still trying to make sense of the first sentence, especially = the "MUST attempt" part. > Is the part from "a node MUST attempt" until "near future" needed? >=20 > Anyway, this is a minor issue, because as you pointed out the = following sentence clearly defines what must be done by the node. Right, it=E2=80=99s a lead in to: The node MUST reduce the size of the packets it is sending along the path. Thanks, Bob --Apple-Mail=_453C0148-52D3-4E62-9317-0848C59380C5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY9P6cAAoJEK7rdBF357uoNm0H/jF4jnD0JXnYcyQyGtIrLrmH IqNlUXNKT0yo5li5/4h+mjrtlmrU5iV0e/43Dtb2/LtxnPm0RRKbk7w4x27/ieq2 2UY4Tn1RIBOOpsh022liGRLiRys5THVFu2mWHVto1t2JikVJD4lm1SBUVaq5unNH kAYIgPnSG+CqPhcl7C/YA7JV0HhzUcByK+YMblquUS5dIeRwXOL6o4A7HFaqCk+8 DxTe1pS5YzRqVgIFfOGaV//9drU3RF9VI09zLLC1MiOQsWQ2wL6li13QqUcHfasp v+2vzBNdRjKDuX/7OR0XhofOVV0tOkZJfjDhzG0rNz2FbI44zm5nYjUmchx1gAM= =eKAF -----END PGP SIGNATURE----- --Apple-Mail=_453C0148-52D3-4E62-9317-0848C59380C5-- From nobody Mon Apr 17 17:07: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 D5CBE129400; Mon, 17 Apr 2017 17:06:55 -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 sG9AiJNuLpWJ; Mon, 17 Apr 2017 17:06:54 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::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 B12911293F3; Mon, 17 Apr 2017 17:06:53 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id r69so67552752vke.2; Mon, 17 Apr 2017 17:06:53 -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=eP07W5CVDZFMHtMm/8/voxy5p6kBJPfjaKiYJB6UVz4=; b=ooOlVXmhwb2R9W+xqeHAVNgVuPi+4PGBb1A8ZxSn9Hp2ga9HBsqvgdAeQIkDouzbbr 2r8K+FSpVAgocoOC611seEqVicIN+GF5FsgEPsdJnizytWVCfbTTNjAEJfNdSF+JYS8k g3+8gJP2hem9isRovbReUGlSllnhO2l5o0nwMx64oDg/CEpe3iBpx2p1svT1/upIoluB FK02vXuqS3Y0/6znmyAFil8UAhACRYDcRQI9LFoAWsiCSjnQRYmGxMAuMKoRVEYl0AR0 5y/T2YjCikm0vTvIBfUf5u4rKgR9ul8nXPLF4sFjA8eeAkcdSgPwyuw3gkAmthGyeIv+ 2xdQ== 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=eP07W5CVDZFMHtMm/8/voxy5p6kBJPfjaKiYJB6UVz4=; b=cYWuFOJjWM7wG1nC7APSVIdtmo6nXWKDeW54cuWywTpFmp45dqBozJo5xHgrn6Vwda DR7hg3jIBavikonlZndnKVIthjnK7NG4fJk4q5/EhAGBSU28VwgHPn+qvqe1uHvks06c H9wD3vajtsl7/ywIKkhpRCFuSzHuV5DGZF2lbJ/Ss1ywntq3rwzeRd17+xWX8MY6YbLM /T9yMMP/Kn6SsG2WvevFTyv3w5AsDx7+QMJMamPlMJ46ro79sLro0Rg+YtHcsypylxZY l6BhC/bVNc93ARmr5xe3L5u6U+Vyg+HZWgvtewavi8fbcol3G0GdKZJNAPulNVNWIWSR pbag== X-Gm-Message-State: AN3rC/6VrF4+bAkuW96G9paOOqYF3G/WYlj/dmMiSFaDYatTPjURgTZs pHxDs4vrUQMfiJIn5G8lMQwSRiKUVA== X-Received: by 10.31.210.132 with SMTP id j126mr9019030vkg.95.1492474012881; Mon, 17 Apr 2017 17:06:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.80.17 with HTTP; Mon, 17 Apr 2017 17:06:52 -0700 (PDT) In-Reply-To: <31D1A9CD-FF14-4B24-B486-CE0C07C9F562@gmail.com> References: <31D1A9CD-FF14-4B24-B486-CE0C07C9F562@gmail.com> From: Rifaat Shekh-Yusef Date: Mon, 17 Apr 2017 20:06:52 -0400 Message-ID: To: Bob Hinden Cc: draft-ietf-6man-rfc1981bis@ietf.org, secdir@ietf.org, IESG Content-Type: multipart/alternative; boundary=001a114e55245fd9fc054d65af5e Archived-At: Subject: Re: [secdir] SecDir review of draft-ietf-6man-rfc1981bis-06 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, 18 Apr 2017 00:06:56 -0000 --001a114e55245fd9fc054d65af5e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Bob! On Mon, Apr 17, 2017 at 1:42 PM, Bob Hinden wrote: > Rifaat, > > > On Apr 17, 2017, at 10:31 AM, Rifaat Shekh-Yusef > wrote: > > > > > > > > On Mon, Apr 17, 2017 at 12:22 PM, Bob Hinden > wrote: > > Rafaat, > > > > Thanks for the review. Comments below. > > > > Bob > > > > > On Apr 17, 2017, at 6:21 AM, Rifaat Shekh-Yusef > 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. > > > > > > Summary: Ready with issues > > > > > > > > > The Security Considerations section describes the possible > implications of > > > a malicious party sending false ICMPv6 Packet Too Big messages and > > > reasonable ways to mitigate their impact. > > > > > > The section also discusses the implication of filtering valid ICMPv6 > > > Packet Too Big messages, which is one of the limitation of this > mechanism, > > > and points to a more robust alternative. > > > > > > > > > Issues > > > =3D=3D=3D=3D=3D=3D > > > > > > Issue 1 - The Security Considerations section, page 14: > > > > > > The first paragraph is discussing the case of malicious party stoppin= g > a > > > victim from receiving legitimate Packet Too Big messages. The second > > > paragraph is discussing the filtering of such packets and implies the > > > potential implication of "black holing". > > > > > > It seems to me that in both of these use cases "black holing" is > possible, > > > and should be clearly stated as such. > > > > How about if I add the following after the two indented paragraphs > describing the attacks: > > > > Both of these attacks can cause a black hole connections, that is, t= he > > TCP three-way handshake completes correctly but the connection hangs > > when data is transferred. > > > > > > Sounds reasonable. > > Good, I will include that in the next version. > > > > > > > > > > > > > > Issue 2 - Section 4, 5th paragraph: > > > > > > Should the term "near future" be clearly defined here? > > > > I think the text is clear given the sentences that follow. The text is > trying not to be too descriptive given that implementations will differ. > It could say things like =E2=80=9Cquickly=E2=80=9D =E2=80=9Cas soon as p= ossible=E2=80=9D, etc., but I > think that=E2=80=99s all about the same. > > > > > > Yeah, I see what you mean, which makes sense. > > > > But I am still trying to make sense of the first sentence, especially > the "MUST attempt" part. > > Is the part from "a node MUST attempt" until "near future" needed? > > > > Anyway, this is a minor issue, because as you pointed out the following > sentence clearly defines what must be done by the node. > > Right, it=E2=80=99s a lead in to: > > The node MUST > reduce the size of the packets it is sending along the path. > > Thanks, > Bob > > > > --001a114e55245fd9fc054d65af5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Bob!

On Mon, Apr 17, 2017 at 1:42 PM, Bob Hinden <bob.hinde= n@gmail.com> wrote:
Rifaat,=

> On Apr 17, 2017, at 10:31 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
>
>
>
> On Mon, Apr 17, 2017 at 12:22 PM, Bob Hinden <bob.hinden@gmail.com> wrote:
> Rafaat,
>
> Thanks for the review.=C2=A0 Comments below.
>
> Bob
>
> > On Apr 17, 2017, at 6:21 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
> >
> > 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.
> >
> > Summary: Ready with issues
> >
> >
> > The Security Considerations section describes the possible implic= ations of
> > a malicious party sending false ICMPv6 Packet Too Big messages an= d
> > reasonable ways to mitigate their impact.
> >
> > The section also discusses the implication of filtering valid ICM= Pv6
> > Packet Too Big messages, which is one of the limitation of this m= echanism,
> > and points to a more robust alternative.
> >
> >
> > Issues
> > =3D=3D=3D=3D=3D=3D
> >
> > Issue 1 - The Security Considerations section, page 14:
> >
> > The first paragraph is discussing the case of malicious party sto= pping a
> > victim from receiving legitimate Packet Too Big messages. The sec= ond
> > paragraph is discussing the filtering of such packets and implies= the
> > potential implication of "black holing".
> >
> > It seems to me that in both of these use cases "black holing= " is possible,
> > and should be clearly stated as such.
>
> How about if I add the following after the two indented paragraphs des= cribing the attacks:
>
>=C2=A0 =C2=A0 Both of these attacks can cause a black hole connections,= that is, the
>=C2=A0 =C2=A0 TCP three-way handshake completes correctly but the conne= ction hangs
>=C2=A0 =C2=A0 when data is transferred.
>
>
> Sounds reasonable.

Good, I will include that in the next version.

>
>
> >
> >
> > Issue 2 - Section 4, 5th paragraph:
> >
> > Should the term "near future" be clearly defined here?<= br> >
> I think the text is clear given the sentences that follow.=C2=A0 The t= ext is trying not to be too descriptive given that implementations will dif= fer.=C2=A0 =C2=A0It could say things like =E2=80=9Cquickly=E2=80=9D =E2=80= =9Cas soon as possible=E2=80=9D, etc., but I think that=E2=80=99s all about= the same.
>
>
> Yeah, I see what you mean, which makes sense.
>
> But I am still trying to make sense of the first sentence, especially = the "MUST attempt" part.
> Is the part from "a node MUST attempt" until "near futu= re" needed?
>
> Anyway, this is a minor issue, because as you pointed out the followin= g sentence clearly defines what must be done by the node.

Right, it=E2=80=99s a lead in to:

=C2=A0 =C2=A0The node MUST
=C2=A0 =C2=A0reduce the size of the packets it is sending along the path.
Thanks,
Bob




--001a114e55245fd9fc054d65af5e-- From nobody Mon Apr 17 20:24: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 1F3FF126CF6; Mon, 17 Apr 2017 20:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 jnip28kc0wlE; Mon, 17 Apr 2017 20:24:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2157D126B72; Mon, 17 Apr 2017 20:24:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLF11055; Tue, 18 Apr 2017 03:24:33 +0000 (GMT) Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 18 Apr 2017 04:24:32 +0100 Received: from DGGEML502-MBS.china.huawei.com ([169.254.3.93]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0301.000; Tue, 18 Apr 2017 11:24:28 +0800 From: "Xialiang (Frank)" To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-avtcore-rfc5285-bis@ietf.org" Thread-Topic: SecDir review of draft-ietf-avtcore-rfc5285-bis-09 Thread-Index: AdK380Ap/PwmSJJsR8uigrJB3Hee4Q== Date: Tue, 18 Apr 2017 03:24:28 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.159.76] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12BAC050FDGGEML502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.58F586F2.0038, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.93, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8d7ba681b7979e5a8194a57c3020ab2e Archived-At: Subject: [secdir] SecDir review of draft-ietf-avtcore-rfc5285-bis-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: Tue, 18 Apr 2017 03:24:39 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12BAC050FDGGEML502MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document provides a general mechanism to use the header extension feat= ure of RTP (the Real-Time Transport Protocol). It provides the option to us= e a small number of small extensions in each RTP packet, where the universe= of possible extensions is large and registration is de-centralized. The a= ctual extensions in use in a session are signaled in the setup information = for that session. This document obsoletes RFC5285. The document appears in reasonably good shape. As a whole, the Security Considerations section analyzes the possible threa= ts to the RTP header extension mechanism, and gives the suitable solutions = well. But, there are still several open issues (TBDs) in the document that need t= o be completed before publication. Below a series of my own comments, questions for your consideration. Comments about the Security Considerations Section: In fact, [RFC3264] also considers packet confidential protection by encrypt= ing the packet bodies to protect against eavesdropping. This point is misse= d here. While Secure Real-time Transport Protocol (SRTP) [RFC3711] covers the same = security requirements and measures of RTP header extension mechanism of thi= s draft, but some of its cryptographic algorithms are old and not updated, = such as its default and mandatory-to-implement algorithms like: AES-CM and = NULL for Encryption, HMAC-SHA1 for Message Authentication/Integrity and so = on. Would you please consider to mention this issue in your draft and sugge= st to use the up to date and secure algorithms to adopt to internet of toda= y. For example, AES-CCM/AES-GCM and HMAC-SHA2_256_128/HMAC-SHA2_512_256? Editorial suggestions: Title of section 6: it does not comply with the rule that the first alphabe= t is capital. Setion 1: the last paragraph misses a ending "." A section of Terminology is missed, since there are several words in the dr= aft need this part. Section 4.1.2: in third paragraph, there is a wrong word "dp", which should= be "do". Section 6: suggest to use "SDP Offer/Answer [RFC3264]" to replace "offer/an= swer [RFC3264]". Thank you. B.R. Frank --_000_C02846B1344F344EB4FAA6FA7AF481F12BAC050FDGGEML502MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I have reviewed this document a= s part of the security directorate's ongoing effort to review all IETF docu= ments being processed by the IESG.  These comments were written primar= ily for the benefit of the security area directors.  Document editors and WG chairs should treat these comment= s just like any other last call comments.

 

 

This document provides a genera= l mechanism to use the header extension feature of RTP (the Real-Time Trans= port Protocol). It provides the option to use a small number of small exten= sions in each RTP packet, where the universe of possible extensions is large and registration is de-centralize= d.  The actual extensions in use in a session are signaled in the setu= p information for that session.  This document obsoletes RFC5285.=

 

 

The document appears in reasona= bly good shape.

As a whole, the Security Consid= erations section analyzes the possible threats to the RTP header extension = mechanism, and gives the suitable solutions well.

 

But, there are still several op= en issues (TBDs) in the document that need to be completed before publicati= on.

Below a series of my own commen= ts, questions for your consideration.

 

 

Comments about the Security Con= siderations Section:

 

In fact, [RFC3264] also conside= rs packet confidential protection by encrypting the packet bodies to protec= t against eavesdropping. This point is missed here.

 

While Secure Real-time Transpor= t Protocol (SRTP) [RFC3711] covers the same security requirements and measu= res of RTP header extension mechanism of this draft, but some of its crypto= graphic algorithms are old and not updated, such as its default and mandatory-to-implement algorithms like: AES-CM and= NULL for Encryption, HMAC-SHA1 for Message Authentication/Integrity and so= on. Would you please consider to mention this issue in your draft and sugg= est to use the up to date and secure algorithms to adopt to internet of today. For example, AES-CCM/AES-GCM and= HMAC-SHA2_256_128/HMAC-SHA2_512_256? 

 

 

 

Editorial suggestions:

 

Title of section 6: it does not= comply with the rule that the first alphabet is capital.=

 

Setion 1: the last paragraph mi= sses a ending "." 

 

A section of Terminology is mis= sed, since there are several words in the draft need this part.<= /span>

 

Section 4.1.2: in third paragra= ph, there is a wrong word "dp", which should be "do".

 

Section 6: suggest to use "= ;SDP Offer/Answer [RFC3264]" to replace "offer/answer [RFC3264]&q= uot;.

 

 

Thank you.

 

 

B.R.

Frank

--_000_C02846B1344F344EB4FAA6FA7AF481F12BAC050FDGGEML502MBSchi_-- From nobody Thu Apr 20 03:11:17 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 2A935129C56 for ; Thu, 20 Apr 2017 03:11:16 -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.50.0 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <149268307616.22262.16358012393041574200.idtracker@ietfa.amsl.com> Date: Thu, 20 Apr 2017 03:11:16 -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, 20 Apr 2017 10:11:16 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-04-27 Reviewer LC end Draft Derek Atkins 2017-03-22 draft-ietf-i2nsf-problem-and-use-cases-12 Russ Mundy 2017-04-18 draft-ietf-ipsecme-tcp-encaps-09 David Waltermire None draft-ietf-isis-l2bundles-04 Last calls: Reviewer LC end Draft Ben Laurie 2017-03-02 draft-ietf-dprive-dtls-and-tls-profiles-09 Chris Lonvick R2017-05-15 draft-freytag-lager-variant-rules-05 Melinda Shore 2017-04-09 draft-ietf-core-coap-tcp-tls-07 Klaas Wierenga 2017-04-21 draft-ietf-grow-large-communities-usage-06 Paul Wouters 2017-04-21 draft-ietf-core-links-json-07 Tom Yu 2017-05-02 draft-ietf-bmwg-ipv6-tran-tech-benchmarking-06 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-08 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Next in the reviewer rotation: Dacheng Zhang Derek Atkins John Bradley Shaun Cooley Alan DeKok Donald Eastlake Shawn Emery Stephen Farrell Daniel Franke Daniel Gillmor From nobody Thu Apr 20 16:31:39 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 6AF13129B66; Thu, 20 Apr 2017 16:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=fccoffice.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 PcoZ3biY7cXe; Thu, 20 Apr 2017 16:31:28 -0700 (PDT) Received: from mx0a-0024ed01.pphosted.com (mx0a-0024ed01.pphosted.com [148.163.149.208]) (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 3A763129484; Thu, 20 Apr 2017 16:31:25 -0700 (PDT) Received: from pps.filterd (m0102172.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v3KNSZfi005329; Thu, 20 Apr 2017 23:31:22 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0051.outbound.protection.outlook.com [23.103.198.51]) by mx0a-0024ed01.pphosted.com with ESMTP id 29wqpehsta-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 20 Apr 2017 23:31:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/YPGaOOfRTj5uCfDR2sdZNkkaWypO2yXEk5m2cYLkvo=; b=IOdYgIBXpBTeNlO7reA24hfb+OdEZs9STtlcr2YnT+iQ9mBoiu0eKLh52A+jVPg4YuXWeI8rGjnVK6oVJ6a6GhdBRa3AcpJOxrJD9wi0ofxYMKm0WrR6hh+qSUbmr5nT4qeKQTI8/y9khgYSm2K2kXaGPDHMyVgzfZTKmH4wrsE= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0636.namprd09.prod.outlook.com (10.160.151.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Thu, 20 Apr 2017 23:31:20 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.1034.018; Thu, 20 Apr 2017 23:31:20 +0000 From: Henning Schulzrinne To: Adam Montville , The IESG , "secdir@ietf.org" , "draft-ietf-sipcore-status-unwanted.all@ietf.org" Thread-Topic: secdir review of draft-ietf-sipcore-status-unwanted Thread-Index: AQHSmeRKzTihbJ3ifEuW1R5akJWfS6HPJQ+9 Date: Thu, 20 Apr 2017 23:31:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=fcc.gov; x-originating-ip: [172.56.3.117] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 7:sJ+AIin0rjCxxX34ttIE0Pyo1YbbNnzXgDDtGXIMiqryAKmjsv+lTYsmQ+5uKHYmPse6RuR4qZJzvxnCfTzsUr5cX9+y82FP8sLvdNxTbvZft4nZ8jAodfkPy62tBMhRASpWfT/PVYVcbUtCt+89otZvUX05zAUkHDwHOVqUXVfwkpHEiIpIznIFdR4XUWXNLYXZrgJYlZGmY5NGG21v9cWC43mJ2MbZhtEDetHvBqE4RLSXVSyMXGAx1ZWcuGWbJTTfCqVKGUggbn3sDDEE1ZY3eMX7Oy4sPOUBFks8gNXWeJKgStvK+TFY7F5Im+L0NcJ7blDn81957quDSU88zA== x-ms-office365-filtering-correlation-id: 223a7529-ae28-4043-cb38-08d48845598e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY1PR09MB0636; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123564025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(6072148); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39840400002)(39400400002)(39450400003)(377454003)(6436002)(7696004)(6306002)(54896002)(229853002)(8676002)(2900100001)(76176999)(81166006)(53936002)(38730400002)(345774005)(5660300001)(9686003)(7736002)(54356999)(99286003)(74316002)(236005)(8936002)(53546009)(606005)(50986999)(6506006)(66066001)(77096006)(7906003)(39060400002)(25786009)(55016002)(6246003)(19627405001)(3660700001)(3280700002)(189998001)(2201001)(86362001)(2501003)(2950100002)(6116002)(33656002)(122556002)(3846002)(102836003)(230783001)(2906002)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634E935DE45A859DBDD099AEA1B0CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2017 23:31:20.1322 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-20_21:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-sipcore-status-unwanted 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, 20 Apr 2017 23:31:33 -0000 --_000_CY1PR09MB0634E935DE45A859DBDD099AEA1B0CY1PR09MB0634namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you for your review and comments. A bit of background: "reporting to government authorities" typically means = that this is reported via the complaint interface to, in the US, the Federa= l Trade Commission (FTC) or the FCC (Federal Communications Commission). In= addition to complaints entered via web forms, this is actually currently d= one by a number of commercial call spam blocking applications. The FTC gets= hundreds of thousand of such complaints and the FCC tens of thousand per m= onth. Needless to say, a single complaint is unlikely to trigger a search w= arrant. (Indeed, the 'unwanted' mechanism, in this case, essentially just s= hort-circuits the process by avoiding consumers having to fill out the web = form.) I didn't want to get into these country-specific details, but if a differen= t formulation, e.g., with a bit more detail, would be useful, let me know. = I'll add the notion of a complaint database, to make clear that this isn't,= by itself (say) a criminal complaint. [FTC statistics are at https://www.ftc.gov/news-events/press-releases/2017/= 03/ftc-releases-annual-summary-consumer-complaints] Henning ________________________________ From: Adam Montville Sent: Friday, March 10, 2017 4:21:16 PM To: The IESG; secdir@ietf.org; draft-ietf-sipcore-status-unwanted.all@ietf.= org Subject: secdir review of draft-ietf-sipcore-status-unwanted 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 primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This draft is ready with (possible) issues. This draft defines a new SIP response code, 666 "Unwanted", which allows ca= lled parties to indicate when a call is unwanted. The intent of the Unwant= ed response code is to provide feedback to global or user-specific filterin= g algorithms (implemented by carriers) from the context of a SIP-initiated = call. >From a security perspective, there's nothing wrong with the draft, and the = Security Considerations section addresses what one might expect (denial of = service, relying on the code only when authenticated caller identities are = in play, etc.) It seems that the biggest risk is false blocks, callers hav= ing their feelings hurt, or folks not getting the calls they may expect -- = but implementers are made aware of these. A potential issue can be seen by taking these two sentences together: "Impl= ementations will have to make appropriate trade-offs between falsely labeli= ng a caller as unwanted and delivering unwanted calls", "The service provid= er...MAY report the calling party identity to government authorities". Thi= s gives rise to the possibility that a mislabeled caller could be reported = to authorities, when there is no real reason for such. Either way, I found the document to be clear and well-written. And while I= list the draft as "ready with issues" here, it may be the case that there = are no issues from the perspective of the ADs for whom I have performed thi= s review. Kind regards, Adam --_000_CY1PR09MB0634E935DE45A859DBDD099AEA1B0CY1PR09MB0634namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you for your review and comments.


A bit of background: "reporting to government authorities" typ= ically means that this is reported via the complaint interface to, in the U= S, the Federal Trade Commission (FTC) or the FCC (Federal Communications Co= mmission). In addition to complaints entered via web forms, this is actually currently done by a number of commercial c= all spam blocking applications. The FTC gets hundreds of thousand of such c= omplaints and the FCC tens of thousand per month. Needless to say, a single= complaint is unlikely to trigger a search warrant. (Indeed, the 'unwanted' mechanism, in this case, essenti= ally just short-circuits the process by avoiding consumers having to fill o= ut the web form.)


I didn't want to get into these country-specific details, but if a diffe= rent formulation, e.g., with a bit more detail, would be useful, let me kno= w. I'll add the notion of a complaint database, to make clear that this isn= 't, by itself (say) a criminal complaint.


[FTC statistics are at https://www.ft= c.gov/news-events/press-releases/2017/03/ftc-releases-annual-summary-consum= er-complaints]



Henning

From: Adam Montville <ad= am.w.montville@gmail.com>
Sent: Friday, March 10, 2017 4:21:16 PM
To: The IESG; secdir@ietf.org; draft-ietf-sipcore-status-unwanted.al= l@ietf.org
Subject: secdir review of draft-ietf-sipcore-status-unwanted
 
I have reviewed this document as part of the security directorate's on= going effort to review all IETF documents being processed by the IESG. = ; These comments were written primarily for the benefit of the security are= a directors.  Document editors and WG chairs should treat these comments just like any other last call comments.=

This draft is ready with (possible) issues.

This draft defines a new SIP response code, 666 "Unwanted", = which allows called parties to indicate when a call is unwanted.  The = intent of the Unwanted response code is to provide feedback to global or us= er-specific filtering algorithms (implemented by carriers) from the context of a SIP-initiated call. 

From a security perspective, there's nothing wrong with the draft, and= the Security Considerations section addresses what one might expect (denia= l of service, relying on the code only when authenticated caller identities= are in play, etc.)  It seems that the biggest risk is false blocks, callers having their feelings hurt, or f= olks not getting the calls they may expect -- but implementers are made awa= re of these.

A potential issue can be seen by taking these two sentences together: = "Implementations will have to make appropriate trade-offs between fals= ely labeling a caller as unwanted and delivering unwanted calls", &quo= t;The service provider...MAY report the calling party identity to government authorities".  This gives rise to t= he possibility that a mislabeled caller could be reported to authorities, w= hen there is no real reason for such.

Either way, I found the document to be clear and well-written.  A= nd while I list the draft as "ready with issues" here, it may be = the case that there are no issues from the perspective of the ADs for whom = I have performed this review.

Kind regards,

Adam
--_000_CY1PR09MB0634E935DE45A859DBDD099AEA1B0CY1PR09MB0634namp_-- From nobody Thu Apr 20 17:00:28 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 4075D129BC1; Thu, 20 Apr 2017 17:00:27 -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 FX1JvQzpFdOF; Thu, 20 Apr 2017 17:00:24 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 63612129BCE; Thu, 20 Apr 2017 17:00:23 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id a103so94017920ioj.1; Thu, 20 Apr 2017 17:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=dF5ZxuxqRYdDBoknqnOatVEr3rNLc7cTmAn0EiNjmJ0=; b=DL2tApPvE1TNa5SAhDPKxUYJuNH1BCtAvDb9hh1RpfVAfJO59t+1mx+5kAtptlHMMR vZFIzhDOcQYtZzWCVaxEETCHGRhpHPqP1SllUVVKpmj7g9hIi/kNHiRIyzpbKMJSFQja 4oOijkQpXNgUfIdqvQH78HRJegYnssp0MD/MsnrpHUlesMU+r8mfhUiIh/Zfy/KfsM6A 6it680AY2qKh36wy+q3oA7aLnHdH/oYqEbop0ZeN9WvqUv8yp1XB/M/9gMOkdGcrMoak qA72LCyNFrx+KanRpxsx2UQGNXY2X93VhuNilIy6LASEyH/7teBk0Mhut+PhdF4XY0M8 fEug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=dF5ZxuxqRYdDBoknqnOatVEr3rNLc7cTmAn0EiNjmJ0=; b=Ml5ab+/azaSw1FsUSif3Zmiwgcf9ZR07JhpEVa2w+swobowlYMs2aXqj9E8SHG0OmP lf6hbOvyj6s2CF8448GNHgFOwXVSwwID0K5PpNkBFAZBhafJJH0edxJIZ4cyYQJX9dSQ QRVl0ZjUcWRP8rgRjmC8PgBEgvjKJpgrNOUFy63YwKsenP49CLZhft7WmPjn6DNGURIa 0T8bVLL13Q6E74Md83jmBNKk2lENV+rs/XZ12QvLuuLj3lTmsCbmLn6gvy3wq1LLWka2 2YjDLBC6BhuuNVPc5QhqGPqm31Q0Hkj6LcEO5RClAsZtY5y4HNg26uEEjgE7OwjOBpbA kM9g== X-Gm-Message-State: AN3rC/6Gel8pHrdEWfWicbxN0zwTv6xjVzn0jV+aAKll5Td8qdK5kY2G Oqxe6aWEsH53P21QpWThNlG8mHB7wjj6 X-Received: by 10.107.53.196 with SMTP id k65mr726518ioo.106.1492732818703; Thu, 20 Apr 2017 17:00:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adam Montville Date: Fri, 21 Apr 2017 00:00:07 +0000 Message-ID: To: Henning Schulzrinne , The IESG , "secdir@ietf.org" , "draft-ietf-sipcore-status-unwanted.all@ietf.org" Content-Type: multipart/alternative; boundary=001a11449722674e16054da1f1ec Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-sipcore-status-unwanted 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, 21 Apr 2017 00:00:27 -0000 --001a11449722674e16054da1f1ec Content-Type: text/plain; charset=UTF-8 Thanks for the clarification. Should be good. On Thu, Apr 20, 2017 at 6:31 PM Henning Schulzrinne < Henning.Schulzrinne@fcc.gov> wrote: > Thank you for your review and comments. > > > A bit of background: "reporting to government authorities" typically means > that this is reported via the complaint interface to, in the US, the > Federal Trade Commission (FTC) or the FCC (Federal Communications > Commission). In addition to complaints entered via web forms, this is > actually currently done by a number of commercial call spam blocking > applications. The FTC gets hundreds of thousand of such complaints and the > FCC tens of thousand per month. Needless to say, a single complaint is > unlikely to trigger a search warrant. (Indeed, the 'unwanted' mechanism, in > this case, essentially just short-circuits the process by avoiding > consumers having to fill out the web form.) > > > I didn't want to get into these country-specific details, but if a > different formulation, e.g., with a bit more detail, would be useful, let > me know. I'll add the notion of a complaint database, to make clear that > this isn't, by itself (say) a criminal complaint. > > > [FTC statistics are at > https://www.ftc.gov/news-events/press-releases/2017/03/ftc-releases-annual-summary-consumer-complaints > ] > > > Henning > ------------------------------ > *From:* Adam Montville > *Sent:* Friday, March 10, 2017 4:21:16 PM > *To:* The IESG; secdir@ietf.org; > draft-ietf-sipcore-status-unwanted.all@ietf.org > *Subject:* secdir review of draft-ietf-sipcore-status-unwanted > > 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 is ready with (possible) issues. > > This draft defines a new SIP response code, 666 "Unwanted", which allows > called parties to indicate when a call is unwanted. The intent of the > Unwanted response code is to provide feedback to global or user-specific > filtering algorithms (implemented by carriers) from the context of a > SIP-initiated call. > > From a security perspective, there's nothing wrong with the draft, and the > Security Considerations section addresses what one might expect (denial of > service, relying on the code only when authenticated caller identities are > in play, etc.) It seems that the biggest risk is false blocks, callers > having their feelings hurt, or folks not getting the calls they may expect > -- but implementers are made aware of these. > > A potential issue can be seen by taking these two sentences together: > "Implementations will have to make appropriate trade-offs between falsely > labeling a caller as unwanted and delivering unwanted calls", "The service > provider...MAY report the calling party identity to government > authorities". This gives rise to the possibility that a mislabeled caller > could be reported to authorities, when there is no real reason for such. > > Either way, I found the document to be clear and well-written. And while > I list the draft as "ready with issues" here, it may be the case that there > are no issues from the perspective of the ADs for whom I have performed > this review. > > Kind regards, > > Adam > --001a11449722674e16054da1f1ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the clarification. Should be good.
On Thu, Apr 20, 2017 at 6:31 PM Henning Schulzrinne <<= a href=3D"mailto:Henning.Schulzrinne@fcc.gov">Henning.Schulzrinne@fcc.gov> wrote:

Thank you for your review and comments.


A bit of background: "reporting to government authorities" typ= ically means that this is reported via the complaint interface to, in the U= S, the Federal Trade Commission (FTC) or the FCC (Federal Communications Co= mmission). In addition to complaints entered via web forms, this is actually currently done by a number of commercial c= all spam blocking applications. The FTC gets hundreds of thousand of such c= omplaints and the FCC tens of thousand per month. Needless to say, a single= complaint is unlikely to trigger a search warrant. (Indeed, the 'unwanted' mechanism, in this case,= essentially just short-circuits the process by avoiding consumers having t= o fill out the web form.)


I didn't want to get into these country-specific details, but if a d= ifferent formulation, e.g., with a bit more detail, would be useful, let me= know. I'll add the notion of a complaint database, to make clear that = this isn't, by itself (say) a criminal complaint.


[FTC statistics are at=C2=A0https://www.ftc.gov/news-events/press-releases/2017= /03/ftc-releases-annual-summary-consumer-complaints]



Henning

From:= Adam Montville <adam.w.montville@gmail.com>
Sent: Friday, March 10, 2017 4:21:16 PM
To: The IESG; s= ecdir@ietf.org; draft-ietf-sipcore-status-unwanted.all@ietf.o= rg
Subject: secdir review of draft-ietf-sipcore-status-unwanted
=C2=A0
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 securit= y area directors.=C2=A0 Document editors and WG chairs should treat these comments just like any other last call comments.=

This draft is ready with (possible) issues.

This draft defines a new SIP response code, 666 "Unwanted", = which allows called parties to indicate when a call is unwanted.=C2=A0 The = intent of the Unwanted response code is to provide feedback to global or us= er-specific filtering algorithms (implemented by carriers) from the context of a SIP-initiated call.=C2=A0

From a security perspective, there's nothing wrong with the draft,= and the Security Considerations section addresses what one might expect (d= enial of service, relying on the code only when authenticated caller identi= ties are in play, etc.) =C2=A0It seems that the biggest risk is false blocks, callers having their feelings hurt, or f= olks not getting the calls they may expect -- but implementers are made awa= re of these.

A potential issue can be seen by taking these two sentences together: = "Implementations will have to make appropriate trade-offs between fals= ely labeling a caller as unwanted and delivering unwanted calls", &quo= t;The service provider...MAY report the calling party identity to government authorities".=C2=A0 This gives rise to t= he possibility that a mislabeled caller could be reported to authorities, w= hen there is no real reason for such.

Either way, I found the document to be clear and well-written.=C2=A0 A= nd while I list the draft as "ready with issues" here, it may be = the case that there are no issues from the perspective of the ADs for whom = I have performed this review.

Kind regards,

Adam
--001a11449722674e16054da1f1ec-- From nobody Fri Apr 21 00:57:43 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 E0DD6129524; Fri, 21 Apr 2017 00:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcvAV-Cf5WNT; Fri, 21 Apr 2017 00:57:40 -0700 (PDT) Received: from out63-ams.mf.surf.net (out63-ams.mf.surf.net [145.0.1.63]) (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 ACED0129440; Fri, 21 Apr 2017 00:57:39 -0700 (PDT) Received: from mail.het.net.je (mail.het.net.je [192.87.110.20]) by outgoing3-ams.mf.surf.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id v3L7vbcb004018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Apr 2017 09:57:37 +0200 Received: from [2001:610:148:beef:506:6b2d:d4da:3b40] (helo=192-87-30-241.terena.org.mail) by mail.het.net.je with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1d1TRV-0005ax-F1; Fri, 21 Apr 2017 09:57:25 +0200 Date: Fri, 21 Apr 2017 09:57:38 +0200 From: Klaas Wierenga To: The IESG , secdir@ietf.org, draft-ietf-grow-large-communities-usage.all@ietf.org Message-ID: X-Mailer: Airmail (420) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Antivirus: no malware found X-Bayes-Prob: 0.9986 (Score 4.9, tokens from: p-out:default, p:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.87.110.20; country=NL; latitude=52.3824; longitude=4.8995; http://maps.google.com/maps?q=52.3824,4.8995&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0bTaTVBSz - 65f1bb2c0025 - 20170421 X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: Subject: [secdir] review of draft-ietf-grow-large-communities-usage-06 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, 21 Apr 2017 07:57:42 -0000 =C2=A0 Hi, I have reviewed this document as part of the security directorate's ongoi= ng effort to review all IET=46 documents being processed by the IESG. The= se comments were written primarily for the benefit of the security area d= irectors. Document editors and WG chairs should treat these comments just= like any other last call comments.=C2=A0 This document presents examples of how operators may use BGP large commun= ities to support some typical use-cases. In general the document is well written and I have no major issues, and I= consider it: ready with nits (see below) My one nit is that even though I think that the statement in the security= considerations =22Operators should note the recommendations in Section 1= 1(https://tools.ietf.org/html/draft-ietf-grow-large-communities-usage-06=23= section-11) of BGP Operations and Security =5BR=46C7454(https://tools.ietf.org/html/rfc7454)= =5D=E2=80=9D is largely true, it would be useful if the authors would exp= and a little on that, not being an expert in this field, I am wondering i= f the use-cases you describe in one way or the other influence the R=46C7= 454 considerations. Klaas From nobody Fri Apr 21 01:06:06 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 282FF129A90 for ; Fri, 21 Apr 2017 01:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.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 s7coihJULatk for ; Fri, 21 Apr 2017 01:05:56 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 970B3129A9E for ; Fri, 21 Apr 2017 01:05:55 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id w64so9799519wma.0 for ; Fri, 21 Apr 2017 01:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=rEj/ZaAdlvTFy9r3RxeSfk+UYH+qn8Q5QzEDK+YtDFU=; b=j9SL2rB1/7ZSHrjYQzarhJeY5cK5YXrsKOLH8Ls9jOVmmBGanftym/K8tUdIzGU9cl LX007Nk3IXe8+d11r7CxeGrGBhiaE4HUwir1vN81DWJF3Iuhsxr2ohbE/I5e0eP7mxIA MPJGheWrPGWqVqLcvRcFKZQU5NRwliG5Tuq9bkrRbHZ4whrcMzQKK2SHrckrGKaD7HL2 b1YfIidKmIigH/1O6/ZxKticDv9Gzlm9YiicuUZA6Taj2QFUcwvnf8pJKmLsqZs32km8 kz3zs6erfY1efqHFsdfwpfM4kT6vJ6zLvglyuACm7QIazyr1BgNODZ+6m71tCFASnpPR UR8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=rEj/ZaAdlvTFy9r3RxeSfk+UYH+qn8Q5QzEDK+YtDFU=; b=ocLYdyc7YhWB0ROOEiXIqeuRNkOANkpg3ZShatw1C928IsghLFt3psDrbCBYCRr8UR i9C1Qrjc8AK49OwIgotaIO+nPpKQMSXvhXE2PwTtSv1F/cDui5TYY9gIrH+IF+KQgAle 5sRvPWg2/BYaYwEBvxZpIqY1jYIHQtlx+iSy/POkD6I0WnTgAHStDy4ipeIVUeUFu/ah tJPdALADUOewmdJWDja6hxcIgOXeuwW6iw83+LQXh8Jadmy6uXX9juj955ZXHEiG9fgR CmSNMT1eMZK0Eio7RJuptd3ahBHg4jGZAoNCe4+nFV3ib4tprKRwLRHC4Zqlhl1pc/T7 MjpA== X-Gm-Message-State: AN3rC/5ptTpoJU/wrvKhZuEgYz0pq7ltCfI+Je18An6QUSkG6tLT8NpZ unJubLewTm6LlQ== X-Received: by 10.28.74.18 with SMTP id x18mr6934780wma.64.1492761953961; Fri, 21 Apr 2017 01:05:53 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:60e6:77e2:3793:28ea]) by smtp.gmail.com with ESMTPSA id w186sm1026804wme.26.2017.04.21.01.05.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 01:05:52 -0700 (PDT) Date: Fri, 21 Apr 2017 10:05:50 +0200 From: Job Snijders To: Klaas Wierenga Cc: The IESG , secdir@ietf.org, draft-ietf-grow-large-communities-usage.all@ietf.org Message-ID: <20170421080550.tv4eb5hs4uzac2c3@Vurt.local> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [secdir] review of draft-ietf-grow-large-communities-usage-06 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, 21 Apr 2017 08:05:59 -0000 On Fri, Apr 21, 2017 at 09:57:38AM +0200, Klaas Wierenga wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments.  > > This document presents examples of how operators may use BGP large > communities to support some typical use-cases. > > In general the document is well written and I have no major issues, > and I consider it: ready with nits (see below) > > My one nit is that even though I think that the statement in the security considerations "Operators should note the recommendations in Section 11(https://tools.ietf.org/html/draft-ietf-grow-large-communities-usage-06#section-11) of BGP > Operations and Security > [RFC7454(https://tools.ietf.org/html/rfc7454)]” is largely true, it > would be useful if the authors would expand a little on that, not > being an expert in this field, I am wondering if the use-cases you > describe in one way or the other influence the RFC7454 considerations. In -07 - following the GenART review we expanded the security section, does that address your nit? https://tools.ietf.org/rfcdiff?url2=draft-ietf-grow-large-communities-usage-07.txt Kind regards, Job From nobody Fri Apr 21 01:12: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 80EB61296B3; Fri, 21 Apr 2017 01:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlwmSuNZxxmP; Fri, 21 Apr 2017 01:12:13 -0700 (PDT) Received: from out64-ams.mf.surf.net (out64-ams.mf.surf.net [145.0.1.64]) (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 B35F1129440; Fri, 21 Apr 2017 01:12:12 -0700 (PDT) Received: from mail.het.net.je (mail.het.net.je [192.87.110.20]) by outgoing3-ams.mf.surf.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id v3L8C91t012042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Apr 2017 10:12:10 +0200 Received: from [2001:610:148:beef:506:6b2d:d4da:3b40] (helo=192-87-30-241.terena.org.mail) by mail.het.net.je with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1d1TfZ-0005fO-Uy; Fri, 21 Apr 2017 10:11:57 +0200 Date: Fri, 21 Apr 2017 10:12:10 +0200 From: Klaas Wierenga To: Job Snijders Cc: draft-ietf-grow-large-communities-usage.all@ietf.org, The IESG , secdir@ietf.org Message-ID: In-Reply-To: <20170421080550.tv4eb5hs4uzac2c3@Vurt.local> References: <20170421080550.tv4eb5hs4uzac2c3@Vurt.local> X-Mailer: Airmail (420) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="58f9beda_4775f9f2_35d" X-Antivirus: no malware found X-Bayes-Prob: 0.0135 (Score 0, tokens from: p-out:default, p:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.87.110.20; country=NL; latitude=52.3824; longitude=4.8995; http://maps.google.com/maps?q=52.3824,4.8995&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0bTaUcazd - aa21068eac54 - 20170421 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: Subject: Re: [secdir] review of draft-ietf-grow-large-communities-usage-06 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, 21 Apr 2017 08:12:15 -0000 --58f9beda_4775f9f2_35d Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Job, Yes it does (and apologies for not spotting the 07 version).=C2=A0 Klaas On 21 April 2017 at 10:05:43, Job Snijders (job=40instituut.net) wrote: On =46ri, Apr 21, 2017 at 09:57:38AM +0200, Klaas Wierenga wrote: =20 > I have reviewed this document as part of the security directorate's =20 > ongoing effort to review all IET=46 documents being processed by the =20 > IESG. These comments were written primarily for the benefit of the =20 > security area directors. Document editors and WG chairs should treat =20 > these comments just like any other last call comments.=C2=A0 =20 > =20 > This document presents examples of how operators may use BGP large =20 > communities to support some typical use-cases. =20 > =20 > In general the document is well written and I have no major issues, =20 > and I consider it: ready with nits (see below) =20 > =20 > My one nit is that even though I think that the statement in the securi= ty considerations =22Operators should note the recommendations in Section= 11(https://tools.ietf.org/html/draft-ietf-grow-large-communities-usage-0= 6=23section-11) of BGP =20 > Operations and Security =20 > =5BR=46C7454(https://tools.ietf.org/html/rfc7454)=5D=E2=80=9D is largel= y true, it =20 > would be useful if the authors would expand a little on that, not =20 > being an expert in this field, I am wondering if the use-cases you =20 > describe in one way or the other influence the R=46C7454 considerations= . =20 In -07 - following the GenART review we expanded the security section, =20 does that address your nit=3F =20 https://tools.ietf.org/rfcdiff=3Furl2=3Ddraft-ietf-grow-large-communities= -usage-07.txt =20 Kind regards, =20 Job =20 --58f9beda_4775f9f2_35d Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline