From nobody Thu Jun 1 18:47:05 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEAF12948B for ; Thu, 1 Jun 2017 18:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAtyM5OhQrXt for ; Thu, 1 Jun 2017 18:47:02 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 E86FD129AA0 for ; Thu, 1 Jun 2017 18:47:01 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id m47so4455238iti.0 for ; Thu, 01 Jun 2017 18:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PUf77JD/Em6y1AZdkr7/O7DVOKAaBRGJCcDxJYkPDKI=; b=Ex3jsQCKImJAmd2C8n3a3MVQ/6M8GA8b9BY0IDGEU1OvK156zGNbo2pmkTXI43Kg3U tehjtW5QmAu5bgoV8yOWrOmLSEUSIRXXiCeywJv0IgtQj5I9WXTElwgco7Jz0MxMsTcZ aSlXg+jRxciCZHZI2l7VjLh5S615Qc+D4wjO1PSvfr5kVDdamKDxntiOKP2jfSyVjCWy J0brOhmn5UnP3l2r6gkINO81Js4rAW/k2bPbpWqzloMxD++eGapl8JDNsoUNYNOcrJWD Tugi4LbXN/TaVDHb0xH8V9To5FzyBA+kg0y3oSFJJ9Ue98NM1TyJoZ+L4OPNij6hTBH8 x4IQ== 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=PUf77JD/Em6y1AZdkr7/O7DVOKAaBRGJCcDxJYkPDKI=; b=TnyqPGD2dGNG97y13NXMAJjghSGPWjs1ef7Vp3sx4QtgBCNA3QieVEZPmlVRb5C6JO 7mlfHOcf9hHQWZx1gEbDYWrtwRtYkxhR9RAQ02DaJumFCzfOmk4y94ZcELoGyo3Rk06f 1/5JWW4soOQl/WjtKJUXlu7GRY9Ms1b+k9vwVG1lAkxV4Fr5FIFKme23M9bpsGdJMX8e SEWjmQBMX74WDFa46WlpFLccL/dJ7O2kPdydmJUX6og2PpIRZEbg4wob0xbjW9UQEKs1 NpU3VWtrvsbUPg+XZCEAkWvodwDuTwJqR2+7TbcYLDPJ69MH82eYIPpB7oO/N3BORA9b bu4g== X-Gm-Message-State: AODbwcCV7cB7Ua7RbPq9dyXvXcqms5J0PcavMELQvScQaMULnne/yyZk +hTR2ZoYeTHOxQlFy1VwJWyA4N8Q+6U89GtO/A== X-Received: by 10.36.16.211 with SMTP id 202mr2360019ity.2.1496368021198; Thu, 01 Jun 2017 18:47:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.35.37 with HTTP; Thu, 1 Jun 2017 18:46:39 -0700 (PDT) In-Reply-To: References: From: William Denniss Date: Thu, 1 Jun 2017 18:46:39 -0700 Message-ID: To: Donald Eastlake Cc: "iesg@ietf.org" , draft-ietf-oauth-native-apps.all@ietf.org, "secdir@ietf.org" Content-Type: multipart/alternative; boundary="001a1144b1745ba5be0550f054c2" Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-oauth-native-apps-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 01:47:03 -0000 --001a1144b1745ba5be0550f054c2 Content-Type: text/plain; charset="UTF-8" Thank you for your review Donald. Changes actioning your comments are staged in Github, and will be reflected in version 12. Replies inline. On Tue, May 23, 2017 at 7:40 PM, Donald Eastlake 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. Document editors and WG chairs should treat these comments just > like any other last call comments. > > The primary goal of this BCP draft is to specify that OAuth 2.0 > authorization requests from native apps should only be made through > external user agents, primarily the user's browser, as opposed to an > embedded user-agent. > > > Security Considerations > > This BCP is all at quite a high level. It talks about interprocess and > world wide web interactions to effectuate OAuth 2.0, mechanisms with > which I am not too familiar. But, all mechanism details are in other > documents.. The recommendations seem reasonable and the beginning of > the Security Considerations section paints a somewhat dismal security > picture compared with that typical of cryptographic or protocol > security. > > As best I can tell, it is ready with trivial nits as listed below. > > > Minor > > SSO is used multiple times but never expanded. > Fixed. > > > Trivial English Improvements > > Page 13, Section 8.8 > "for native apps to include" -> "that native apps include" > Done. > > Page , Appendix B > "in an generic manner" -> "in a generic manner" > Done. > > Page 19, Appendix B.4, 2nd paragraph > Last word of first line and first word of second line are duplicates. > Fixed. > > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > --001a1144b1745ba5be0550f054c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for your review Donald.=C2=A0

Changes actioning your comments are staged=C2=A0in Github= , and will be reflected in version 12.

Replies inl= ine.

On Tue, M= ay 23, 2017 at 7:40 PM, Donald Eastlake <d3e3e3@gmail.com> wr= ote:
I have reviewed t= his document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. Document editors and WG chairs should treat these comments just
like any other last call comments.

The primary goal of this BCP draft is to specify that OAuth 2.0
authorization requests from native apps=C2=A0 should only be made through external user agents, primarily the user's browser, as opposed to an embedded user-agent.


Security Considerations

This BCP is all at quite a high level. It talks about interprocess and
world wide web interactions to effectuate OAuth 2.0, mechanisms with
which I am not too familiar. But, all mechanism details are in other
documents.. The recommendations seem reasonable and the beginning of
the Security Considerations section paints a somewhat dismal security
picture compared with that typical of cryptographic or protocol
security.

As best I can tell, it is ready with trivial nits as listed below.


Minor

SSO is used multiple times but never expanded.

Fixed.
=C2=A0


Trivial English Improvements

Page 13, Section 8.8
"for native apps to include" -> "that native apps include= "

Done.
=C2=A0

Page , Appendix B
"in an generic manner" -> "in a generic manner"
<= /blockquote>

Done.
=C2=A0

Page 19, Appendix B.4, 2nd paragraph
Last word of first line and first word of second line are duplicates.

Fixed.

=C2=A0
=


Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com

--001a1144b1745ba5be0550f054c2-- From nobody Fri Jun 2 04:33:15 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 C562B12EB49 for ; Fri, 2 Jun 2017 04:33:13 -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.52.0 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <149640319379.31768.1065362186676565890.idtracker@ietfa.amsl.com> Date: Fri, 02 Jun 2017 04:33:13 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 11:33:14 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-06-08 Reviewer LC end Draft Daniel Franke 2017-05-15 draft-ietf-bmwg-vswitch-opnfv-03 Daniel Gillmor 2017-05-14 draft-ietf-netmod-yang-model-classification-07 Tobias Gondrom 2017-05-14 draft-ietf-calext-caldav-attachments-02 Takeshi Takahashi R2017-05-02 draft-ietf-grow-bgp-reject-08 For telechat 2017-06-22 Reviewer LC end Draft Catherine Meadows 2017-06-15 draft-ietf-tcpm-dctcp-07 Sandra Murphy 2017-06-09 draft-ietf-pals-p2mp-pw-lsp-ping-03 Yoav Nir 2017-06-09 draft-ietf-mpls-app-aware-tldp-08 For telechat 2017-07-06 Reviewer LC end Draft Scott Kelly None draft-turner-est-extensions-08 Daniel Migault 2017-06-13 draft-ietf-precis-7700bis-07 Matthew Miller 2017-06-13 draft-ietf-precis-7564bis-07 Last calls: Reviewer LC end Draft Watson Ladd 2017-06-06 draft-ietf-v6ops-unique-ipv6-prefix-per-host-03 Ben Laurie 2017-06-05 draft-ietf-v6ops-v4v6-xlat-prefix-01 David Mandelberg 2017-06-28 draft-baeuerle-netnews-cancel-lock-05 Adam Montville 2017-06-13 draft-ietf-bmwg-dcbench-terminology-09 Russ Mundy 2017-06-13 draft-ietf-bmwg-dcbench-methodology-07 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-10 Dacheng Zhang 2017-05-04 draft-ietf-spring-resiliency-use-cases-11 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Next in the reviewer rotation: Magnus Nystrom Hilarie Orman Radia Perlman Vincent Roca Joseph Salowey Rich Salz Yaron Sheffer Rifaat Shekh-Yusef Melinda Shore Robert Sparks From nobody Fri Jun 2 05:47:22 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5541412EB89 for ; Fri, 2 Jun 2017 05:47:19 -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_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=unavailable 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 fp0phyDi2_G0 for ; Fri, 2 Jun 2017 05:47:13 -0700 (PDT) Received: from smtp74.iad3a.emailsrvr.com (smtp74.iad3a.emailsrvr.com [173.203.187.74]) (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 792FF12EB8E for ; Fri, 2 Jun 2017 05:47:09 -0700 (PDT) Received: from smtp26.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp26.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id DE49E5538; Fri, 2 Jun 2017 08:47:03 -0400 (EDT) Received: from app59.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp26.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id CB25A555F; Fri, 2 Jun 2017 08:47:03 -0400 (EDT) X-Sender-Id: scott@hyperthought.com Received: from app59.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Fri, 02 Jun 2017 08:47:03 -0400 Received: from hyperthought.com (localhost [127.0.0.1]) by app59.wa-webapps.iad3a (Postfix) with ESMTP id 90D99200C1; Fri, 2 Jun 2017 08:47:03 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Fri, 2 Jun 2017 05:47:03 -0700 (PDT) X-Auth-ID: scott@hyperthought.com Date: Fri, 2 Jun 2017 05:47:03 -0700 (PDT) From: "Scott G. Kelly" To: "secdir@ietf.org" , "iesg@ietf.org" , draft-turner-est-extensions.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain Message-ID: <1496407623.591322313@apps.rackspace.com> X-Mailer: webmail/12.9.1-RC Archived-At: Subject: [secdir] secdir review of draft-turner-est-extensions-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: Fri, 02 Jun 2017 12:47:19 -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 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.=0A=0AThe summary of the review is ready with ni= ts.=0A=0AExcerpting from the abstract, =0A=0A The EST (Enrollment over Se= cure Transport) protocol defined a Well-=0A Known URI (Uniform Resource I= dentifier): /.well-known/est. EST also=0A defined several path component= s that clients use for PKI (Public Key=0A Infrastructure) services, namel= y certificate enrollment (e.g.,=0A /simpleenroll).=0A=0AThis document des= cribes 6 additional path components, including a Package Availability List = (PAL) that informs clients of packages that are available/authorized.=0A=0A= The document is clear and well-written. Maybe this sentence=0A=0A o /firmwa= re - Some client firmware and software support automatic=0A updates m= echanism and some do not.=0A=0Acould use a little word-smithing for verb/no= un agreement?=0A=0AThe security considerations section lists many RFCs upon= which this one depends, but I was surprised to find it only mentions RFC70= 30 with respect to server-generated asymmetric key pairs. My impression is = that this doc extends 7030, so all of 7030's security considerations apply = here. I guess this is implicit, but I would state it.=0A=0A--Scott=0A From nobody Fri Jun 2 17:32: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 A192D12EAED; Fri, 2 Jun 2017 17:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 OnekNmZwv8yg; Fri, 2 Jun 2017 17:32:16 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 535F112EAEA; Fri, 2 Jun 2017 17:32:16 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id h4so109942506oib.3; Fri, 02 Jun 2017 17:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=aYRLQ8VKLuwCdfAuMmGdthTMbhUsfk4xX/oUgiMbs7c=; b=Ch2Pv/zvTuSBbT1pNpiNkzYtk0MTEyd9N2wUm1LihDpdH3NzJ3OLvr7+0PbOHaVcyK 8Zj71/z2wCTcI9sdPorSaM9PZUmN6GK1oHKVVBhu6+nk3kdtkQjaU/y/8y8Xel+MmBxo b/W//hIxWMQR2XB61uPpUdBBSM0eEc44aHbDP5XzgwPvRXSfl4XQ0vU4D45EDgGMU/qY ozeTcXK1h97Ejmd+JbtuyitGbaGQNuz7mmlL2e919qTRClh4unJzfAOkO4MfwgB3hxkQ UmUUMifs7zUNAzrF2K+rRhf2bLepyQ9RBkjgmEeOQplfb8idNwQNhHz1L4qyp9evPopG nyaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=aYRLQ8VKLuwCdfAuMmGdthTMbhUsfk4xX/oUgiMbs7c=; b=mpgQHdavX1t/lD70ZOgZrsAbFi1HOi8RFUT2f8Uxn7dGC9BmK/l7iQdGvZDHTEDe9C qoNufks1Sylgq0KDLoWkaVj671+e0+xpjLiKe68Pt6laADnOK/V3qC2oO9H2yJbwc058 CAbZ01IdUP20xqmQIXpbTv+BVWufQ1t0qMfsLaACytsjeuomuwux0uG5/XehKnxZd0r3 kGLKu+JBqHAqa3ULMr0SmWs1vnNnnRZp/XpGum2YlGPOPGCEYZ2F1wJzLmqOkQHIC4y0 dphTum8Bf/9o7xtj9zTmIycSemjlRYySQa1EKSTtaRerQvr/p5SpqoRGl/VA0DU2bLSv oV6w== X-Gm-Message-State: AKS2vOzXcmn1msS/zUn3qKRxTB/fNQ0ut1aEYuqc5a3vkXqA6r5zDGmf bUsEtwW6mkqkZH07iUV4kZmR4elZfg== X-Received: by 10.157.34.117 with SMTP id o108mr5888572ota.214.1496449935753; Fri, 02 Jun 2017 17:32:15 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.23.5 with HTTP; Fri, 2 Jun 2017 17:32:15 -0700 (PDT) In-Reply-To: References: From: Phillip Hallam-Baker Date: Fri, 2 Jun 2017 20:32:15 -0400 X-Google-Sender-Auth: RCiJRzANYjuCi2vkL4Ao0umMx0A Message-ID: To: David Noveck Cc: Spencer Dawkins at IETF , NFSv4 , "secdir@ietf.org" Content-Type: multipart/alternative; boundary="001a113bf388d847320551036623" Archived-At: Subject: Re: [secdir] [nfsv4] SECDIR Review of draft-ietf-nfsv4-umask-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 00:32:18 -0000 --001a113bf388d847320551036623 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 31, 2017 at 9:23 AM, David Noveck wrote: > Phillip Hallam-Baker wrote > > They are not so much a security plan as a collection of random thoughts > jotted down > > in haphazard fashion.=E2=80=8B > > This is fair criticism. I've looked through the Security Considerations > sections of RFCs 3530, 7530, and 5661 and the differences are minor. No= ne > of these sections were written to provide a security plan, but tried to > describe, somewhat inelegantly, the evolution of NFS from its origins in = a > LAN environment towards NFSv4 which attempted to provide some reasonable > security features. Any security needs were provided by RPCSECGSS, and no= t > by the protocol itself. > > > There is clearly no coherent model of what NFS security should achieve, > what the > > threats are, what controls are deployed to control them > > An alternative would have been to define an entirely new protocol with a > real security plan covering these matters, but that wasn't the goal then. > If it had been, we would probably have a much more secure protocol that > nobody would deploy. What happened was that NFSv4 was defined requiring > implementation, but not use, of RPCSECGSS. Even today, many NFSv4 > deployments use AUTH_SYS and very few which use RPCSECGSS, use integrity = or > privacy, because of performance issues. Security is provided by use of > physically isolated networks or VPNs. That was considered adequate when > RFCs 3530, 5661, and 7530 were written and approved. > =E2=80=8BWhen the decisions were made performance was likely an issue. No l= onger. turning on encryption has negligible impact in the HTTP world. What would be an issue is that TLS ain't exactly designed to be NFS friendly. =E2=80=8B =E2=80=8BProtocols do wear out over time. And often it is simpler to start = from scratch than to try and extend something beyond capacity.=E2=80=8B =E2=80= =8BI don't see a need to rewrite NFS though. As a file sharing protocol it is fine. What I would look into changing is the transport layer. When I look at a protocol, I ask, how much of this protocol needs to interact with other 'stuff' because that is the stuff that is really expensive to change. In NFS, that is the parts that interact with the file system semantics operating system drivers and all that. =E2=80=8BInstead of layering over UDP/TCP I would look at QUIC. Sure, you a= re not using that any time soon in a standard but it is probably in a decent enough state now to start looking at the possibilities. Instead of using GSS which is a framework for fifty shades of almost always password auth, I would move to authenticating and encrypting using public key based credentials. =E2=80=8BWhat you would need to make this work is a mechanism to make manag= ement of the public key credentials=E2=80=8B really simple and that just happens to = be what I am working on right now. I am pretty sure that it would suit a file system because I am using it to support an object storage system which is not the same thing but it is close enough. The main difference I see between the two is that a remote file system allows you to modify remote files while in an object system the only modification supported is to append additional data to an append only log. =E2=80=8B --001a113bf388d847320551036623 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Ma= y 31, 2017 at 9:23 AM, David Noveck <davenoveck@gmail.com> wrote:
Phillip Ha= llam-Baker wrote
> They are not so much a security= plan as a collection of random thoughts jotted down=C2=A0
> in haph= azard fashion.=E2=80=8B

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

> There is clearly no coherent model of what = NFS security should achieve, what the=C2=A0
> threats are, wha= t controls are deployed to control them

An = alternative would have been to define an entirely new protocol with a real = security plan covering these matters, but that wasn't the goal then.=C2= =A0 If it had been, we would probably have a much more secure protocol that= nobody would deploy.=C2=A0 What happened was that NFSv4 was defined requir= ing implementation, but not use, of RPCSECGSS.=C2=A0 Even today, many NFSv4= deployments use AUTH_SYS and very few which use RPCSECGSS, use integrity o= r privacy, because of performance issues.=C2=A0 Security is provided by use= of physically isolated networks or VPNs. =C2=A0 That was considered adequa= te when RFCs 3530, 5661, and 7530 were written and approved.

=E2=80=8BWhen the decisions were made performance was likely an i= ssue. No longer. turning on encryption has negligible impact in the HTTP wo= rld. What would be an issue is that TLS ain't exactly designed to be NF= S friendly.
=E2=80=8B
=E2=80=8BProtocols= do wear out over time. And often it is simpler to start from scratch than = to try and extend something beyond capacity.=E2=80=8B =E2=80=8BI don't = see a need to rewrite NFS though. As a file sharing protocol it is fine. Wh= at I would look into changing is the transport layer.

When I look at a protocol, I ask, h= ow much of this protocol needs to interact with other 'stuff' becau= se that is the stuff that is really expensive to change. In NFS, that is th= e parts that interact with the file system semantics operating system drive= rs and all that.=C2=A0

=E2=80=8BIns= tead of layering over UDP/TCP I would look at QUIC. Sure, you are not using= that any time soon in a standard but it is probably in a decent enough sta= te now to start looking at the possibilities.

Instead of using GSS which is a framework for fifty sh= ades of almost always password auth, I would move to authenticating and enc= rypting using public key based credentials.

=E2=80=8BWhat you would need t= o make this work is a mechanism to make management of the public key creden= tials=E2=80=8B really simple and that just happens to be what I am working = on right now. I am pretty sure that it would suit a file system because I a= m using it to support an object storage system which is not the same thing = but it is close enough. The main difference I see between the two is that a= remote file system allows you to modify remote files while in an object sy= stem the only modification supported is to append additional data to an app= end only log.=C2=A0
=E2=80=8B

--001a113bf388d847320551036623-- From nobody Fri Jun 2 18:06: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 E75FE129473; Fri, 2 Jun 2017 18:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 WWmcg4rirHZ1; Fri, 2 Jun 2017 18:06:07 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44AED129470; Fri, 2 Jun 2017 18:06:07 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id AAF5DC002824; Fri, 2 Jun 2017 18:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=T5UDZivlH7Oz5w xoM19910BuRvs=; b=Hl+9ZOeXEgYu6Kie++3f+sweI/fLL27RFKcOBod0i1qrny MRsWAzh7Hw3+Ysp+M+Ofi7r1R0FATalhcyymLkqMQMVBSynyUViOOHV+PVPhzD72 edvAtsBx1NSWrdGQghevTzTWqSN/iLodHx1w/3aLtNTv9HjJ+P+F3iZ/23Yng= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 3A891C002823; Fri, 2 Jun 2017 18:06:06 -0700 (PDT) Date: Fri, 2 Jun 2017 20:06:02 -0500 From: Nico Williams To: Phillip Hallam-Baker Cc: David Noveck , "secdir@ietf.org" , Spencer Dawkins at IETF , NFSv4 Message-ID: <20170603010601.GD2903@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [secdir] [nfsv4] SECDIR Review of draft-ietf-nfsv4-umask-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 01:06:08 -0000 On Fri, Jun 02, 2017 at 08:32:15PM -0400, Phillip Hallam-Baker wrote: > On Wed, May 31, 2017 at 9:23 AM, David Noveck wrote: > Instead of using GSS which is a framework for fifty shades of almost always > password auth, I would move to authenticating and encrypting using public > key based credentials. What are you on about?? GSS-API has a number of mechanisms, including: - Kerberos V5 [RFC4121] - PKU2U, which is PKIX based (no reference, as it's not yet standardized at the IETF) - SCRAM (password based) and others. Nico -- From nobody Sat Jun 3 01:56:49 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4459C124281 for ; Sat, 3 Jun 2017 01:56:42 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dR_f2ust4PMR for ; Sat, 3 Jun 2017 01:56:39 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 73DAA12441E for ; Sat, 3 Jun 2017 01:56:39 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id m47so38561568iti.0 for ; Sat, 03 Jun 2017 01:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DQaMfrUhzMug8Q8ltHiBAayl3PCvKhYF6qannGo+AVc=; b=bBra2xmInz5vpFJ0x/tABohep8C03sVuy3Od07nL7AXuGkD6H4wtbzz+6HKvkfvFG8 +/yX9KKF0mEkdT8YzAigynqSay7GEz/EZGrA6k6XTykKV2hWZnYViRZiXmeEEDXg1Bcs EG3iOWfznqmW3l1E6k9MJDR2CqEdsVfV69ujQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DQaMfrUhzMug8Q8ltHiBAayl3PCvKhYF6qannGo+AVc=; b=ZMm1vmSuJ2Eltr+YdxbucGUdMbO/YHbDtSyBEWIgr8LTvC7fxTFEV6cSeVfa8+0F8h M3vaO5cxcTcWbD/9PpRTltCTSiL/wapauu0XyjjpqjaL0FZILYXwv2udE1vNsUAdmBfO dlI9U6uy4MgnUQ73RVpzE6LK/Pic6Ph00KXtc25klFVxCH0bjQp2B25ZdXJtlEk3+fKh qYRZoLDdXI5fR9es9WIyAEx5+Xm3+zDJvZ9/Bo7FJ43KhtTKjkMbHotyZ2SltA8HJOZ7 kYmwVUndQWjeAHBdlZk9CPXX0tAgkNbBM935ZkFxlvXdGJaV9A7AcvG8gMBSERavhkEj eTRQ== X-Gm-Message-State: AKS2vOwzNvramR1aPKQMqxOuCMV5mHWLQX4YFi6qTE4YBEVpm+K0BsSv IkLEzri/hdn3lhhT X-Received: by 10.107.159.196 with SMTP id i187mr1032436ioe.143.1496480198537; Sat, 03 Jun 2017 01:56:38 -0700 (PDT) Received: from [5.5.33.178] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id m195sm11253077ioe.35.2017.06.03.01.56.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Jun 2017 01:56:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner X-Priority: 3 (Normal) In-Reply-To: <1496407623.591322313@apps.rackspace.com> Date: Sat, 3 Jun 2017 04:56:35 -0400 Cc: "secdir@ietf.org" , "iesg@ietf.org" , draft-turner-est-extensions.all@tools.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9C090308-86DF-4114-A7D1-E5C2CB8916DF@sn3rd.com> References: <1496407623.591322313@apps.rackspace.com> To: "Scott G. Kelly" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] secdir review of draft-turner-est-extensions-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: Sat, 03 Jun 2017 08:56:42 -0000 > On Jun 2, 2017, at 08:47, Scott G. Kelly = 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 > The summary of the review is ready with nits. >=20 > Excerpting from the abstract,=20 >=20 > The EST (Enrollment over Secure Transport) protocol defined a Well- > Known URI (Uniform Resource Identifier): /.well-known/est. EST also > defined several path components that clients use for PKI (Public Key > Infrastructure) services, namely certificate enrollment (e.g., > /simpleenroll). >=20 > This document describes 6 additional path components, including a = Package Availability List (PAL) that informs clients of packages that = are available/authorized. >=20 > The document is clear and well-written. Maybe this sentence >=20 > o /firmware - Some client firmware and software support automatic > updates mechanism and some do not. >=20 > could use a little word-smithing for verb/noun agreement? How about: o /firmware - Some client firmware and software support automatic update mechanisms and some do not. > The security considerations section lists many RFCs upon which this = one depends, but I was surprised to find it only mentions RFC7030 with = respect to server-generated asymmetric key pairs. My impression is that = this doc extends 7030, so all of 7030's security considerations apply = here. I guess this is implicit, but I would state it. I can make this more explicit: This document relies on many other specifications; however, all of the = the [RFC7030] security considerations apply. spt > --Scott >=20 >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Sat Jun 3 05:54: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 EA775129B71 for ; Sat, 3 Jun 2017 05:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 TTaFFdviXUkS for ; Sat, 3 Jun 2017 05:54:41 -0700 (PDT) Received: from smtp74.iad3a.emailsrvr.com (smtp74.iad3a.emailsrvr.com [173.203.187.74]) (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 8121B129511 for ; Sat, 3 Jun 2017 05:54:41 -0700 (PDT) Received: from smtp18.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp18.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C46372519A; Sat, 3 Jun 2017 08:54:35 -0400 (EDT) Received: from app23.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp18.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id B0FAE23062; Sat, 3 Jun 2017 08:54:35 -0400 (EDT) X-Sender-Id: scott@hyperthought.com Received: from app23.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Sat, 03 Jun 2017 08:54:35 -0400 Received: from hyperthought.com (localhost [127.0.0.1]) by app23.wa-webapps.iad3a (Postfix) with ESMTP id 768D6C003A; Sat, 3 Jun 2017 08:54:35 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Sat, 3 Jun 2017 05:54:35 -0700 (PDT) X-Auth-ID: scott@hyperthought.com Date: Sat, 3 Jun 2017 05:54:35 -0700 (PDT) From: "Scott G. Kelly" To: "Sean Turner" Cc: "secdir@ietf.org" , "iesg@ietf.org" , draft-turner-est-extensions.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: <9C090308-86DF-4114-A7D1-E5C2CB8916DF@sn3rd.com> References: <1496407623.591322313@apps.rackspace.com> <9C090308-86DF-4114-A7D1-E5C2CB8916DF@sn3rd.com> Message-ID: <1496494475.474230398@apps.rackspace.com> X-Mailer: webmail/12.9.1-RC Archived-At: Subject: Re: [secdir] secdir review of draft-turner-est-extensions-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: Sat, 03 Jun 2017 12:54:43 -0000 Hi Sean,=0A=0AOn Saturday, June 3, 2017 1:56am, "Sean Turner" said:=0A=0A=0A>>=0A>> The document is clear and well-writte= n. Maybe this sentence=0A>>=0A>> o /firmware - Some client firmware and sof= tware support automatic=0A>> updates mechanism and some do not.=0A>>= =0A>> could use a little word-smithing for verb/noun agreement?=0A> =0A> Ho= w about:=0A> =0A> o /firmware - Some client firmware and software support a= utomatic=0A> update mechanisms and some do not.=0A=0AIt was a very mi= nor point. This is fine. =0A=0A>> The security considerations section lists= many RFCs upon which this one depends,=0A>> but I was surprised to find it= only mentions RFC7030 with respect to=0A>> server-generated asymmetric key= pairs. My impression is that this doc extends=0A>> 7030, so all of 7030's = security considerations apply here. I guess this is=0A>> implicit, but I wo= uld state it.=0A> =0A> I can make this more explicit:=0A> =0A> This documen= t relies on many other specifications; however, all of the the=0A> [RFC7030= ] security considerations apply.=0A=0A=0AYes, this addresses my point.=0A= =0AThanks,=0A=0AScott=0A=0A> =0A> spt=0A> =0A>> --Scott=0A>>=0A>>=0A>> ____= ___________________________________________=0A>> secdir mailing list=0A>> s= ecdir@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/secdir=0A>> wiki:= http://tools.ietf.org/area/sec/trac/wiki/SecDirReview=0A> =0A> =0A From nobody Sun Jun 4 18:46:44 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1F9127869; Sun, 4 Jun 2017 18:46:37 -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 PxH4llhEBcXv; Sun, 4 Jun 2017 18:46:36 -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 4044B124D6C; Sun, 4 Jun 2017 18:46:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHX02190; Mon, 05 Jun 2017 01:46:33 +0000 (GMT) Received: from SZXEMI402-HUB.china.huawei.com (10.82.75.34) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 5 Jun 2017 02:46:32 +0100 Received: from SZXEMI502-MBX.china.huawei.com ([169.254.5.112]) by SZXEMI402-HUB.china.huawei.com ([10.83.65.54]) with mapi id 14.03.0235.001; Mon, 5 Jun 2017 09:46:25 +0800 From: zhangdacheng To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-sipcore-name-addr-guidance.all@ietf.org" CC: "draft-ietf-spring-resiliency-use-cases.all@ietf.org" Thread-Topic: SECDIR review of draft-ietf-spring-resiliency-use-cases Thread-Index: AdLdnKOjtnTqkXDIRO6hg2kG+iEfdA== Date: Mon, 5 Jun 2017 01:46:24 +0000 Message-ID: <879E76B64CF340468BF5E4DE504C2242C54869@szxemi502-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.167.227] Content-Type: multipart/alternative; boundary="_000_879E76B64CF340468BF5E4DE504C2242C54869szxemi502mbxchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5934B7F9.0089, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: eb6685a680d8b1ba91aa6d0461b5520d Archived-At: Subject: [secdir] SECDIR review of draft-ietf-spring-resiliency-use-cases 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, 05 Jun 2017 01:46:38 -0000 --_000_879E76B64CF340468BF5E4DE504C2242C54869szxemi502mbxchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkhpLA0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBz ZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBk b2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiBUaGVzZSBjb21tZW50cyB3ZXJl IHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBk aXJlY3RvcnMuIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhl c2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMNCg0KICAg VGhpcyBkb2N1bWVudCBpZGVudGlmaWVzIGFuZCBkZXNjcmliZXMgdGhlIHJlcXVpcmVtZW50cyBm b3IgYSBzZXQgb2YNCiAgIHVzZSBjYXNlcyByZWxhdGVkIHRvIG5ldHdvcmsgcmVzaWxpZW5jeSBv biBTZWdtZW50IFJvdXRpbmcgKFNQUklORykNCiAgIG5ldHdvcmtzLg0KDQpUaGlzIGluZm9ybWF0 aW9uYWwgZG9jdW1lbnQgaW50cm9kdWNlcyB0aGUgY2FuZGlkYXRlIHNvbHV0aW9ucy91c2UgY2Fz ZXMgd2hpY2ggY291bGQgYmUgYXBwbGllZCB0byBlbmhhbmNlIHRoZSBuZXR3b3JrIHJlc2lsaWVu Y3kgb24gU1BSSU5HIG5ldHdvcmtzIHdoZW4gZmFpbHVyZXMgb2NjdXJzLiBJIHRoaW5rIHRoaXMg d29yayBkb2VzIG5vdCBicmluZyBhbnkgYWRkaXRpb25hbCBzZWN1cml0eSBpc3N1ZS4NCg0KVGhl IGRvY3VtZW50IGlzIFJFQURZIGZvciBwdWJsaWNhdGlvbi4NCg0KVGhhbmtzLA0KDQpEYWNoZW5n DQo= --_000_879E76B64CF340468BF5E4DE504C2242C54869szxemi502mbxchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEg NiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TOw0KCWNv bG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byP IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRN TENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8iOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBw dCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IlpILUNOIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+SGksPGJyPjxi cj5JIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBk aXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMg YmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4g cHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMu IERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVu dHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHM8YnI+PGJyPiZuYnNwOyZu YnNwOyBUaGlzIGRvY3VtZW50IGlkZW50aWZpZXMgYW5kIGRlc2NyaWJlcyB0aGUgcmVxdWlyZW1l bnRzIGZvciBhIHNldCBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB1c2UgY2FzZXMg cmVsYXRlZCB0byBuZXR3b3JrIHJlc2lsaWVuY3kgb24gU2VnbWVudCBSb3V0aW5nIChTUFJJTkcp PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBuZXR3b3Jrcy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss c2VyaWY7Y29sb3I6YmxhY2siPlRoaXMgaW5mb3JtYXRpb25hbCBkb2N1bWVudCBpbnRyb2R1Y2Vz IHRoZSBjYW5kaWRhdGUgc29sdXRpb25zL3VzZSBjYXNlcyB3aGljaCBjb3VsZCBiZSBhcHBsaWVk IHRvIGVuaGFuY2UgdGhlIG5ldHdvcmsgcmVzaWxpZW5jeSBvbiBTUFJJTkcgbmV0d29ya3Mgd2hl biBmYWlsdXJlcw0KIG9jY3Vycy4gSSB0aGluayB0aGlzIHdvcmsgZG9lcyBub3QgYnJpbmcgYW55 IGFkZGl0aW9uYWwgc2VjdXJpdHkgaXNzdWUuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5UaGUgZG9jdW1lbnQgaXMgUkVB RFkgZm9yIHB1YmxpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6 YmxhY2siPjxicj4NClRoYW5rcyw8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LHNlcmlmO2NvbG9yOmJsYWNrIj5EYWNoZW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_879E76B64CF340468BF5E4DE504C2242C54869szxemi502mbxchina_-- From nobody Sun Jun 4 22:10:19 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A23126B7F for ; Sun, 4 Jun 2017 22:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 u8YoG6pPbWQg for ; Sun, 4 Jun 2017 22:10:09 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 91E9F12702E for ; Sun, 4 Jun 2017 22:10:09 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id 9so77403079pfj.1; Sun, 04 Jun 2017 22:10:09 -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=v7KbnW12xW2rd7+ULkOYdzsmCT3Gi4Zqvv8x37A1b7k=; b=nrCCZ47AzNht6jJy40wr2KB5bZDsI7ekLSML4SMKpPfCpGYdKo8Vg1LEEgcTgOWXWx nFAvX+CMWN5YgbP8sHKMlEP8WqpctSgPUgsbchNzCsYbLiPjm+PSVJk5quOu2pfiHYOB 66dezlzT36CnxurZ2yCumoeX0cbg1LMHmHkod66Cg058LgdO80AVGB+/PLTLPAJlCntB SEFO41RppU4iI77VW1OWLvy+3GRYOKOikwqSuNmyiz+IOxZ4k69J8Aj2VSZ3O2Tg2Y/L HgR240fZUXbj52zgeWIpog5Pvl9E+T7lSTR+twSLxve30x5HiCd6h89qQe4z8G/pU3U9 x1YQ== 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=v7KbnW12xW2rd7+ULkOYdzsmCT3Gi4Zqvv8x37A1b7k=; b=fW5rfR9XRLsQvYR8aO/gcxrpFGcrIVoSuDAYNAfIbRm1ajxF4eaUY95SJj3FhFlxiE FO+EEG8iVAw2yhIDJpJ7lC30qMSavK/1VtBrv9d8OfeGinP1ZOfotBLlDMzI3DVCGUD0 +ibCfpkj2Fdh3+5kjmSnLuzx3WpgpP54drj97q25mfnR2B7HUrLDXqi2yKdyrRSwlgq9 HQD1589Z0pZHJnR2Hd+orsSTxwwvrPJE2reV2a4I5KSEVot/OoZKiKT9cA4Jhted35Nq vTuHAoGkf3WzkMHsxlkwXo2Q19HR0Q8lV9tJoOxA1YJKkOfZSeQqihQj+bG4/72BrQWV 31/A== X-Gm-Message-State: AODbwcCVBP3yrq1zbueEyOAvKbA+4GPYwlu2qluB1+8f6H6Hnktj/gUi JxT6JlvL3fkTzpjVXdcDF1Z2pVLOnAUU4hY= X-Received: by 10.98.158.138 with SMTP id f10mr7549743pfk.177.1496639408794; Sun, 04 Jun 2017 22:10:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.207.228 with HTTP; Sun, 4 Jun 2017 22:10:08 -0700 (PDT) From: Watson Ladd Date: Sun, 4 Jun 2017 22:10:08 -0700 Message-ID: To: secdir@ietf.org, draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@tools.ietf.org, iseg@ietf.org Content-Type: multipart/alternative; boundary="94eb2c04fd8a53503f05512f84ad" Archived-At: Subject: [secdir] Review of draft-ietf-v6ops-unique-ipv6-prefix-per-host 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, 05 Jun 2017 05:10:13 -0000 --94eb2c04fd8a53503f05512f84ad 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. The summary of the review is that this document is has one substantial issue plus a formatting nit: the author names are running into the title. Perhaps this can be fixed The substantial comment is that the interaction of privacy addresses with giving each subscriber a unique IPv6 address prefix space is not discussed in this document at all. This seems like a security issue that should be addressed as it reduces privacy compared to a shared prefix for all users. (Or maybe I am completely wrong: I do not know IPv6 in great detail). At minimum it should be discussed in the security considerations section, even if explicitly dismissed. Sincerely, Watson --94eb2c04fd8a53503f05512f84ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security dire= ctorate's ongoing effort to review all IETF documents being processed b= y 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 tr= eat these comments just like any other last call comments.

The summa= ry of the review is that this document is has one substantial issue plus a = formatting nit: the author names are running into the title. Perhaps this c= an be fixed

The substantial comment is that the interact= ion of privacy addresses with giving each subscriber a unique IPv6 address = prefix space is not discussed in this document at all. This seems like a se= curity issue that should be addressed as it reduces privacy compared to a s= hared prefix for all users. (Or maybe I am completely wrong: I do not know = IPv6 in great detail). At minimum it should be discussed in the security co= nsiderations section, even if explicitly dismissed.

Sincerely,
Watson
--94eb2c04fd8a53503f05512f84ad-- From nobody Mon Jun 5 09:53:14 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B8F129B56; Mon, 5 Jun 2017 09:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 3VERQhr0hHiO; Mon, 5 Jun 2017 09:53:01 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11DF7129B73; Mon, 5 Jun 2017 09:53:01 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id B09ABC002827; Mon, 5 Jun 2017 09:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=MiN1f3hgq1H8Sq JjLpPrwTBcyLs=; b=t5VKm+nC4dZA6rXkbf1j42NcUt5tA0vdmyQVjQa9MTsYlJ QGKIS8+RC9hXi1bEV4oQUKA7vQ606n9g808naaPxSnRI8JKdtZ3VFXKD9MyWb4Vm Rfi9+JL2DAkQlv1jFbGkRfFXQcYn2piPF8rp/E9+QYkx4cJStvxicubUg6qVE= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 71039C002821; Mon, 5 Jun 2017 09:52:59 -0700 (PDT) Date: Mon, 5 Jun 2017 11:52:55 -0500 From: Nico Williams To: Watson Ladd Cc: David Noveck , "secdir@ietf.org" , Phillip Hallam-Baker , Spencer Dawkins at IETF , NFSv4 Message-ID: <20170605165254.GE2903@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [secdir] [nfsv4] SECDIR Review of draft-ietf-nfsv4-umask-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 16:53:03 -0000 I find this much debate about a rather trivial extension that helps NFSv4 meet the Unix security model... a bit surprising. But onward, I shall answer your questions. As you'll see, the umask extension strictly *improves* security. On Wed, May 31, 2017 at 08:59:30PM -0700, Watson Ladd wrote: > On Wed, May 31, 2017 at 6:23 AM, David Noveck wrote: > > Phillip Hallam-Baker wrote > >> They are not so much a security plan as a collection of random thoughts > >> jotted down > >> in haphazard fashion. > > > > This is fair criticism. I've looked through the Security Considerations > > sections of RFCs 3530, 7530, and 5661 and the differences are minor. None > > of these sections were written to provide a security plan, but tried to > > describe, somewhat inelegantly, the evolution of NFS from its origins in a > > LAN environment towards NFSv4 which attempted to provide some reasonable > > security features. Any security needs were provided by RPCSECGSS, and not > > by the protocol itself. > > > >> There is clearly no coherent model of what NFS security should > >> achieve, what the threats are, what controls are deployed to > >> control them > > > > An alternative would have been to define an entirely new protocol with a > > real security plan covering these matters, but that wasn't the goal then. > > If it had been, we would probably have a much more secure protocol that > > nobody would deploy. What happened was that NFSv4 was defined requiring > > implementation, but not use, of RPCSECGSS. Even today, many NFSv4 > > deployments use AUTH_SYS and very few which use RPCSECGSS, use integrity or > > privacy, because of performance issues. Security is provided by use of > > physically isolated networks or VPNs. That was considered adequate when > > RFCs 3530, 5661, and 7530 were written and approved. > > How does this address the sorts of problems associated with the NFS > permissions model? Furthermore, this candy bar network (crunchy shell > with gooey inside) is a real liability. It would be nice if we could > make it easier to move away from. So... the idea is that: - the client establishes a "security context" that authenticates the user as some principal (using Kerberos, PKIX, SCRAM, whatever) - the server then establishes the client's UIDs/GIDs/SIDs/whatever is appropriate (if anything) on the server side -- let's call this the "authorization context" - subsequent RPCs for that user are made with that security context, thus identifying the user to the server The server then authorizes calls as follows: - validates the request (see RPCSEC_GSS) - maps the security context ID to the authorization context for that security context - evaluates whatever ACLs or mode bits are associated with any files or directories (or other objects) the user wishes to access, and grants or denies access accordingly. Now, mode bits and umask are a bit odd when used together with proper access control lists. However, there are ways to make them meaningful. For example, if I chmod 0600 a file then all access bits will be removed a) for all ACL entries (ACEs) that refer to non-owner users, b) for all groups, c) for the "everyone" entry. Increasing access, e.g., with chmod 0664, is trickier, but still, there's a way to make it meaningful. This is really important: it *is* possible to make mode bit changes meaningful with ACLs. A umask basically says "determine the ACL of new files/directories by first adding the inheritable ACEs as usual, then applying the umask to decrease or increase access as by a chmod, and do all of this atomically". The atomicity is the important part, because otherwise a client might create a file that initially starts out as having a broad (inherited!) ACL, and then decrease access via a second operation (possibly in the same RPC, but RPCs are not atomic), thus creating a race condition when trying to create files with more restrictive ACLs. Clearly, the umask very much improves security. It is rather shocking that NFSv4 didn't have it to begin with. We figured out the correct way to a) construct apparent mode bits from ACLs, and b) apply mode bits changes to ACLs, years ago after many dissatisfying attempts. I don't think that is at all codified in any RFC (but I don't follow NFSv4 that closely, so I may be wrong). Perhaps it should be, even though experimenting with various different algorithms was made possible by... not specifying it in the first place -- the state of the art here seems mature. > > If it is appropriate to move the goal posts here, based on current needs, we > > have to understand exactly what is being asked for, in order to see if > > remediation is possible while maintaining continuity with the existing NFSv4 > > protocol and implementations. Some possibilities: > > > > A clear security plan which defines the threats that NFSv4 addresses and is > > clear about those it does not address (and so have to addressed by other > > means). > > A security plan plan defining the threats that NFSv4 should address, how > > some of those are addressed by various NFSv4 minor versions, and others will > > be by extensions to NFSv4.2 or later minor versions. > > I prefer the second, but it might never happen. The first is at least > useful (when combined with what NFSv4 could address as shown by other > systems of similar kind) I will admit to not knowing how comprehensively NFSv4's various base RFCs cover the NFSv4 security model -- they are enormous RFCs. Some details are very much left to implementors, mainly how user/group IDs are represented on disk, how the "authorization context" for any one user is established, and how the implementation interfaces with other protocols such as SMB or local POSIX access. Leaving those details to implementors is purposeful. I've covered authentication and authorization (above). I can also speak about the transport security model. Spoilers: it's not that good, and the first attempt to make it significantly better via IPsec failed due to lack of implementation of RFC5660. But it's not exactly broken. NFSv4's transport security protocol is woefully inefficient for multi-user clients, but those have gone the way of the dodo. It's inefficient too in terms of ability to leave crypto to HW -- only IPsec w/ RFC5660 can help here. And even for single-user clients, it's inefficient in that RPCSEC_GSS pre-dates AEAD functionality in GSS, so it uses two GSS operations per-request (and two per-response) where one should do -- i.e., it has higher overhead than it needs to. The non-use of IPsec or TLS to protect the confidentiality (and integrity) of all of the flows between an NFSv4 client and server means that some traffic analysis can be done, identifying users identified to eavesdroppers (depending on which GSS mechanism is used). A more complete analysis of RPCSEC_GSS should really not be done in the context of this I-D. Nico -- From nobody Mon Jun 5 10:17: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 4DF07129584; Mon, 5 Jun 2017 10:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 TEBEsrOTuyTi; Mon, 5 Jun 2017 10:17:10 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66837129411; Mon, 5 Jun 2017 10:17:10 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id B409AC002828; Mon, 5 Jun 2017 10:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=rHJn8E9PHLYmkD Z2fuoCyTLwMvA=; b=hY6rXSUhFT+PBGse/lPE7rDySRnzavYwZ8OFZxi78QUbDm +KDBRQZ/LLbPi80RizuEkhfm7O+zk+TI0IpmwVgYWKl5I5QYTcH83s/Xos2fqFBF SWlLoQkvyYTe4wbKCQZtfcgc5V59RrKc9ohm2ofpgaxTp4ImYMk5OIwBdAGNM= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 6DA05C002821; Mon, 5 Jun 2017 10:17:08 -0700 (PDT) Date: Mon, 5 Jun 2017 12:17:05 -0500 From: Nico Williams To: Watson Ladd Cc: David Noveck , "secdir@ietf.org" , Phillip Hallam-Baker , Spencer Dawkins at IETF , NFSv4 Message-ID: <20170605171704.GF2903@localhost> References: <20170605165254.GE2903@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170605165254.GE2903@localhost> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [secdir] RPCSEC_GSS analysis (was Re: [nfsv4] SECDIR Review of draft-ietf-nfsv4-umask-03) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 17:17:12 -0000 > [...]. A more > complete analysis of RPCSEC_GSS should really not be done in the context > of this I-D. So here is that thread. ONC RPC is... an RPC protocol. Requests have a 32-bit (small) XID that responses repeat. The XID allows responses to be sent out of order, and resembles what HTTP/2 calls channels (or whatever). Each RPC request or response message has a header which carries said XID and other metadata, including a field for security that RPCSEC_GSS uses to a) identify a "security context" (explained earlier) and b) include a MIC of metadata. A "MIC" is a lot like a MAC, with some additional metadata. Each RPC request or response message also contains a payload. The payload is either MIC'ed (to provide only integrity protection) or "wrapped" (to also provide integrity protection. "MIC" and "wrap" are GSS [RFC2743] terminology. GSS is an API and a small amount of protocol for authenticating peers to each other. GSS has an "initiator" (the client in the NFS case) and an "acceptor" (the server in the NFS case). At first the initiator and acceptor engage in an exchange of "security context tokens" (messages) until "security context" establishment succeeds or fail. An established security context basically has session keys that can be used to make/verify MICs (again, MAC-like messages), or wrap/unwrap "wrap tokens". Wrapping can provide either integrity protection, or both integrity and confidentiality protection. MIC and wrap tokens can carry things like timestamps or sequence numbers in them that can be used to deal with out of sequence delivery and detect replays. All of the metadata in RPC headers goes in the clear unless the TCP connection is further protected by IPsec or TLS or SSHv2 or whatever. People have run NFSv4 over all of those, but there is no standard for doing so over TLS or SSHv2 -- there is no "upgrade to TLS" feature in NFSv4 (unless it's been added recently and I missed it). The binding between header and payload is done, IIRC, by including the payload MIC or wrap token in the input to the header MIC token input, but I may be misremembering. You can go check RFC2205 to double-check. Wrap tokens nowadays can do "AEAD" style "encrypt some plaintext and authenticate it and additional data", which would benefit RPCSEC_GSS. But even so, the most efficient thing we can do is implement RFC5660 and run NFSv4 with channel binding to IPsec. Nico -- From nobody Mon Jun 5 10:30:31 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55D9126D85; Mon, 5 Jun 2017 10:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 wuK-PJGcfdc7; Mon, 5 Jun 2017 10:30:23 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00387129534; Mon, 5 Jun 2017 10:30:22 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 8BF3BC002824; Mon, 5 Jun 2017 10:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=5xsq0AXkNOKFoC +B0lXR1ovoUPI=; b=P0qtvwhuB2QCDXt3uKxI0iLVAk0pCiQNbnq094CNu8sUWK aHVenIU6XStohIROoGuThyDXLZOET1Occ31ActUwd5qjvoGev5K+2einBCSMXqbl g8VkeNYwgiJlFsqwXM0+wnqn1VuMniXZ2R0nS7mGK8oGkRdy9U/dbIul4Do8I= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id CB173C002823; Mon, 5 Jun 2017 10:30:21 -0700 (PDT) Date: Mon, 5 Jun 2017 12:30:19 -0500 From: Nico Williams To: Watson Ladd Cc: Phillip Hallam-Baker , Spencer Dawkins at IETF , NFSv4 , "secdir@ietf.org" Message-ID: <20170605173018.GG2903@localhost> References: <20170605165254.GE2903@localhost> <20170605171704.GF2903@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170605171704.GF2903@localhost> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [secdir] [nfsv4] RPCSEC_GSS analysis (was Re: SECDIR Review of draft-ietf-nfsv4-umask-03) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 17:30:24 -0000 The biggest security problem with RPCSEC_GSS in general, and NFSv4 in particular, is that RPC protocols like NFSv4 are generally three-party protocols, not two-party protocols, but RPCSEC_GSS uses a two-party security protocol (GSS) and does not compose use of it to construct a three-party protocol. The parties are: the client, the users on the client, and the server. The client / user distinction is usually important and real: the client is the OS, which does not necessarily (and usually does NOT) trust the user. This leads to some interesting attacks! RPCSEC_GSSv3 adds the missing composition of GSS into a three-party model. Nico -- From nobody Mon Jun 5 10:32:44 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30561129534; Mon, 5 Jun 2017 10:32:43 -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, 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 p1GggNq2Bh04; Mon, 5 Jun 2017 10:32:41 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 E48BE126D85; Mon, 5 Jun 2017 10:32:37 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id x129so5184456ite.0; Mon, 05 Jun 2017 10:32:37 -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=ZvNW09bBbhHzx8GzgOGH82IHrfnAzNlRB5qbvaRsJ5Q=; b=QLpschupXdoALOLluoLo2GiB3ALy4LtXmL8fbu5MC/w35Ox40TVK1YSRR3Ic6IN4aY HDdODevAYi7rHwfBe3ComMhS90OCb2pmUSuVfpR+Ac099pORENzpXRntfoXdkZqcAEsL cUjceai8Jcp2fxsTq2O8TDuPb+pT61F0reFJPZi8OzqD4afB6aROPCQ8nobr7UHo0zZe 6oBsNQo2NFyy0CGCb2bqGw7PsWVrBkSYzOCvTkNi59XbHesNf9mRfpFa+vCBUKXUaK7j HWdLWwao6OagBSQBQYSm/Dn0gChaQSrnfZw7W0AjGrv/bh3Ah9NNTFu75Qa+E6L3ovLi UHAA== 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=ZvNW09bBbhHzx8GzgOGH82IHrfnAzNlRB5qbvaRsJ5Q=; b=Ep27zTOc/Z3o3d4V2RGe57XcOIQjycQoj/uGU4whRr4nLb9KcgAlamDNKKVO/Yde/1 pRq/ualNEZ5WgsrOxhfRIk1zVA8CUz3wb2xeW8sVRdxPqr6khrz2l/PoKEM0yI3e0YDq C8rvjxjhbeqkUkmrV4nO+QUt8BSXG61q27R/Wp3iZmLEoRGiUQYUX2twDCNBqwTJ3Ch6 cP8tjwNyi5iaGqambLGDe4Vv31s7IE1PQKpxaHASmPMDhDpA7KsoOPg9kjt1vX1Jn+B9 W+c57ERflParB33kM1y1K7G7agIWcu8aOEQK6UX/p/VoiQXv8wPedRpwLe4L2svfVB/G OQ2Q== X-Gm-Message-State: AODbwcBysyf7Iiha/2hO0QndV9dZmOLpv0gp//9rv6HzZn3CVpJ114sP tj2v39ueAAEBpIM30ODXSjFNXyJ21TVv X-Received: by 10.107.23.66 with SMTP id 63mr20460463iox.184.1496683956974; Mon, 05 Jun 2017 10:32:36 -0700 (PDT) MIME-Version: 1.0 From: Adam Montville Date: Mon, 05 Jun 2017 17:32:26 +0000 Message-ID: To: draft-ietf-bmwg-dcbench-terminology.all@ietf.org, "secdir@ietf.org" , The IESG Content-Type: multipart/alternative; boundary="94eb2c05c23e98d831055139e324" Archived-At: Subject: [secdir] SECDIR Review of: draft-ietf-bmwg-dcbench-terminology 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, 05 Jun 2017 17:32:43 -0000 --94eb2c05c23e98d831055139e324 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. Bottom Line: Almost Ready About Security Considerations For your security considerations phrases like "are limited to" and "will be", and I would suggest that these are your MUSTs or SHOULDs. Given the "MUST NOT" you have in the second paragraph, it seems that "MUST" should be used instead of "SHOULD". In that sense, then, I would suggest the following statements be updated: 1) "Benchmarking activities as described in this memo MUST be limited to technology characterization using controlled stimuli...", "The benchmarking network topology MUST be an independent test setup..." That said, you might consider softening the "MUST NOT" and consequent "MUST" statements to "SHOULD NOT" and "SHOULD", respectively. This because there may well be circumstances where testing in a production environment is necessary. About Rest of Draft The draft describes well-understood concepts of FILO, FIFO, LILO, and LIFO. It then goes on to recast these definitions as "first bit last bit" (or "FL"), and "last bit last bit" (or "LL"), and so on. However, the draft does not really make use of these alternate expressions for the aforementioned well-understood concepts. I recommend picking one of these representations and using it consistently throughout; moreover, I recommend sticking with FILO, FIFO, LILO, and LIFO. There's a sentence in 2.2 which reads, "Data Center DUTs are frequently store-and-forward for smaller packet sizes and then adopting a cut-through behavior." This feels incomplete. When does it adopt cut-through behavior? Is that adopted for larger packet sizes? Is it worthwhile to talk at all about the change threshold? Section 1.2 describes the generally expected definition format. However, section 2 seems to immediately depart from that to some degree by placing terms as top-level sections (i.e. "2. Latency") with children for definition, discussion, and measurement units. To compound this confusion, section 6 further departs from the expectation set in 1.2 by using the top-level section as a grouping construct for "Buffering" (without defining "Buffering"). Buffering has two children which are "buffer" and "incast". Buffer, itself is never defined, but instead has a "definition" subsection consisting of many other terms. The same sort of thing happens with "6.2 Incast". Please pick a format and make clear what things are terms, and which are not terms. Then rewrite section 1.2, so that it more properly describes what the reader should expect. There are, at several locations, uses of the capitalized word "CAN" in a way that suggests normative-type intent. "CAN" does not seem to be an RFC2119 keyword. In one case, it seems that "CAN" may actually mean a lower case "may" or "can" (see 6.1.1 on page 12). Nits Throughout the draft sometimes terms are capitalized, sometimes they are not. I believe they should more often not be capitalized, but if they are, do so consistently. Generally speaking (this may be stylistic) the first word after a colon (':') should be capitalized. Example: This is. Find acronyms/initializations and ensure they're expanded at least on the first occurrence (i.e. "PDV" on page 6) In the abstract s/as it is to/as to/ In 2.1 s/in unit of/in units of/ and s/store forward/store and forward/ In 2.3 s/follow:/follows:/ In 2.3, item 2: Is "proceed data" a common term? In 4.1 s/test on/tests on/ In 4.3 s/of :/of:/ In 4.3 s/[4.1s]/section 4.1/ In 5.3, if "CAN" is changed to "can", then s/line rate can measured/line rate can be measured/ In 6.1.1 s/expressed in Byte;/B (bytes),/ or s/expressed in Byte;/Bytes,/ In 6.1.1 s/amount of buffer a single/amount of buffer for a single/ In 6.1.1 recommend striking "it is a burst" In 6.2.1 s/by synchronous/by synchronous arrival time/ In 6.2.2 s/In a ingress/In an ingress/ In 6.2.2 s/In either cases/In either case/ In 6.2.3 s/non null/non-null/ In 7.3 the first paragraph could be improved by simply writing, "When S represents the payload bytes, which does not include packet or TCP headers, and Ft is the Finishing Time of the last sender, the Goodput, G, is then measured by the following formula..." Kind regards, Adam --94eb2c05c23e98d831055139e324 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security= directorate's ongoing effort to review all IETF documents being proces= sed by the IESG. These comments were written primarily for the benefit of t= he security area directors. Document editors and WG chairs should treat the= se comments just like any other last call comments.

Bottom Line: Almost Ready

About Security Conside= rations
For your security considerations phrases like "are l= imited to" and "will be", and I would suggest that these are= your MUSTs or SHOULDs. Given the "MUST NOT" you have in the seco= nd paragraph, it seems that "MUST" should be used instead of &quo= t;SHOULD". In that sense, then, I would suggest the following statemen= ts be updated: 1) "Benchmarking activities as described in this memo M= UST be limited to technology characterization using controlled stimuli...&q= uot;, "The benchmarking network topology MUST be an independent test s= etup..."

That said, you might consider soften= ing the "MUST NOT" and consequent "MUST" statements to = "SHOULD NOT" and "SHOULD", respectively. This because t= here may well be circumstances where testing in a production environment is= necessary.


About Rest of Draft
The draft describes well-understood concepts of FILO, FIFO, LILO, an= d LIFO. It then goes on to recast these definitions as "first bit last= bit" (or "FL"), and "last bit last bit" (or "= ;LL"), and so on. However, the draft does not really make use of these= alternate expressions for the aforementioned well-understood concepts. I r= ecommend picking one of these representations and using it consistently thr= oughout; moreover, I recommend sticking with FILO, FIFO, LILO, and LIFO.

There's a sentence in 2.2 which reads, "Dat= a Center DUTs are frequently store-and-forward for smaller packet sizes and= then adopting a cut-through behavior." This feels incomplete. When do= es it adopt cut-through behavior? Is that adopted for larger packet sizes? = Is it worthwhile to talk at all about the change threshold?

<= /div>
Section 1.2 describes the generally expected definition format. H= owever, section 2 seems to immediately depart from that to some degree by p= lacing terms as top-level sections (i.e. "2. Latency") with child= ren for definition, discussion, and measurement units. To compound this con= fusion, section 6 further departs from the expectation set in 1.2 by using = the top-level section as a grouping construct for "Buffering" (wi= thout defining "Buffering"). Buffering has two children which are= "buffer" and "incast". Buffer, itself is never defined= , but instead has a "definition" subsection =C2=A0consisting of m= any other terms. The same sort of thing happens with "6.2 Incast"= . Please pick a format and make clear what things are terms, and which are = not terms. Then rewrite section 1.2, so that it more properly describes wha= t the reader should expect.

There are, at several = locations, uses of the capitalized word "CAN" in a way that sugge= sts normative-type intent. "CAN" does not seem to be an RFC2119 k= eyword. In one case, it seems that "CAN" may actually mean a lowe= r case "may" or "can" (see 6.1.1 on page 12).


Nits
Throughout the draft sometime= s terms are capitalized, sometimes they are not. I believe they should more= often not be capitalized, but if they are, do so consistently.
<= br>
Generally speaking (this may be stylistic) the first word aft= er a colon (':') should be capitalized. Example: This is.

Find acronyms/initializations and ensure they're expand= ed at least on the first occurrence (i.e. "PDV" on page 6)
<= div>
In the abstract s/as it is to/as to/

In 2.1 s/in unit of/in units of/ and s/store forward/store and forwar= d/

In 2.3 s/follow:/follows:/

=
In 2.3, item 2: Is "proceed data" a common term?
<= br>
In 4.1 s/test on/tests on/

In 4.3 s/= of :/of:/

In 4.3 s/[4.1s]/section 4.1/
<= br>
In 5.3, if "CAN" is changed to "can", the= n s/line rate can measured/line rate can be measured/

<= div>In 6.1.1 s/expressed in Byte;/B (bytes),/ or s/expressed in Byte;/Bytes= ,/

In 6.1.1 s/amount of buffer a single/amount of = buffer for a single/

In 6.1.1 recommend striking &= quot;it is a burst"

In 6.2.1 s/by synchronous= /by synchronous arrival time/

In 6.2.2 s/In a ingr= ess/In an ingress/

In 6.2.2 s/In either cases/In e= ither case/

In 6.2.3 s/non null/non-null/

In 7.3 the first paragraph could be improved by simply wri= ting, "When S represents the payload bytes, which does not include pac= ket or TCP headers, and Ft is the Finishing Time of the last sender, the Go= odput, G, is then measured by the following formula..."

=

Kind regards,

Adam
=


--94eb2c05c23e98d831055139e324-- From nobody Tue Jun 6 08:21:19 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167801294B3; Tue, 6 Jun 2017 08:21:18 -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, 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 4F6yVWE6KCDT; Tue, 6 Jun 2017 08:21:14 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 A4D72129477; Tue, 6 Jun 2017 08:21:14 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id m62so95218996itc.0; Tue, 06 Jun 2017 08:21: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=CDJivLJN6QWBd8gJbntG75WvobgMMXOc0OsdReX51vE=; b=RyvwdqWuxxwreMHz6pxFTLM/wckyY4JJeVSk9bkpr4vE/P3u4zjGIFo3zFUTDzQx0v PpBuyI8iSxwBLlKLzJ3sg1H3DM7g+BpozW5Jt0qblBfxQDZAG6Fcelhu/L9Xo+eYtVG5 qLBbHe0ts0BKW5002GRMvM/oPd9XzcJcCsNXKNWDOx4QeXUP2uVPbPniCHrJFzFi8N5D 27vt13zjtTwu9fPvVDrR98JXl/m/fGGkO8OG9jITsLGanTtExiQ1Qkz51i3dIhsDH+5n zG1iYVQLXbWdWq8oCT0ftWPT1RFrbjUyUrJWHPwQVSjLRQzSu3n5He69dDIF+6ggSqhn ztug== 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=CDJivLJN6QWBd8gJbntG75WvobgMMXOc0OsdReX51vE=; b=SEmvfgvtzJUDQgLyAuGIyfeGNAw3hr6n1rRbLaXoz5b7CN9M0fJ+xJ+mAMr+x7oDTi wYzv0Jj0qDP6kbgnD1XUsy9giRuwoxX2PI1F9nf2z7m+sidopJ82aiu7GAT8GPKup2r4 soBXxE9+nK3ISlz47VMA9CGv/Vg1tNY5bLy4HItnBKt7qb1H6vZrtrg8wZcoJ1QaIImV lSOBaB6jLPm8ZXJ4Sf7AowzDHz2GdggyDGWFSTU7OIRMQVJK+XVAgB5ZhkiyQ84i4+YW mPi8wcwP6JHtKJqK03qLBr6PQTUkEN7+9SvnMPe9TFJW8yPf9F35fivK7h6ry/EYqBVP pLfg== X-Gm-Message-State: AODbwcDseFfuBoEZvQcH3LS4p5qLZfufw4mqipgXkAzEV7I3+yP8MIQl Bc/fdimboCYOiHwtTr+qUJ3aRtsqoA== X-Received: by 10.107.6.69 with SMTP id 66mr25207595iog.163.1496762473949; Tue, 06 Jun 2017 08:21:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.20.75 with HTTP; Tue, 6 Jun 2017 08:21:13 -0700 (PDT) In-Reply-To: <20170605165254.GE2903@localhost> References: <20170605165254.GE2903@localhost> From: David Noveck Date: Tue, 6 Jun 2017 11:21:13 -0400 Message-ID: To: Nico Williams Cc: Watson Ladd , "secdir@ietf.org" , Phillip Hallam-Baker , Spencer Dawkins at IETF , NFSv4 Content-Type: multipart/alternative; boundary="001a113edff892b23c05514c2b68" Archived-At: Subject: Re: [secdir] [nfsv4] SECDIR Review of draft-ietf-nfsv4-umask-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 15:21:18 -0000 --001a113edff892b23c05514c2b68 Content-Type: text/plain; charset="UTF-8" > A more complete analysis of RPCSEC_GSS should really not be > done in the context of this I-D. I agree that it should not, but it is not clear exactly what is being asked for to get this document into the RFC editing process. Unlike xattrs, this document actually has been approved. The state is listed as "Approved-announcement to be sent::Point Raised - writeup needed" so we know it has been approved but are unclear about why this has not been announced, what exactly the point raised might be and how the issue/point is to be resolved. I think the authors are entitled to a clearer treatment of these matters. On Mon, Jun 5, 2017 at 12:52 PM, Nico Williams wrote: > > I find this much debate about a rather trivial extension that helps > NFSv4 meet the Unix security model... a bit surprising. But onward, I > shall answer your questions. > > As you'll see, the umask extension strictly *improves* security. > > On Wed, May 31, 2017 at 08:59:30PM -0700, Watson Ladd wrote: > > On Wed, May 31, 2017 at 6:23 AM, David Noveck > wrote: > > > Phillip Hallam-Baker wrote > > >> They are not so much a security plan as a collection of random > thoughts > > >> jotted down > > >> in haphazard fashion. > > > > > > This is fair criticism. I've looked through the Security > Considerations > > > sections of RFCs 3530, 7530, and 5661 and the differences are minor. > None > > > of these sections were written to provide a security plan, but tried to > > > describe, somewhat inelegantly, the evolution of NFS from its origins > in a > > > LAN environment towards NFSv4 which attempted to provide some > reasonable > > > security features. Any security needs were provided by RPCSECGSS, and > not > > > by the protocol itself. > > > > > >> There is clearly no coherent model of what NFS security should > > >> achieve, what the threats are, what controls are deployed to > > >> control them > > > > > > An alternative would have been to define an entirely new protocol with > a > > > real security plan covering these matters, but that wasn't the goal > then. > > > If it had been, we would probably have a much more secure protocol that > > > nobody would deploy. What happened was that NFSv4 was defined > requiring > > > implementation, but not use, of RPCSECGSS. Even today, many NFSv4 > > > deployments use AUTH_SYS and very few which use RPCSECGSS, use > integrity or > > > privacy, because of performance issues. Security is provided by use of > > > physically isolated networks or VPNs. That was considered adequate > when > > > RFCs 3530, 5661, and 7530 were written and approved. > > > > How does this address the sorts of problems associated with the NFS > > permissions model? Furthermore, this candy bar network (crunchy shell > > with gooey inside) is a real liability. It would be nice if we could > > make it easier to move away from. > > So... the idea is that: > > - the client establishes a "security context" that authenticates the > user as some principal (using Kerberos, PKIX, SCRAM, whatever) > > - the server then establishes the client's UIDs/GIDs/SIDs/whatever is > appropriate (if anything) on the server side -- let's call this the > "authorization context" > > - subsequent RPCs for that user are made with that security context, > thus identifying the user to the server > > The server then authorizes calls as follows: > > - validates the request (see RPCSEC_GSS) > > - maps the security context ID to the authorization context for that > security context > > - evaluates whatever ACLs or mode bits are associated with any files or > directories (or other objects) the user wishes to access, and grants > or denies access accordingly. > > Now, mode bits and umask are a bit odd when used together with proper > access control lists. However, there are ways to make them meaningful. > > For example, if I chmod 0600 a file then all access bits will be removed > a) for all ACL entries (ACEs) that refer to non-owner users, b) for all > groups, c) for the "everyone" entry. Increasing access, e.g., with > chmod 0664, is trickier, but still, there's a way to make it meaningful. > > This is really important: it *is* possible to make mode bit changes > meaningful with ACLs. > > A umask basically says "determine the ACL of new files/directories by > first adding the inheritable ACEs as usual, then applying the umask to > decrease or increase access as by a chmod, and do all of this > atomically". > > The atomicity is the important part, because otherwise a client might > create a file that initially starts out as having a broad (inherited!) > ACL, and then decrease access via a second operation (possibly in the > same RPC, but RPCs are not atomic), thus creating a race condition when > trying to create files with more restrictive ACLs. > > Clearly, the umask very much improves security. It is rather shocking > that NFSv4 didn't have it to begin with. > > We figured out the correct way to a) construct apparent mode bits from > ACLs, and b) apply mode bits changes to ACLs, years ago after many > dissatisfying attempts. I don't think that is at all codified in any > RFC (but I don't follow NFSv4 that closely, so I may be wrong). Perhaps > it should be, even though experimenting with various different > algorithms was made possible by... not specifying it in the first place > -- the state of the art here seems mature. > > > > If it is appropriate to move the goal posts here, based on current > needs, we > > > have to understand exactly what is being asked for, in order to see if > > > remediation is possible while maintaining continuity with the existing > NFSv4 > > > protocol and implementations. Some possibilities: > > > > > > A clear security plan which defines the threats that NFSv4 addresses > and is > > > clear about those it does not address (and so have to addressed by > other > > > means). > > > A security plan plan defining the threats that NFSv4 should address, > how > > > some of those are addressed by various NFSv4 minor versions, and > others will > > > be by extensions to NFSv4.2 or later minor versions. > > > > I prefer the second, but it might never happen. The first is at least > > useful (when combined with what NFSv4 could address as shown by other > > systems of similar kind) > > I will admit to not knowing how comprehensively NFSv4's various base > RFCs cover the NFSv4 security model -- they are enormous RFCs. Some > details are very much left to implementors, mainly how user/group IDs > are represented on disk, how the "authorization context" for any one > user is established, and how the implementation interfaces with other > protocols such as SMB or local POSIX access. Leaving those details to > implementors is purposeful. > > I've covered authentication and authorization (above). > > I can also speak about the transport security model. Spoilers: it's not > that good, and the first attempt to make it significantly better via > IPsec failed due to lack of implementation of RFC5660. But it's not > exactly broken. > > NFSv4's transport security protocol is woefully inefficient for > multi-user clients, but those have gone the way of the dodo. It's > inefficient too in terms of ability to leave crypto to HW -- only IPsec > w/ RFC5660 can help here. And even for single-user clients, it's > inefficient in that RPCSEC_GSS pre-dates AEAD functionality in GSS, so > it uses two GSS operations per-request (and two per-response) where one > should do -- i.e., it has higher overhead than it needs to. > > The non-use of IPsec or TLS to protect the confidentiality (and > integrity) of all of the flows between an NFSv4 client and server means > that some traffic analysis can be done, identifying users identified to > eavesdroppers (depending on which GSS mechanism is used). A more > complete analysis of RPCSEC_GSS should really not be done in the context > of this I-D. > > Nico > -- > --001a113edff892b23c05514c2b68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> A more=C2=A0<= span style=3D"font-size:12.8px">complete analysis of RPCSEC_GSS should real= ly not be=C2=A0
> done in th= e context=C2=A0of this I-D.<= br>

I agree that it should not, but it is not clear = exactly what is being asked for to=C2=A0
get this document into the RFC editing process.=C2=A0 Unlik= e xattrs, this document=C2=A0
actually has been approved.=C2=A0 The state is listed as "= Approved-announcement to=
be sent::Point Raised - writeup needed" so we know i= t has been approved but
are unclear about why this has not been announced, what exactly t= he point raised=C2=A0
might be and how the issue/point is to be resolved.

I think the authors are entitled to a = clearer treatment of these matters. =C2=A0=C2=A0

On Mon, Jun 5, 2017 at 12= :52 PM, Nico Williams <nico@cryptonector.com> wrote:
=

I find this much debate about a rather trivial extension that helps
NFSv4 meet the Unix security model... a bit surprising.=C2=A0 But onward, I=
shall answer your questions.

As you'll see, the umask extension strictly *improves* security.

On Wed, May 31, 2017 at 08:59:30PM -0700, Watson Ladd wrote:
> On Wed, May 31, 2017 at 6:23 AM, David Noveck <davenoveck@gmail.com> wrote:
> > Phillip Hallam-Baker wrote
> >> They are not so much a security plan as a collection of rando= m thoughts
> >> jotted down
> >> in haphazard fashion.
> >
> > This is fair criticism.=C2=A0 I've looked through the Securit= y Considerations
> > sections of RFCs 3530, 7530, and 5661 and the differences are min= or.=C2=A0 =C2=A0None
> > of these sections were written to provide a security plan, but tr= ied to
> > describe, somewhat inelegantly, the evolution of NFS from its ori= gins in a
> > LAN environment towards NFSv4 which attempted to provide some rea= sonable
> > security features.=C2=A0 Any security needs were provided by RPCS= ECGSS, and not
> > by the protocol itself.
> >
> >> There is clearly no coherent model of what NFS security shoul= d
> >> achieve, what the threats are, what controls are deployed to<= br> > >> control them
> >
> > An alternative would have been to define an entirely new protocol= with a
> > real security plan covering these matters, but that wasn't th= e goal then.
> > If it had been, we would probably have a much more secure protoco= l that
> > nobody would deploy.=C2=A0 What happened was that NFSv4 was defin= ed requiring
> > implementation, but not use, of RPCSECGSS.=C2=A0 Even today, many= NFSv4
> > deployments use AUTH_SYS and very few which use RPCSECGSS, use in= tegrity or
> > privacy, because of performance issues.=C2=A0 Security is provide= d by use of
> > physically isolated networks or VPNs.=C2=A0 =C2=A0That was consid= ered adequate when
> > RFCs 3530, 5661, and 7530 were written and approved.
>
> How does this address the sorts of problems associated with the NFS > permissions model? Furthermore, this candy bar network (crunchy shell<= br> > with gooey inside) is a real liability. It would be nice if we could > make it easier to move away from.

So... the idea is that:

=C2=A0- the client establishes a "security context" that authenti= cates the
=C2=A0 =C2=A0user as some principal (using Kerberos, PKIX, SCRAM, whatever)=

=C2=A0- the server then establishes the client's UIDs/GIDs/SIDs/whateve= r is
=C2=A0 =C2=A0appropriate (if anything) on the server side -- let's call= this the
=C2=A0 =C2=A0"authorization context"

=C2=A0- subsequent RPCs for that user are made with that security context,<= br> =C2=A0 =C2=A0thus identifying the user to the server

The server then authorizes calls as follows:

=C2=A0- validates the request (see RPCSEC_GSS)

=C2=A0- maps the security context ID to the authorization context for that<= br> =C2=A0 =C2=A0security context

=C2=A0- evaluates whatever ACLs or mode bits are associated with any files = or
=C2=A0 =C2=A0directories (or other objects) the user wishes to access, and = grants
=C2=A0 =C2=A0or denies access accordingly.

Now, mode bits and umask are a bit odd when used together with proper
access control lists.=C2=A0 However, there are ways to make them meaningful= .

For example, if I chmod 0600 a file then all access bits will be removed a) for all ACL entries (ACEs) that refer to non-owner users, b) for all
groups, c) for the "everyone" entry.=C2=A0 Increasing access, e.g= ., with
chmod 0664, is trickier, but still, there's a way to make it meaningful= .

This is really important: it *is* possible to make mode bit changes
meaningful with ACLs.

A umask basically says "determine the ACL of new files/directories by<= br> first adding the inheritable ACEs as usual, then applying the umask to
decrease or increase access as by a chmod, and do all of this
atomically".

The atomicity is the important part, because otherwise a client might
create a file that initially starts out as having a broad (inherited!)
ACL, and then decrease access via a second operation (possibly in the
same RPC, but RPCs are not atomic), thus creating a race condition when
trying to create files with more restrictive ACLs.

Clearly, the umask very much improves security.=C2=A0 It is rather shocking=
that NFSv4 didn't have it to begin with.

We figured out the correct way to a) construct apparent mode bits from
ACLs, and b) apply mode bits changes to ACLs, years ago after many
dissatisfying attempts.=C2=A0 I don't think that is at all codified in = any
RFC (but I don't follow NFSv4 that closely, so I may be wrong).=C2=A0 P= erhaps
it should be, even though experimenting with various different
algorithms was made possible by... not specifying it in the first place
-- the state of the art here seems mature.

> > If it is appropriate to move the goal posts here, based on curren= t needs, we
> > have to understand exactly what is being asked for, in order to s= ee if
> > remediation is possible while maintaining continuity with the exi= sting NFSv4
> > protocol and implementations.=C2=A0 Some possibilities:
> >
> > A clear security plan which defines the threats that NFSv4 addres= ses and is
> > clear about those it does not address (and so have to addressed b= y other
> > means).
> > A security plan plan defining the threats that NFSv4 should addre= ss, how
> > some of those are addressed by various NFSv4 minor versions, and = others will
> > be by extensions to NFSv4.2 or later minor versions.
>
> I prefer the second, but it might never happen. The first is at least<= br> > useful (when combined with what NFSv4 could address as shown by other<= br> > systems of similar kind)

I will admit to not knowing how comprehensively NFSv4's various = base
RFCs cover the NFSv4 security model -- they are enormous RFCs.=C2=A0 Some details are very much left to implementors, mainly how user/group IDs
are represented on disk, how the "authorization context" for any = one
user is established, and how the implementation interfaces with other
protocols such as SMB or local POSIX access.=C2=A0 Leaving those details to=
implementors is purposeful.

I've covered authentication and authorization (above).

I can also speak about the transport security model.=C2=A0 Spoilers: it'= ;s not
that good, and the first attempt to make it significantly better via
IPsec failed due to lack of implementation of RFC5660.=C2=A0 But it's n= ot
exactly broken.

NFSv4's transport security protocol is woefully inefficient for
multi-user clients, but those have gone the way of the dodo.=C2=A0 It's=
inefficient too in terms of ability to leave crypto to HW -- only IPsec
w/ RFC5660 can help here.=C2=A0 And even for single-user clients, it's<= br> inefficient in that RPCSEC_GSS pre-dates AEAD functionality in GSS, so
it uses two GSS operations per-request (and two per-response) where one
should do -- i.e., it has higher overhead than it needs to.

The non-use of IPsec or TLS to protect the confidentiality (and
integrity) of all of the flows between an NFSv4 client and server means
that some traffic analysis can be done, identifying users identified to
eavesdroppers (depending on which GSS mechanism is used).=C2=A0 A more
complete analysis of RPCSEC_GSS should really not be done in the context of this I-D.

Nico
--

--001a113edff892b23c05514c2b68-- From nobody Tue Jun 6 08:22:31 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B56129477; Tue, 6 Jun 2017 08:22:24 -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 o7Vd-8CkJWSh; Tue, 6 Jun 2017 08:22:21 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 5DEA0128B8E; Tue, 6 Jun 2017 08:22:21 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id r63so111983221itc.1; Tue, 06 Jun 2017 08:22:21 -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=5SYruZwAYVGH1kximGizXYsgsdmY/Yhf1P8auMhUmsk=; b=I4b9lFoxzTZ34WbJxWSYleaPIFSnnUVU4IkWSm1dGcxFcqYCA5NqqiV+iFQJZmJCkb wb79nIkpxFkZcvNyHO8mO8Kij0yHFpJaMxbtd87MGMgQLC+WfFqdeDscwDbc8LS3Qfu0 8/2lk4U2WFIlxrpKKTRBRoJhe8t3mItqwFcCHou2yWzxaFO/ZnXmcpVjWPY3naRBi2Kb uJylpeJt7MFsADeR2hUza0qlcVpA21wkdf5K+2ChWKs+BFuVbe8N6RFnkkC2VJdAW1/v cOY7beGSkAaFKyIT5ul8GRqjfPDl03Itdr5P5/pauTQdy52V0yHgPpz4OIf68QeAWOl6 m2ew== 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=5SYruZwAYVGH1kximGizXYsgsdmY/Yhf1P8auMhUmsk=; b=rmYXymx1a3GFxRyp/2RYaJIyV0+OeaT3dNew4OpDQgpvCDJWFZQsaVOkiwfZ3QqyED 2/s3lU8NWba6HvV+nUWYvkTbSGkUlvQxg5kzeaUK05BaN+jr/ueUsFCHzUjuYpkIcxgq mxEJjxSDFVCwa67JM1X41LPa0jUgo+xfQKsADXrKw0gediAM0t+g2nHDdcvxBl4A33V2 1Bvc7dpvNaHhxYZjbGGW1zAxiuKqwu3BN530bKBBg0RtaDwMtHUavLibgHXx2FHt2iSd mLMXc5fIkuLdY8WPECe+pqgGngAFKFiuY7h182ashZXzF9EDAduuGjRltiXa01Peuatl TTWA== X-Gm-Message-State: AODbwcCVWXCMdOu9xUQVMdF+18Q8ZtQSdWrbyJFHE2w4IeFrdI2IcmFy 7TGw8Mipg/wyRh9xwu0elAzNaDxCFdUZ X-Received: by 10.36.246.67 with SMTP id u64mr18525459ith.3.1496762540728; Tue, 06 Jun 2017 08:22:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.20.75 with HTTP; Tue, 6 Jun 2017 08:22:20 -0700 (PDT) In-Reply-To: <20170605165254.GE2903@localhost> References: <20170605165254.GE2903@localhost> From: David Noveck Date: Tue, 6 Jun 2017 11:22:20 -0400 Message-ID: To: Nico Williams Cc: Watson Ladd , "secdir@ietf.org" , Phillip Hallam-Baker , Spencer Dawkins at IETF , NFSv4 Content-Type: multipart/alternative; boundary="94eb2c12c4308dab6305514c2f58" Archived-At: Subject: Re: [secdir] [nfsv4] SECDIR Review of draft-ietf-nfsv4-umask-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 15:22:24 -0000 --94eb2c12c4308dab6305514c2f58 Content-Type: text/plain; charset="UTF-8" > A more complete analysis of RPCSEC_GSS should really not be > done in the context of this I-D. I agree that it should not, but it is not clear exactly what is being asked for to get this document into the RFC editing process. Unlike xattrs, this document actually has been approved. The state is listed as "Approved-announcement to be sent::Point Raised - writeup needed" so we know it has been approved but are unclear about why this has not been announced, what exactly the point raised might be and how the issue/point is to be resolved. I think the authors are entitled to a clearer treatment of these matters. On Mon, Jun 5, 2017 at 12:52 PM, Nico Williams wrote: > > I find this much debate about a rather trivial extension that helps > NFSv4 meet the Unix security model... a bit surprising. But onward, I > shall answer your questions. > > As you'll see, the umask extension strictly *improves* security. > > On Wed, May 31, 2017 at 08:59:30PM -0700, Watson Ladd wrote: > > On Wed, May 31, 2017 at 6:23 AM, David Noveck > wrote: > > > Phillip Hallam-Baker wrote > > >> They are not so much a security plan as a collection of random > thoughts > > >> jotted down > > >> in haphazard fashion. > > > > > > This is fair criticism. I've looked through the Security > Considerations > > > sections of RFCs 3530, 7530, and 5661 and the differences are minor. > None > > > of these sections were written to provide a security plan, but tried to > > > describe, somewhat inelegantly, the evolution of NFS from its origins > in a > > > LAN environment towards NFSv4 which attempted to provide some > reasonable > > > security features. Any security needs were provided by RPCSECGSS, and > not > > > by the protocol itself. > > > > > >> There is clearly no coherent model of what NFS security should > > >> achieve, what the threats are, what controls are deployed to > > >> control them > > > > > > An alternative would have been to define an entirely new protocol with > a > > > real security plan covering these matters, but that wasn't the goal > then. > > > If it had been, we would probably have a much more secure protocol that > > > nobody would deploy. What happened was that NFSv4 was defined > requiring > > > implementation, but not use, of RPCSECGSS. Even today, many NFSv4 > > > deployments use AUTH_SYS and very few which use RPCSECGSS, use > integrity or > > > privacy, because of performance issues. Security is provided by use of > > > physically isolated networks or VPNs. That was considered adequate > when > > > RFCs 3530, 5661, and 7530 were written and approved. > > > > How does this address the sorts of problems associated with the NFS > > permissions model? Furthermore, this candy bar network (crunchy shell > > with gooey inside) is a real liability. It would be nice if we could > > make it easier to move away from. > > So... the idea is that: > > - the client establishes a "security context" that authenticates the > user as some principal (using Kerberos, PKIX, SCRAM, whatever) > > - the server then establishes the client's UIDs/GIDs/SIDs/whatever is > appropriate (if anything) on the server side -- let's call this the > "authorization context" > > - subsequent RPCs for that user are made with that security context, > thus identifying the user to the server > > The server then authorizes calls as follows: > > - validates the request (see RPCSEC_GSS) > > - maps the security context ID to the authorization context for that > security context > > - evaluates whatever ACLs or mode bits are associated with any files or > directories (or other objects) the user wishes to access, and grants > or denies access accordingly. > > Now, mode bits and umask are a bit odd when used together with proper > access control lists. However, there are ways to make them meaningful. > > For example, if I chmod 0600 a file then all access bits will be removed > a) for all ACL entries (ACEs) that refer to non-owner users, b) for all > groups, c) for the "everyone" entry. Increasing access, e.g., with > chmod 0664, is trickier, but still, there's a way to make it meaningful. > > This is really important: it *is* possible to make mode bit changes > meaningful with ACLs. > > A umask basically says "determine the ACL of new files/directories by > first adding the inheritable ACEs as usual, then applying the umask to > decrease or increase access as by a chmod, and do all of this > atomically". > > The atomicity is the important part, because otherwise a client might > create a file that initially starts out as having a broad (inherited!) > ACL, and then decrease access via a second operation (possibly in the > same RPC, but RPCs are not atomic), thus creating a race condition when > trying to create files with more restrictive ACLs. > > Clearly, the umask very much improves security. It is rather shocking > that NFSv4 didn't have it to begin with. > > We figured out the correct way to a) construct apparent mode bits from > ACLs, and b) apply mode bits changes to ACLs, years ago after many > dissatisfying attempts. I don't think that is at all codified in any > RFC (but I don't follow NFSv4 that closely, so I may be wrong). Perhaps > it should be, even though experimenting with various different > algorithms was made possible by... not specifying it in the first place > -- the state of the art here seems mature. > > > > If it is appropriate to move the goal posts here, based on current > needs, we > > > have to understand exactly what is being asked for, in order to see if > > > remediation is possible while maintaining continuity with the existing > NFSv4 > > > protocol and implementations. Some possibilities: > > > > > > A clear security plan which defines the threats that NFSv4 addresses > and is > > > clear about those it does not address (and so have to addressed by > other > > > means). > > > A security plan plan defining the threats that NFSv4 should address, > how > > > some of those are addressed by various NFSv4 minor versions, and > others will > > > be by extensions to NFSv4.2 or later minor versions. > > > > I prefer the second, but it might never happen. The first is at least > > useful (when combined with what NFSv4 could address as shown by other > > systems of similar kind) > > I will admit to not knowing how comprehensively NFSv4's various base > RFCs cover the NFSv4 security model -- they are enormous RFCs. Some > details are very much left to implementors, mainly how user/group IDs > are represented on disk, how the "authorization context" for any one > user is established, and how the implementation interfaces with other > protocols such as SMB or local POSIX access. Leaving those details to > implementors is purposeful. > > I've covered authentication and authorization (above). > > I can also speak about the transport security model. Spoilers: it's not > that good, and the first attempt to make it significantly better via > IPsec failed due to lack of implementation of RFC5660. But it's not > exactly broken. > > NFSv4's transport security protocol is woefully inefficient for > multi-user clients, but those have gone the way of the dodo. It's > inefficient too in terms of ability to leave crypto to HW -- only IPsec > w/ RFC5660 can help here. And even for single-user clients, it's > inefficient in that RPCSEC_GSS pre-dates AEAD functionality in GSS, so > it uses two GSS operations per-request (and two per-response) where one > should do -- i.e., it has higher overhead than it needs to. > > The non-use of IPsec or TLS to protect the confidentiality (and > integrity) of all of the flows between an NFSv4 client and server means > that some traffic analysis can be done, identifying users identified to > eavesdroppers (depending on which GSS mechanism is used). A more > complete analysis of RPCSEC_GSS should really not be done in the context > of this I-D. > > Nico > -- > --94eb2c12c4308dab6305514c2f58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> A more=C2=A0<= span style=3D"font-size:12.8px">complete analysis of RPCSEC_GSS should real= ly not be=C2=A0
> done in th= e context=C2=A0of this I-D.<= br>

I agree that it should not, but it is not clear = exactly what is being asked for to=C2=A0
get this document into the RFC editing process.=C2=A0 Unlik= e xattrs, this document=C2=A0
actually has been approved.=C2=A0 The state is listed as "= Approved-announcement to=
be sent::Point Raise= d - writeup needed" so we know it has been approved but
are unclear about why this h= as not been announced, what exactly the point raised=C2=A0
might be and how the issue/poi= nt is to be resolved.

I= think the authors are entitled to a clearer treatment of these matters. = =C2=A0=C2=A0

On Mon, Jun 5, 2017 at 12:52 PM, Nico Williams <nico@cry= ptonector.com> wrote:

I find this much debate about a rather trivial extension that helps
NFSv4 meet the Unix security model... a bit surprising.=C2=A0 But onward, I=
shall answer your questions.

As you'll see, the umask extension strictly *improves* security.

On Wed, May 31, 2017 at 08:59:30PM -0700, Watson Ladd wrote:
> On Wed, May 31, 2017 at 6:23 AM, David Noveck <davenoveck@gmail.com> wrote:
> > Phillip Hallam-Baker wrote
> >> They are not so much a security plan as a collection of rando= m thoughts
> >> jotted down
> >> in haphazard fashion.
> >
> > This is fair criticism.=C2=A0 I've looked through the Securit= y Considerations
> > sections of RFCs 3530, 7530, and 5661 and the differences are min= or.=C2=A0 =C2=A0None
> > of these sections were written to provide a security plan, but tr= ied to
> > describe, somewhat inelegantly, the evolution of NFS from its ori= gins in a
> > LAN environment towards NFSv4 which attempted to provide some rea= sonable
> > security features.=C2=A0 Any security needs were provided by RPCS= ECGSS, and not
> > by the protocol itself.
> >
> >> There is clearly no coherent model of what NFS security shoul= d
> >> achieve, what the threats are, what controls are deployed to<= br> > >> control them
> >
> > An alternative would have been to define an entirely new protocol= with a
> > real security plan covering these matters, but that wasn't th= e goal then.
> > If it had been, we would probably have a much more secure protoco= l that
> > nobody would deploy.=C2=A0 What happened was that NFSv4 was defin= ed requiring
> > implementation, but not use, of RPCSECGSS.=C2=A0 Even today, many= NFSv4
> > deployments use AUTH_SYS and very few which use RPCSECGSS, use in= tegrity or
> > privacy, because of performance issues.=C2=A0 Security is provide= d by use of
> > physically isolated networks or VPNs.=C2=A0 =C2=A0That was consid= ered adequate when
> > RFCs 3530, 5661, and 7530 were written and approved.
>
> How does this address the sorts of problems associated with the NFS > permissions model? Furthermore, this candy bar network (crunchy shell<= br> > with gooey inside) is a real liability. It would be nice if we could > make it easier to move away from.

So... the idea is that:

=C2=A0- the client establishes a "security context" that authenti= cates the
=C2=A0 =C2=A0user as some principal (using Kerberos, PKIX, SCRAM, whatever)=

=C2=A0- the server then establishes the client's UIDs/GIDs/SIDs/whateve= r is
=C2=A0 =C2=A0appropriate (if anything) on the server side -- let's call= this the
=C2=A0 =C2=A0"authorization context"

=C2=A0- subsequent RPCs for that user are made with that security context,<= br> =C2=A0 =C2=A0thus identifying the user to the server

The server then authorizes calls as follows:

=C2=A0- validates the request (see RPCSEC_GSS)

=C2=A0- maps the security context ID to the authorization context for that<= br> =C2=A0 =C2=A0security context

=C2=A0- evaluates whatever ACLs or mode bits are associated with any files = or
=C2=A0 =C2=A0directories (or other objects) the user wishes to access, and = grants
=C2=A0 =C2=A0or denies access accordingly.

Now, mode bits and umask are a bit odd when used together with proper
access control lists.=C2=A0 However, there are ways to make them meaningful= .

For example, if I chmod 0600 a file then all access bits will be removed a) for all ACL entries (ACEs) that refer to non-owner users, b) for all
groups, c) for the "everyone" entry.=C2=A0 Increasing access, e.g= ., with
chmod 0664, is trickier, but still, there's a way to make it meaningful= .

This is really important: it *is* possible to make mode bit changes
meaningful with ACLs.

A umask basically says "determine the ACL of new files/directories by<= br> first adding the inheritable ACEs as usual, then applying the umask to
decrease or increase access as by a chmod, and do all of this
atomically".

The atomicity is the important part, because otherwise a client might
create a file that initially starts out as having a broad (inherited!)
ACL, and then decrease access via a second operation (possibly in the
same RPC, but RPCs are not atomic), thus creating a race condition when
trying to create files with more restrictive ACLs.

Clearly, the umask very much improves security.=C2=A0 It is rather shocking=
that NFSv4 didn't have it to begin with.

We figured out the correct way to a) construct apparent mode bits from
ACLs, and b) apply mode bits changes to ACLs, years ago after many
dissatisfying attempts.=C2=A0 I don't think that is at all codified in = any
RFC (but I don't follow NFSv4 that closely, so I may be wrong).=C2=A0 P= erhaps
it should be, even though experimenting with various different
algorithms was made possible by... not specifying it in the first place
-- the state of the art here seems mature.

> > If it is appropriate to move the goal posts here, based on curren= t needs, we
> > have to understand exactly what is being asked for, in order to s= ee if
> > remediation is possible while maintaining continuity with the exi= sting NFSv4
> > protocol and implementations.=C2=A0 Some possibilities:
> >
> > A clear security plan which defines the threats that NFSv4 addres= ses and is
> > clear about those it does not address (and so have to addressed b= y other
> > means).
> > A security plan plan defining the threats that NFSv4 should addre= ss, how
> > some of those are addressed by various NFSv4 minor versions, and = others will
> > be by extensions to NFSv4.2 or later minor versions.
>
> I prefer the second, but it might never happen. The first is at least<= br> > useful (when combined with what NFSv4 could address as shown by other<= br> > systems of similar kind)

I will admit to not knowing how comprehensively NFSv4's various = base
RFCs cover the NFSv4 security model -- they are enormous RFCs.=C2=A0 Some details are very much left to implementors, mainly how user/group IDs
are represented on disk, how the "authorization context" for any = one
user is established, and how the implementation interfaces with other
protocols such as SMB or local POSIX access.=C2=A0 Leaving those details to=
implementors is purposeful.

I've covered authentication and authorization (above).

I can also speak about the transport security model.=C2=A0 Spoilers: it'= ;s not
that good, and the first attempt to make it significantly better via
IPsec failed due to lack of implementation of RFC5660.=C2=A0 But it's n= ot
exactly broken.

NFSv4's transport security protocol is woefully inefficient for
multi-user clients, but those have gone the way of the dodo.=C2=A0 It's=
inefficient too in terms of ability to leave crypto to HW -- only IPsec
w/ RFC5660 can help here.=C2=A0 And even for single-user clients, it's<= br> inefficient in that RPCSEC_GSS pre-dates AEAD functionality in GSS, so
it uses two GSS operations per-request (and two per-response) where one
should do -- i.e., it has higher overhead than it needs to.

The non-use of IPsec or TLS to protect the confidentiality (and
integrity) of all of the flows between an NFSv4 client and server means
that some traffic analysis can be done, identifying users identified to
eavesdroppers (depending on which GSS mechanism is used).=C2=A0 A more
complete analysis of RPCSEC_GSS should really not be done in the context of this I-D.

Nico
--

--94eb2c12c4308dab6305514c2f58-- From nobody Tue Jun 6 09:00:52 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 438161294B8; Tue, 6 Jun 2017 09:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 zqn9548Ai8Sc; Tue, 6 Jun 2017 09:00:43 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 068BF128990; Tue, 6 Jun 2017 09:00:37 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 90061C002827; Tue, 6 Jun 2017 09:00:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=fOyeFts0oDR0+p 0bR32tE0CG5/8=; b=lE/XVBKq+Pn0oSr0gzoqlHyMb6oef9M8qBml2772/tjuCx ID0BJEgQnRBlA3BXn33yCXuFHoyCvE7GyvLe8x9zLrm5OMjqAPHnbe+IAYt5VsPn fmQP/T1CmZB1XlN8b33iMbm/b4yn0snbon7dDpnLTuNkMIx/K8mnprUtCmBXg= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 91209C002821; Tue, 6 Jun 2017 09:00:36 -0700 (PDT) Date: Tue, 6 Jun 2017 11:00:33 -0500 From: Nico Williams To: David Noveck Cc: Watson Ladd , "secdir@ietf.org" , Phillip Hallam-Baker , Spencer Dawkins at IETF , NFSv4 Message-ID: <20170606160032.GC3432@localhost> References: <20170605165254.GE2903@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [secdir] [nfsv4] SECDIR Review of draft-ietf-nfsv4-umask-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 16:00:44 -0000 On Tue, Jun 06, 2017 at 11:21:13AM -0400, David Noveck wrote: > > A more complete analysis of RPCSEC_GSS should really not be > > done in the context of this I-D. > > I agree that it should not, but it is not clear exactly what is being > asked for to get this document into the RFC editing process. Unlike It's a secdir review. It plays no official part in the publication process. It is merely a review meant to aid the IESG. > xattrs, this document actually has been approved. The state is listed > as "Approved-announcement to be sent::Point Raised - writeup needed" > so we know it has been approved but are unclear about why this has not > been announced, what exactly the point raised might be and how the > issue/point is to be resolved. The secdir review may simply have been too late. But it's still worth responding to, which I have. I took up this sub-thread because I'm familiar enough with the subject so I can, and because I think Phillip and Watson deserve getting answers on this even if there's no procedural need to provide them. > I think the authors are entitled to a clearer treatment of these matters. So are non-NFSv4 WG participants in this thread. It's not every day you get a free analysis of your protocol by folks like Watson. Rejoice. Nico -- From nobody Wed Jun 7 00:08:57 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 47DA912EA5A; Wed, 7 Jun 2017 00:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 5bSM3SqJLbbq; Wed, 7 Jun 2017 00:08:47 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAE421201FA; Wed, 7 Jun 2017 00:08:47 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id 202so941367ybd.0; Wed, 07 Jun 2017 00:08:47 -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=98TiONn++xsHp86j0MNsM0RhkjRerMShMU8N3T1+AEk=; b=p4ESZIXBsivoSOWta1bfw0/28b9SD/XOZ6i+2vfchyvxK0q43Dlg1d+XP6eAVSjc2a 4/8IBi5L2CozAmkSGO7ah4GTp6+gsY7V9mcgf/V6vmLhjHch+opAM4qqu40fKrvzbRzr veJZXTe9aty2auYabZ5Im4z+ujZIMxjrqZqQU+fWJKSSpaIVpIgd7b2iyDFWtS/bhPPM ogk35oax0CedOu0a6L/41oY6n0VP9co9AnkjRLcGLITVlXdNMPfVXzRaW2unIrKoYxfZ 8ExenrmPkstpSqPYOFdO+i9tplQpocw9iXahQBWPJ4PVLLJSDwWaehv55WyLlP4KfJUJ 4KMg== 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=98TiONn++xsHp86j0MNsM0RhkjRerMShMU8N3T1+AEk=; b=X7HITvYCkQpmS9adCxURR8GhAyfQprUWRZIczVB2rafV1SGF/BYInAhzV+sp8QpeE9 MSVTui5Mwi//3e1V4cc3ycMh+ddfL8Ue5AFYimARIb0P42u4WlVdJDgVWYnM05o4TG6g 3F8DKtvsJRc/PS8uNtJUGTQuYmc58MPzDtAgN5ejWXynHwXDKJdXoQttNoyVTIuaE+zq /7qNlVNNYJYLEVmR4d0jn64nioLzmPwmhk2V7YqKMYFxZZpPELexJMxXmxK9wWMYMhM1 nd/6Heh7LrHnyJOyPhfSeMjFSp/+hQ83jPTCJM/kzuBPF8RbnCGBX9UouZc3Al0Kiyz4 pdaw== X-Gm-Message-State: AODbwcA5H//QO5Mb25l2x8Q+9wH2Zm6KVtTUs4E1pGA1SF7H87gTVJG4 3+wUUWj9rlzJH66wwNX9foWeSDGhZw== X-Received: by 10.37.204.75 with SMTP id l72mr5486620ybf.176.1496819327003; Wed, 07 Jun 2017 00:08:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.195.194 with HTTP; Wed, 7 Jun 2017 00:08:46 -0700 (PDT) In-Reply-To: <20170606160032.GC3432@localhost> References: <20170605165254.GE2903@localhost> <20170606160032.GC3432@localhost> From: Spencer Dawkins at IETF Date: Wed, 7 Jun 2017 02:08:46 -0500 Message-ID: To: Nico Williams Cc: David Noveck , Watson Ladd , "secdir@ietf.org" , Phillip Hallam-Baker , NFSv4 Content-Type: multipart/alternative; boundary="94eb2c0ef74247737105515968be" Archived-At: Subject: Re: [secdir] [nfsv4] SECDIR Review of draft-ietf-nfsv4-umask-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 07:08:49 -0000 --94eb2c0ef74247737105515968be Content-Type: text/plain; charset="UTF-8" Hi, David, Speaking as the responsible AD ... On Tue, Jun 6, 2017 at 11:00 AM, Nico Williams wrote: > On Tue, Jun 06, 2017 at 11:21:13AM -0400, David Noveck wrote: > > > A more complete analysis of RPCSEC_GSS should really not be > > > done in the context of this I-D. > > > > I agree that it should not, but it is not clear exactly what is being > > asked for to get this document into the RFC editing process. Unlike > > It's a secdir review. It plays no official part in the publication > process. It is merely a review meant to aid the IESG. > > > xattrs, this document actually has been approved. The state is listed > > as "Approved-announcement to be sent::Point Raised - writeup needed" > > so we know it has been approved but are unclear about why this has not > > been announced, what exactly the point raised might be and how the > > issue/point is to be resolved. > > The secdir review may simply have been too late. But it's still worth > responding to, which I have. > > I took up this sub-thread because I'm familiar enough with the subject > so I can, and because I think Phillip and Watson deserve getting answers > on this even if there's no procedural need to provide them. > > > I think the authors are entitled to a clearer treatment of these matters. > > So are non-NFSv4 WG participants in this thread. It's not every day you > get a free analysis of your protocol by folks like Watson. Rejoice. The document is approved. We now approve documents with no Discuss ballot positions, but can still make changes to resolve comments that arise during IESG Evaluation, if that's appropriate. I read Phillip's SECDIR review with interest. It does not seem to apply to this draft, any more than to the rest of NFSv4, so I wouldn't hold up this draft to pursue the issues Phillip raised. Those issues do seem to be a useful input to NFSv4, as the working group considers a charter update (after finishing quite a lot of work, and thanks to you all for that). Does that help? Spencer (D) --94eb2c0ef74247737105515968be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, David,=C2=A0

Speaking as the respon= sible AD ...

On Tue, Jun 6, 2017 at 11:00 AM, Nico Williams <nico@cryptonector.com= > wrote:
O= n Tue, Jun 06, 2017 at 11:21:13AM -0400, David Noveck wrote:
> > A more complete analysis of RPCSEC_GSS should really not be
> > done in the context of this I-D.
>
> I agree that it should not, but it is not clear exactly what is being<= br> > asked for to get this document into the RFC editing process.=C2=A0 Unl= ike

It's a secdir review.=C2=A0 It plays no official part in the pub= lication
process.=C2=A0 It is merely a review meant to aid the IESG.

> xattrs, this document actually has been approved.=C2=A0 The state is l= isted
> as "Approved-announcement to be sent::Point Raised - writeup need= ed"
> so we know it has been approved but are unclear about why this has not=
> been announced, what exactly the point raised might be and how the
> issue/point is to be resolved.

The secdir review may simply have been too late.=C2=A0 But it's = still worth
responding to, which I have.

I took up this sub-thread because I'm familiar enough with the subject<= br> so I can, and because I think Phillip and Watson deserve getting answers on this even if there's no procedural need to provide them.

> I think the authors are entitled to a clearer treatment of these matte= rs.

So are non-NFSv4 WG participants in this thread.=C2=A0 It's not = every day you
get a free analysis of your protocol by folks like Watson.=C2=A0 Rejoice.

=C2=A0The document is approved. We now appro= ve documents with no Discuss ballot positions, but can still make changes t= o resolve comments that arise during IESG Evaluation, if that's appropr= iate.

I read Phillip's SECDIR review with inte= rest. It does not seem to apply to this draft, any more than to the rest of= NFSv4, so I wouldn't hold up this draft to pursue the issues Phillip r= aised.

Those issues do seem to be a useful input t= o NFSv4, as the working group considers a charter update (after finishing q= uite a lot of work, and thanks to you all for that).

Does that help?

Spencer (D)
--94eb2c0ef74247737105515968be-- From nobody Wed Jun 7 03:44: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 E4A8212EB94; Wed, 7 Jun 2017 03:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 kUovDeiCXsm1; Wed, 7 Jun 2017 03:44:09 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 6F69012EB93; Wed, 7 Jun 2017 03:44:09 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id m47so109938541iti.1; Wed, 07 Jun 2017 03:44:09 -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=+EkJZ91wyojwlSww/8E+YBDpGXzOUwufkIG/+p4IM1A=; b=rrscI1izK5Yl7sowyVWykSyLaj8B5w9kMKCZGXfyKlHpNbSZkKKIIiPK2yT/z2OAqS tJuPfGKkDYbtw8iG2TAYt1UWvlnrAZgZ7jp73BijqX6pVXhF6WbkfSNC5gaf3pio5MFz tRtLMGRZXOKBQxv4+mMCmXYYSxU6+r6XfxkbKO4VjzNrlsXp0yByCJu1pRUm3CD04nx4 e2uVSNQtcIpl8KzcKo+20J9Q6XT2VxsANwQdNoLeu706hLWD3tv84lgekK0ggvGVffF9 gX4UBLY3qqBL6JDNyShm67/daamoetjg5G+BtKYs21vx3Yrticvm0CxA3Qd17NLhnSKy jGEg== 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=+EkJZ91wyojwlSww/8E+YBDpGXzOUwufkIG/+p4IM1A=; b=uRVsbgt8M3AQNfWR7gOFqw280iC2qR4ZwQWZl7/Q9sdeotRnokVGxeA0N8SnRKwIgM /D/NxvD7Cz0EghTAUXgUDaT/Cx00sRbYCc1OPqCd2PZTaYAFA6LH+qwxKlIWMx30ytF/ dx5LNfPT8g9MmXPspEgTLzfZsAo3Vb1nvo5MY7NBG2DptpM4DWFi+h9aQI3dbCKUlAVI k0aLYqNce562f/LP8KAnIlJJ9eN7BYXilWsAt6+852KhivpH9PsLn8k3Ilrv37l+JR7w e8rdJCsuYnYnQ7ojygstsrdz8B3+4v8znntt34jSHo2ZJFalM4o5TLyBCyUr8/re8VZ4 PhmQ== X-Gm-Message-State: AODbwcA5R6vIJiW3i1PwKoalCHhn66x2b93yI7J4FlirKCRW01MTQCjx 9GndGNA4KwaBklVYjzrdADJedm6CEQ== X-Received: by 10.36.246.67 with SMTP id u64mr913554ith.3.1496832248743; Wed, 07 Jun 2017 03:44:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.20.75 with HTTP; Wed, 7 Jun 2017 03:44:08 -0700 (PDT) In-Reply-To: References: <20170605165254.GE2903@localhost> <20170606160032.GC3432@localhost> From: David Noveck Date: Wed, 7 Jun 2017 06:44:08 -0400 Message-ID: To: Spencer Dawkins at IETF Cc: Nico Williams , Watson Ladd , "secdir@ietf.org" , Phillip Hallam-Baker , NFSv4 Content-Type: multipart/alternative; boundary="94eb2c12c430798dc905515c6aa5" Archived-At: Subject: Re: [secdir] [nfsv4] SECDIR Review of draft-ietf-nfsv4-umask-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 10:44:11 -0000 --94eb2c12c430798dc905515c6aa5 Content-Type: text/plain; charset="UTF-8" > Does that help? Yes it does. As NIco points out, implementations of this document will help improve NFSv4 security, although the issues addressed seem to be disjoint from the ones raised in the SECDIR review. In any case, since prototypes exist, I hope we will see iincreasing interoperability testing of umask implementations, On Wed, Jun 7, 2017 at 3:08 AM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Hi, David, > > Speaking as the responsible AD ... > > On Tue, Jun 6, 2017 at 11:00 AM, Nico Williams > wrote: > >> On Tue, Jun 06, 2017 at 11:21:13AM -0400, David Noveck wrote: >> > > A more complete analysis of RPCSEC_GSS should really not be >> > > done in the context of this I-D. >> > >> > I agree that it should not, but it is not clear exactly what is being >> > asked for to get this document into the RFC editing process. Unlike >> >> It's a secdir review. It plays no official part in the publication >> process. It is merely a review meant to aid the IESG. >> >> > xattrs, this document actually has been approved. The state is listed >> > as "Approved-announcement to be sent::Point Raised - writeup needed" >> > so we know it has been approved but are unclear about why this has not >> > been announced, what exactly the point raised might be and how the >> > issue/point is to be resolved. >> >> The secdir review may simply have been too late. But it's still worth >> responding to, which I have. >> >> I took up this sub-thread because I'm familiar enough with the subject >> so I can, and because I think Phillip and Watson deserve getting answers >> on this even if there's no procedural need to provide them. >> >> > I think the authors are entitled to a clearer treatment of these >> matters. >> >> So are non-NFSv4 WG participants in this thread. It's not every day you >> get a free analysis of your protocol by folks like Watson. Rejoice. > > > The document is approved. We now approve documents with no Discuss ballot > positions, but can still make changes to resolve comments that arise during > IESG Evaluation, if that's appropriate. > > I read Phillip's SECDIR review with interest. It does not seem to apply to > this draft, any more than to the rest of NFSv4, so I wouldn't hold up this > draft to pursue the issues Phillip raised. > > Those issues do seem to be a useful input to NFSv4, as the working group > considers a charter update (after finishing quite a lot of work, and thanks > to you all for that). > > Does that help? > > Spencer (D) > --94eb2c12c430798dc905515c6aa5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> Does that hel= p?

Yes it does.=C2=A0 As NIco points out, imp= lementations of this document will help improve NFSv4 security, although th= e issues addressed seem to be disjoint from the ones raised in the SECDIR r= eview.=C2=A0 In any case, since prototypes exist, I hope we will see iincre= asing interoperability testing of umask implementations,
=

On Wed, Jun 7, 20= 17 at 3:08 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gm= ail.com> wrote:
Hi, David,=C2=A0

Speaking as the responsible AD ..= .

On Tue, Jun 6, 2017 at 11:00 AM, Nico Williams <= ;nico@cryptonect= or.com> wrote:
On Tue= , Jun 06, 2017 at 11:21:13AM -0400, David Noveck wrote:
> > A more complete analysis of RPCSEC_GSS should really not be
> > done in the context of this I-D.
>
> I agree that it should not, but it is not clear exactly what is being<= br> > asked for to get this document into the RFC editing process.=C2=A0 Unl= ike

It's a secdir review.=C2=A0 It plays no official part in the pub= lication
process.=C2=A0 It is merely a review meant to aid the IESG.

> xattrs, this document actually has been approved.=C2=A0 The state is l= isted
> as "Approved-announcement to be sent::Point Raised - writeup need= ed"
> so we know it has been approved but are unclear about why this has not=
> been announced, what exactly the point raised might be and how the
> issue/point is to be resolved.

The secdir review may simply have been too late.=C2=A0 But it's = still worth
responding to, which I have.

I took up this sub-thread because I'm familiar enough with the subject<= br> so I can, and because I think Phillip and Watson deserve getting answers on this even if there's no procedural need to provide them.

> I think the authors are entitled to a clearer treatment of these matte= rs.

So are non-NFSv4 WG participants in this thread.=C2=A0 It's not = every day you
get a free analysis of your protocol by folks like Watson.=C2=A0 Rejoice.

=C2=A0The document is approved. We no= w approve documents with no Discuss ballot positions, but can still make ch= anges to resolve comments that arise during IESG Evaluation, if that's = appropriate.

I read Phillip's SECDIR review wi= th interest. It does not seem to apply to this draft, any more than to the = rest of NFSv4, so I wouldn't hold up this draft to pursue the issues Ph= illip raised.

Those issues do seem to be a useful = input to NFSv4, as the working group considers a charter update (after fini= shing quite a lot of work, and thanks to you all for that).

<= /div>
Does that help?

Spencer (D)
<= /div>

--94eb2c12c430798dc905515c6aa5-- From nobody Wed Jun 7 19:31:48 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 10E51128B8D; Wed, 7 Jun 2017 19:31:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Daniel Franke To: Cc: draft-ietf-bmwg-vswitch-opnfv.all@ietf.org, ietf@ietf.org, bmwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.53.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149688909394.25708.7443355162118602638@ietfa.amsl.com> Date: Wed, 07 Jun 2017 19:31:33 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-bmwg-vswitch-opnfv-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 02:31:34 -0000 Reviewer: Daniel Franke Review result: Ready I reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. This Informational draft outlines methodology for benchmarking switches, carried out on isolated test networks. It defines no new protocols or device capabilities in support of the recommended methodology, or anything else which would introduce any new security considerations. From nobody Wed Jun 7 21:21: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 EE0FA129B0E; Wed, 7 Jun 2017 21:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rc5.so-net.ne.jp 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 Jg9ClB_2Tmtc; Wed, 7 Jun 2017 21:21:24 -0700 (PDT) Received: from ms-omx51.so-net.ne.jp (ms-omx51.so-net.ne.jp [202.238.84.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B0CB129B09; Wed, 7 Jun 2017 21:21:24 -0700 (PDT) Received: from ms-omx61.so-net.ne.jp (ms-omx61.plus.so-net.ne.jp [10.240.84.163]) by ms-omx51.plus.so-net.ne.jp with ESMTP id v584LNk0024582; Thu, 8 Jun 2017 13:21:23 +0900 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rc5.so-net.ne.jp; s=sn2017; t=1496895683; bh=DGLgt7ufQHPl/2nI82vdOw4iaG4889cHnZrZMcXOaXc=; h=In-Reply-To:References:From:Date:Subject:To:Cc; b=ryNWZY1fy97LtcmT8fY6ynLTv/7gxgpZPJUCOoYtk44cEOJ0tUhtnKKitsT8qlcaK 8LSGu+Fz7lcuk8NUhI4NhCA0nHwyMX/ZJq/vThAGxk6RVSwPsMVzFVBuMQCZFMtdGG DLQI8uzdj4c7QPgp86KSouDA+j9gMgZIoOjE2niu0CulbJpdcNiSbIXGVAk3sD3aAS LuO5XBIWxdeLAfiOYAYzBsk5M4dlnbz6nJ/stSn95quR64CW7Q7SKS4b/vwM+WAGo3 UcAf9lHWUYyhZ623u5JvRfHN/tVYty2i/KlCdo9/OMV5Ib9nJBQmaRhTclFl4sVGO+ ntnijhmZt77/A== Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com [209.85.216.179]) (authenticated) by ms-omx61.plus.so-net.ne.jp with ESMTP id v584LLag024985 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Thu, 8 Jun 2017 13:21:22 +0900 Received: by mail-qt0-f179.google.com with SMTP id c10so28807525qtd.1; Wed, 07 Jun 2017 21:21:22 -0700 (PDT) X-Gm-Message-State: AKS2vOy/dfaspElcyIwaAF2R4TzJu17MC37KzYt0vx6PIMERuutHSpH2 7NgcVAWaJnzUDG/a9MBRWcpmghBfWA== X-Received: by 10.55.82.67 with SMTP id g64mr10361914qkb.41.1496895681241; Wed, 07 Jun 2017 21:21:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.53.16 with HTTP; Wed, 7 Jun 2017 21:20:40 -0700 (PDT) In-Reply-To: <002701d2b742$812b7880$83826980$@nict.go.jp> References: <002701d2b742$812b7880$83826980$@nict.go.jp> From: Takeshi Takahashi Date: Thu, 8 Jun 2017 13:20:40 +0900 X-Gmail-Original-Message-ID: Message-ID: To: Takeshi Takahashi Cc: draft-ietf-grow-bgp-reject.all@ietf.org, iesg@ietf.org, secdir@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [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: Thu, 08 Jun 2017 04:21:27 -0000 Hello, I was re-assigned to review 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 of the changes after the 05 draft] Many changes are made. Especially, this draft updates RFC4271, which anyway was cited in the normative reference section. Moreover, the "solution" section was removed, (especially, its 4th bullet was completely removed.) I believe the content became more mature. As mentioned before, I see no problem in this draft. Thank you. Take 2017-04-17 12:07 GMT+09:00 Takeshi Takahashi : > 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 > -- -- Takeshi Takahashi, Ph.D., CISSP, PMP "Practice makes perfect!" From nobody Wed Jun 7 21:22:14 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD6C129B09; Wed, 7 Jun 2017 21:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 I2zrnM8n6Lng; Wed, 7 Jun 2017 21:22:07 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id EE3CF129B0E; Wed, 7 Jun 2017 21:22:06 -0700 (PDT) Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns2.nict.go.jp with ESMTP id v584M5Mx013593; Thu, 8 Jun 2017 13:22:05 +0900 (JST) Received: from DESKTOP2JPR8KD (ssh1.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp with ESMTP id v584M5YW013586; Thu, 8 Jun 2017 13:22:05 +0900 (JST) From: "Takeshi Takahashi" To: , , Date: Thu, 8 Jun 2017 13:22:05 +0900 Message-ID: <000001d2e00e$c8edfe50$5ac9faf0$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdLgDsiPcD4dLBLQR3qgubN+0eRm7A== Content-Language: ja X-Virus-Scanned: clamav-milter 0.98.7 at zenith2 X-Virus-Status: Clean Archived-At: Subject: [secdir] Secdir review of draft-ietf-grow-bgp-reject-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, 08 Jun 2017 04:22:09 -0000 Hello, I was re-assigned to review 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 of the changes after the 05 draft] Many changes are made. Especially, this draft updates RFC4271, which anyway was cited in the = normative reference section. Moreover, the "solution" section was removed, (especially, its 4th = bullet was completely removed.) I believe the content became more = mature. As mentioned before, I see no problem in this draft. Thank you. Take 2017-04-17 12:07 GMT+09:00 Takeshi Takahashi = : > Hello, > > I have reviewed this document as part of the security directorate's=20 > ongoing effort to review all IETF documents being processed by the = IESG. > These comments were written primarily for the benefit of the security=20 > area directors. > Document editors and WG chairs should treat these comments just like=20 > 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 Thu Jun 8 13:34: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 7FAEB129535 for ; Thu, 8 Jun 2017 13:34:10 -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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-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 vrHg5JzRCn0h for ; Thu, 8 Jun 2017 13:34:09 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A26921294FF for ; Thu, 8 Jun 2017 13:34:07 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id p62so21504681vkp.0 for ; Thu, 08 Jun 2017 13:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qG3aT16h1I667aXHYvEdhf2xIyCWueYY/hhClT1UWn8=; b=vHBfxNflePerOfLqW9M0gukCAt/Xr6n2Wd1NSLkYA9peyqJBQf2MGM7Umza9yYKlmN J706zE5TweXq1Anbs+VeCauO58DZ/IL0mZd9nwz9iJ7Kd7gxSJC8agNM35H+mTx9oFaD UDQfLnXOW/HEtccRVHVSqDNXoTL8uABSG3lj9Om3Uev8BlehD/8gkPxBBjK7PzOleh5M Plr9yDgXpWovPDDL2Cv6/iPzF5I1TA0A0f/GWIPF19bZHsA21npdLwzR6Pvewh0Feb+K otsTYGZg+kNpXAWCjlLP/uOLHPyec4HsX82W4UPvMSo0csZr+RwdD5Bd8LTqY/JdezTO r5ag== 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=qG3aT16h1I667aXHYvEdhf2xIyCWueYY/hhClT1UWn8=; b=lFUetdfwEU6V1LbMmUEWotLlPiLGpJ+CAVteBGEHaH5u0a8FhxN2xKyDrZB8I9aIHr 3OVktmnO1RWKVmKLuhka/vrBrAQpA9hYw7Gmnf3Zcu99Y65Fe0UsD6foYtaDu3wKNaeC vBP+YDek/0UiX1R1KlTql4P+f8FJgX7uwv3Pg/XAMOpOQpfSZvSsDUOoRFgS2EVFB9+p wGJuqdLaK4gix65jbL7j9GIAPQs66QXCpx05NEgTWVGdzm4u1vjK9Jv1S2KH+qmQNwdk duPJljhoT4/7LXntPa1TnKmzGmzvU7OMjEWSowaDxtZ5oPDJ5naMfnecWOmJj47NV+ar gx5A== X-Gm-Message-State: AODbwcDY/TKHYw3Z6WQ7ZnZYGCoCoJCMvJ77MIKVdwyX9cv3GMAKWaAl 7YRu/rhlEWd9UDQieR6sz7JYUOWQUcDg X-Received: by 10.31.107.155 with SMTP id k27mr20120586vki.51.1496954046667; Thu, 08 Jun 2017 13:34:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.198 with HTTP; Thu, 8 Jun 2017 13:33:26 -0700 (PDT) In-Reply-To: <000001d2e00e$c8edfe50$5ac9faf0$@nict.go.jp> References: <000001d2e00e$c8edfe50$5ac9faf0$@nict.go.jp> From: Warren Kumari Date: Thu, 8 Jun 2017 16:33:26 -0400 Message-ID: To: Takeshi Takahashi Cc: draft-ietf-grow-bgp-reject.all@ietf.org, The IESG , IETF Security Directorate Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-grow-bgp-reject-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, 08 Jun 2017 20:34:10 -0000 On Thu, Jun 8, 2017 at 12:22 AM, Takeshi Takahashi wrote: > Hello, > > I was re-assigned to review 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 of the changes after the 05 draft] Many changes are made. > Especially, this draft updates RFC4271, which anyway was cited in the normative reference section. > Moreover, the "solution" section was removed, (especially, its 4th bullet was completely removed.) I believe the content became more mature. > As mentioned before, I see no problem in this draft. I just quickly wanted to thank you for your (repeated!) reviews. Appreciated, W > > Thank you. > Take > > > > > 2017-04-17 12:07 GMT+09:00 Takeshi Takahashi : >> 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 >> > > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Jun 8 14:47:40 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 60BD612952D; Thu, 8 Jun 2017 14:47:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir To: Cc: mpls@ietf.org, ietf@ietf.org, draft-ietf-mpls-app-aware-tldp.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149695844237.15142.17304755568511932911@ietfa.amsl.com> Date: Thu, 08 Jun 2017 14:47:22 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-mpls-app-aware-tldp-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: Thu, 08 Jun 2017 21:47:22 -0000 Reviewer: Yoav Nir Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. My biggest issue with this document is that it is hard to read. For example, the Introduction expands tLDP to "targeted LDP", and the Introduction begins with "LDP uses extended discovery...", but LDP itself is only expanded to "label distribution protocol" in the IANA considerations section. Similarly, the much-overloaded term "application" is never explained except that some applications are "targeted" and that "FEC 128 pseudowire" is an example of an application. I am sure this makes sense to participants of the MPLS working group, but to others this is much harder. There needs to be at least a reference to RFC 5036 where these terms are better explained (RFC 5036 is referenced but only as the document where tLDP adjacency is described). Nits: The Security Considerations section begins with "The Capability procedure described in this document will apply and does not introduce any change to LDP Security Considerations". The procedure will apply what? Or will apply to what? I think the words "will apply and" are superfluous. The second paragraph seems to be repeating part of the (rather extensive) security considerations of RFC 5036, but it does not say why (or even whether) that particular anti-DoS measure applies in particular to the mechanism described in this document. IOW why is this measure singled out from among the three pages of security considerations from RFC 5036? The third paragraph is not clear to me. It talks about two nodes not establishing a tLDP session if they don't support the same application. I don't know why that belongs in the security considerations section. The SHOULD NOT (establish a session) mandate definitely does not belong there. From nobody Thu Jun 8 22:11: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 D9060126B7E for ; Thu, 8 Jun 2017 22:11:22 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-gpqzPHfV-k for ; Thu, 8 Jun 2017 22:11:20 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B3E2127275 for ; Thu, 8 Jun 2017 22:11:20 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id a70so22855758pge.3 for ; Thu, 08 Jun 2017 22:11:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=zhISNj7a+LtV3Qxi7ua+RMQ5SktLHCet1LtX8hfA1VQ=; b=nwzSGs4KV31y+X6ixhWAa5ItSVNxQIBON4J4iPYB1p5PIIReJh3QWPw+GHoyKs0kpq UkcaVwj9UE5wVshjpxfKhmlCa1jw42u5wCB9qESBzIMRcDR8dmjulRZTaXbre815aaAi W7znmnbIo/YymYoRJ7bdWOdi5zypUM4Y2uRGdHIWutHEbFrskglWZ7aCBNSJ+6IDra+Y nJ2m4/EHVYF6Im6+UNyFNcLNf8eYMAISwuEeVvWzlASD3/IDIHlmqm5JdNWaheFaBbAm H04xmppHfvMBpOtEKm5fs9OWu6N239vK84iYLjeGA5JQINPE705EzvYYYKwt2Qrq41G4 MZwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=zhISNj7a+LtV3Qxi7ua+RMQ5SktLHCet1LtX8hfA1VQ=; b=sMG9RDfvvA7vH4T2fTT6TkeHitg7TEDF/hLCvCct2RXInTV4cXi8eBw2bJpQ6l/AuX ZEwi0yyaZA+uA0Yy6TXtko1k9XgsVMFiCka1uKtz6QoHwkhBaiMQ6H9KEtmazzQfPruH b9romDn1SzxY+f1iV4oMhK27QgMBOXQTHpManu+njjk5C2MOoVN9CrWMzCrWvDDjGFtO MrqOCMY/8397sIgQG9nUyLz0vA+pXn0ShYVyedxBhjy5D+pHQDq71kDv4P7LKfwqoL2h EOE298oU8uCalZghtrhoq858vmd6Yqm0b5S8fHnhf+7pYM/gmwUTfYTZO2bjhdI++zFp pOFg== X-Gm-Message-State: AODbwcDyJKHRczsjE3alI/gcxPWR1QIGwVw7OeW5nXm1w0gw11Rotosb NP1wZ0oLGGEQX5bi59zL992P1K6bhrMW X-Received: by 10.98.194.132 with SMTP id w4mr40168226pfk.176.1496985079571; Thu, 08 Jun 2017 22:11:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.138.38 with HTTP; Thu, 8 Jun 2017 22:10:59 -0700 (PDT) From: Lucien Avramov Date: Thu, 8 Jun 2017 22:10:59 -0700 Message-ID: To: Adam Montville Cc: draft-ietf-bmwg-dcbench-terminology.all@ietf.org, "secdir@ietf.org" , The IESG Content-Type: multipart/alternative; boundary="94eb2c18e3b6e7a3df05517fff7f" Archived-At: Subject: Re: [secdir] SECDIR Review of: draft-ietf-bmwg-dcbench-terminology 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, 09 Jun 2017 05:11:23 -0000 --94eb2c18e3b6e7a3df05517fff7f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Adam! Many thanks for the review! I addressed your comments and published -10 of the draft (draft-ietf-bmwg-dcbench-terminology-10). Please see inline for some comments. Thanks a lot for the detail feedback! Lucien On Mon, Jun 5, 2017 at 10:32 AM, Adam Montville 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 are= a > directors. Document editors and WG chairs should treat these comments jus= t > like any other last call comments. > > Bottom Line: Almost Ready > > About Security Considerations > For your security considerations phrases like "are limited to" and "will > be", and I would suggest that these are your MUSTs or SHOULDs. Given the > "MUST NOT" you have in the second paragraph, it seems that "MUST" should = be > used instead of "SHOULD". In that sense, then, I would suggest the > following statements be updated: 1) "Benchmarking activities as described > in this memo MUST be limited to technology characterization using > controlled stimuli...", "The benchmarking network topology MUST be an > independent test setup..." > > That said, you might consider softening the "MUST NOT" and consequent > "MUST" statements to "SHOULD NOT" and "SHOULD", respectively. This becaus= e > there may well be circumstances where testing in a production environment > is necessary. > > > *These are the standard security considerations all BMWG uses for all the drafts. We want to stay with the considerations we chose. * > About Rest of Draft > The draft describes well-understood concepts of FILO, FIFO, LILO, and > LIFO. It then goes on to recast these definitions as "first bit last bit" > (or "FL"), and "last bit last bit" (or "LL"), and so on. However, the dra= ft > does not really make use of these alternate expressions for the > aforementioned well-understood concepts. I recommend picking one of these > representations and using it consistently throughout; moreover, I recomme= nd > sticking with FILO, FIFO, LILO, and LIFO. > *We do want to stay with FILO, FIFO, LILO and LIFO. The FL, LL, etc were added as this was sometimes referred to as, not to as FL, LL, etc.* > > There's a sentence in 2.2 which reads, "Data Center DUTs are frequently > store-and-forward for smaller packet sizes and then adopting a cut-throug= h > behavior." This feels incomplete. When does it adopt cut-through behavior= ? > Is that adopted for larger packet sizes? Is it worthwhile to talk at all > about the change threshold? > *I addressed your comment by updating the text in the publication to state that the threshold change is not matter, what matters is that the test FILO is key, in order to catch these differences of behaviors. * > > Section 1.2 describes the generally expected definition format. However, > section 2 seems to immediately depart from that to some degree by placing > terms as top-level sections (i.e. "2. Latency") with children for > definition, discussion, and measurement units. To compound this confusion= , > section 6 further departs from the expectation set in 1.2 by using the > top-level section as a grouping construct for "Buffering" (without defini= ng > "Buffering"). Buffering has two children which are "buffer" and "incast". > Buffer, itself is never defined, but instead has a "definition" subsectio= n > consisting of many other terms. The same sort of thing happens with "6.2 > Incast". Please pick a format and make clear what things are terms, and > which are not terms. Then rewrite section 1.2, so that it more properly > describes what the reader should expect. > *This is just nesting of the format, Incast is a sub of Buffering. We can change them to top level with Buffering =E2=80=93 Buffer and Buffering =E2= =80=93 Incast, however we find that less readable for the user and want to keep the current display/text the way it is.* > > There are, at several locations, uses of the capitalized word "CAN" in a > way that suggests normative-type intent. "CAN" does not seem to be an > RFC2119 keyword. In one case, it seems that "CAN" may actually mean a low= er > case "may" or "can" (see 6.1.1 on page 12). > *This is fixed, thank you!* > Nits > Throughout the draft sometimes terms are capitalized, sometimes they are > not. I believe they should more often not be capitalized, but if they are= , > do so consistently. > > Generally speaking (this may be stylistic) the first word after a colon > (':') should be capitalized. Example: This is. > *This is fixed, thank you!* > > Find acronyms/initializations and ensure they're expanded at least on the > first occurrence (i.e. "PDV" on page 6) > Thanks! > > In the abstract s/as it is to/as to/ > > *This is fixed, thank you!* > In 2.1 s/in unit of/in units of/ and s/store forward/store and forward/ > *This is fixed, thank you!* > > In 2.3 s/follow:/follows:/ > *This is fixed, thank you!* > > In 2.3, item 2: Is "proceed data" a common term? > *This is fixed, thank you!* > > In 4.1 s/test on/tests on/ > *This is fixed, thank you!* > > In 4.3 s/of :/of:/ > *This is fixed, thank you!* > > In 4.3 s/[4.1s]/section 4.1/ > *This is fixed, thank you!* > > In 5.3, if "CAN" is changed to "can", then s/line rate can measured/line > rate can be measured/ > *This is fixed, thank you!* > In 6.1.1 s/expressed in Byte;/B (bytes),/ or s/expressed in Byte;/Bytes,/ > *This is fixed, thank you!* > > In 6.1.1 s/amount of buffer a single/amount of buffer for a single/ > *This is fixed, thank you!* > > In 6.1.1 recommend striking "it is a burst" > *This is fixed, thank you!* > > In 6.2.1 s/by synchronous/by synchronous arrival time/ > *This is fixed, thank you!* > > In 6.2.2 s/In a ingress/In an ingress/ > *This is fixed, thank you!* > > In 6.2.2 s/In either cases/In either case/ > *This is fixed, thank you!* > > In 6.2.3 s/non null/non-null/ > *This is fixed, thank you!* > > In 7.3 the first paragraph could be improved by simply writing, "When S > represents the payload bytes, which does not include packet or TCP header= s, > and Ft is the Finishing Time of the last sender, the Goodput, G, is then > measured by the following formula..." > *This is fixed, thank you!* > > > Kind regards, > > Adam > > > --94eb2c18e3b6e7a3df05517fff7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Adam!

Many thanks for the review! I = addressed your comments and published -10 of the draft (draft-ietf-bmwg-dcb= ench-terminology-10).=C2=A0

Please see inline for = some comments.

Thanks a lot for the detail feedbac= k!

Lucien

On Mon, Jun 5, 2017 at 10:32 AM, Adam Montville <adam.w.montville@gmail.com> wrote:
I have reviewed thi= s document as part of the security directorate's ongoing effort to revi= ew all IETF documents being processed by the IESG. These comments were writ= ten primarily for the benefit of the security area directors. Document edit= ors and WG chairs should treat these comments just like any other last call= comments.

Bottom Line: Almost Ready
About Security Considerations
For your security consi= derations phrases like "are limited to" and "will be", = and I would suggest that these are your MUSTs or SHOULDs. Given the "M= UST NOT" you have in the second paragraph, it seems that "MUST&qu= ot; should be used instead of "SHOULD". In that sense, then, I wo= uld suggest the following statements be updated: 1) "Benchmarking acti= vities as described in this memo MUST be limited to technology characteriza= tion using controlled stimuli...", "The benchmarking network topo= logy MUST be an independent test setup..."

Th= at said, you might consider softening the "MUST NOT" and conseque= nt "MUST" statements to "SHOULD NOT" and "SHOULD&q= uot;, respectively. This because there may well be circumstances where test= ing in a production environment is necessary.


=
These are the s= tandard security considerations all BMWG uses for all the drafts. We want t= o stay with the considerations we chose.=C2=A0
=C2=A0
<= /div>
About Rest of Draft
The draft describes well-understood= concepts of FILO, FIFO, LILO, and LIFO. It then goes on to recast these de= finitions as "first bit last bit" (or "FL"), and "= last bit last bit" (or "LL"), and so on. However, the draft = does not really make use of these alternate expressions for the aforementio= ned well-understood concepts. I recommend picking one of these representati= ons and using it consistently throughout; moreover, I recommend sticking wi= th FILO, FIFO, LILO, and LIFO.

= We do want to stay with FILO, FIFO, LILO and = LIFO. The FL, LL, etc were added as this was sometimes referred to as, not = to as FL, LL, etc.
=C2=A0

There's a sent= ence in 2.2 which reads, "Data Center DUTs are frequently store-and-fo= rward for smaller packet sizes and then adopting a cut-through behavior.&qu= ot; This feels incomplete. When does it adopt cut-through behavior? Is that= adopted for larger packet sizes? Is it worthwhile to talk at all about the= change threshold?

I address= ed your comment by updating the text in the publication to state that the t= hreshold change is not matter, what matters is that the test FILO is key, i= n order to catch these differences of behaviors.=C2=A0

=C2=A0

Section 1.2 describes the generally expect= ed definition format. However, section 2 seems to immediately depart from t= hat to some degree by placing terms as top-level sections (i.e. "2. La= tency") with children for definition, discussion, and measurement unit= s. To compound this confusion, section 6 further departs from the expectati= on set in 1.2 by using the top-level section as a grouping construct for &q= uot;Buffering" (without defining "Buffering"). Buffering has= two children which are "buffer" and "incast". Buffer, = itself is never defined, but instead has a "definition" subsectio= n =C2=A0consisting of many other terms. The same sort of thing happens with= "6.2 Incast". Please pick a format and make clear what things ar= e terms, and which are not terms. Then rewrite section 1.2, so that it more= properly describes what the reader should expect.
=

This is just nesting of t= he format, Incast is a sub of Buffering. We can change them to top level wi= th Buffering =E2=80=93 Buffer and Buffering =E2=80=93 Incast, however we fi= nd that less readable for the user and want to keep the current display/tex= t the way it is.
=C2=A0

There are, at severa= l locations, uses of the capitalized word "CAN" in a way that sug= gests normative-type intent. "CAN" does not seem to be an RFC2119= keyword. In one case, it seems that "CAN" may actually mean a lo= wer case "may" or "can" (see 6.1.1 on page 12).

=C2=A0
This is fixed, thank you!
=C2= =A0
Nits
Throughout the draft sometimes terms are ca= pitalized, sometimes they are not. I believe they should more often not be = capitalized, but if they are, do so consistently.

= Generally speaking (this may be stylistic) the first word after a colon (&#= 39;:') should be capitalized. Example: This is.

This is fixed, thank you= !

Find acronyms/initializations and ensure they&= #39;re expanded at least on the first occurrence (i.e. "PDV" on p= age 6)

Thanks!=C2=A0

In the abstract s/as it is to/as to/

This is fixed, thank you!
=C2=A0
<= div dir=3D"ltr">
In 2.1 s/in unit of/in units of/ and s/stor= e forward/store and forward/

This is fixed, thank you!

<= div>In 2.3 s/follow:/follows:/
This is fixed, thank you!

In 2.3, i= tem 2: Is "proceed data" a common term?
<= div>This is fixed, thank you!

<= /div>
In 4.1 s/test on/tests on/
This is fixed, thank you!

In= 4.3 s/of :/of:/
This is fixed, thank you!

In 4.3 s/[4.1s]/section= 4.1/
This is fi= xed, thank you!

In 5.3, if "CAN" is chan= ged to "can", then s/line rate can measured/line rate can be meas= ured/

This is fixed, thank you!
=C2=A0
In 6.1= .1 s/expressed in Byte;/B (bytes),/ or s/expressed in Byte;/Bytes,/
This is fixed, tha= nk you!
=C2=A0

In 6.1.1 s/amount o= f buffer a single/amount of buffer for a single/
This is fixed, thank you!
=C2=A0
=

In 6.1.1 recommend striking "it i= s a burst"
This is fixed, thank you!
=C2=A0

<= div>In 6.2.1 s/by synchronous/by synchronous arrival time/
This is fixed, thank you!
=C2=A0

In 6.2.2 s/In a ingress/In = an ingress/
This is fixed, thank you!
=C2=A0

= In 6.2.2 s/In either cases/In either case/
This is fixed, thank you!
=C2=A0

In 6.2.3 s/non null/non-null/
This is fixed, thank you!=
=C2=A0

In 7.3 the first paragraph= could be improved by simply writing, "When S represents the payload b= ytes, which does not include packet or TCP headers, and Ft is the Finishing= Time of the last sender, the Goodput, G, is then measured by the following= formula..."
This is fixed, thank you!
=C2=A0


Kind regards,

Adam
=


--94eb2c18e3b6e7a3df05517fff7f-- From nobody Fri Jun 9 03:43:12 2017 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8792E12956D for ; Fri, 9 Jun 2017 03:43:11 -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.54.0 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <149700499146.2922.11368848883119253698.idtracker@ietfa.amsl.com> Date: Fri, 09 Jun 2017 03:43:11 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 10:43:11 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-06-22 Reviewer LC end Draft Ben Laurie 2017-06-05 draft-ietf-v6ops-v4v6-xlat-prefix-01 Catherine Meadows 2017-06-15 draft-ietf-tcpm-dctcp-07 Sandra Murphy 2017-06-09 draft-ietf-pals-p2mp-pw-lsp-ping-03 For telechat 2017-07-06 Reviewer LC end Draft David Mandelberg 2017-06-28 draft-baeuerle-netnews-cancel-lock-05 Daniel Migault 2017-06-13 draft-ietf-precis-7700bis-07 Matthew Miller 2017-06-13 draft-ietf-precis-7564bis-07 Last calls: Reviewer LC end Draft Tobias Gondrom 2017-05-14 draft-ietf-calext-caldav-attachments-02 Adam Montville R2017-06-13 draft-ietf-bmwg-dcbench-terminology-10 Russ Mundy 2017-06-13 draft-ietf-bmwg-dcbench-methodology-09 Magnus Nystrom 2017-06-20 draft-ietf-dnsop-sutld-ps-05 Hilarie Orman 2017-06-16 draft-ietf-dmm-mag-multihoming-03 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-10 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Next in the reviewer rotation: Radia Perlman Vincent Roca Joseph Salowey Rich Salz Yaron Sheffer Rifaat Shekh-Yusef Melinda Shore Robert Sparks Takeshi Takahashi Tina Tsou From nobody Fri Jun 9 10:05:26 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 BAF5E1292AE; Fri, 9 Jun 2017 10:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbW63O6bLtjl; Fri, 9 Jun 2017 10:04:58 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDCCC126C89; Fri, 9 Jun 2017 10:04:57 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id m77so7493099lfe.0; Fri, 09 Jun 2017 10:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=ZB6dRgA5+7jxfnaJ1b+0+9R3Jvpf+eoEgu8V+kNLnPY=; b=r1BUwd0QMZeXNpO8Nv6KmfZXPwzAY3MC2YdPtboXVill4GOVe3rSJQQJx20SbZRtT4 el2MxABCyGNJdqLMRr9JEzzFINYsFREj50Wnw2KS0Dg1YWSg+Vz0sh1NI7MnE9nV6vfe v/mUdq4vrpfgaLoohFa9k96ngDeZiv7qEw60D8/TsANX59E+JYGVGIB72wU0CJrluLyG hVrl9jeh3uo7DJPOe8lSlonBnjFd5c1+xSs5NRIBlf5A62hExkbCICMld/EzstmTdg7b pU4nJbOLg9S6ZIw8ZKVdsIkRrnXYpSjFRFGs9OxTAQg9MvLNlavURjfcjd9oOmthGUXZ 6CFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=ZB6dRgA5+7jxfnaJ1b+0+9R3Jvpf+eoEgu8V+kNLnPY=; b=jVGPkD4OAFlbrfYYROy1QtnYEVFcI7sjBFv9xN13S3dGrGIF4m/4RGCuQYem6E1qAx 29g6ae0jNpwPb+kpSIgxKK+uRc5TQOSDvaVRV4S/2Nka/W0AwTy8CmTdVhBe2ZBzpLbA +rjuZlAMG2lRLbHl4VLjBrMFzsvh1LGLSrb/hoyC3o2Gt3CjNX7x5ZrCSeN8TJXckYyh PPmMmreaD+l4xtghTsUl7JIUnEPlbPLDSOz8w3SR8hjKKe0StYXcfQK7XjjvLLoT21ch CqnHaBbZCFXsQPofVqKKg/CmlcnyZEKxBl6vl08TvpeheGms1LVS8fEX0znCIbsT5YJ6 7CwA== X-Gm-Message-State: AODbwcDP3Fpbo2Dvmp3zFw0/vpRMA+VIxZ4upHf9FCiA49QnAugDydpg ALrNUirrD+gjFxLtaKiwvb3nDANi3wHY X-Received: by 10.46.1.155 with SMTP id f27mr8389592lji.55.1497027895883; Fri, 09 Jun 2017 10:04:55 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.0.30 with HTTP; Fri, 9 Jun 2017 10:04:55 -0700 (PDT) From: Daniel Migault Date: Fri, 9 Jun 2017 13:04:55 -0400 X-Google-Sender-Auth: GOjk1Lsq3IMA3jLDAEvjb092rmw Message-ID: To: secdir@ietf.org Cc: The IESG , draft-ietf-precis-7700bis.all@ietf.org Content-Type: multipart/alternative; boundary="001a1142c5b2f3ff37055189f78c" Archived-At: Subject: [secdir] secdir review of draft-ietf-precis-7700bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 17:05:01 -0000 --001a1142c5b2f3ff37055189f78c Content-Type: text/plain; charset="UTF-8" Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is READY nits: COMMENT A) """ 2.1. Rules The following rules apply within the Nickname profile of the PRECIS FreeformClass. """ I might be helpful to add the reference to RFC7564 after the FreeformClass as you did in section 2.2. Another way could also to assume in the introduction the reader is familiar with RFC7564. I also agree RFC7564 is mentioned in the terminology section. COMMENT B) """ 4. Normalization Rule: Apply Unicode Normalization Form KC. Because """ Two unexpected white spaces. Can be fixed by rfc-editor COMMENT C) """ 6. Security Considerations 6.3. Visually Similar Characters """ Maybe a reference to the example section with the names 5/7 or 6/7 can illustrate that the current profile does not prevent visually similar characters. --001a1142c5b2f3ff37055189f78c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I have reviewed this document as part of t= he security directorate's
ongoing effort to review all IETF documen= ts being processed by the
IESG.=C2=A0 These comments were written prima= rily for the benefit of the
security area directors.=C2=A0 Document edi= tors and WG chairs should treat
these comments just like any other last= call comments.

The summary of the review is READY


nits:<= br>
COMMENT A)

"""
2.1.=C2=A0 Rules

=C2= =A0=C2=A0 The following rules apply within the Nickname profile of the PREC= IS
=C2=A0=C2=A0 FreeformClass.
"""

I might be h= elpful to add the reference to RFC7564 after the FreeformClass as you did i= n section 2.2. Another way could also to assume in the introduction the rea= der is familiar with RFC7564. I also agree RFC7564 is mentioned in the term= inology section.
=C2=A0=C2=A0
COMMENT B)

"&= quot;" =C2=A0
=C2=A04.=C2=A0 Normalization Rule: Apply = Unicode Normalization Form KC.=C2=A0 Because
"""

T= wo unexpected white spaces. Can be fixed by rfc-editor

COMMENT C)
"""
6.=C2=A0 Security Considerations

6.3.=C2= =A0 Visually Similar Characters
"""

Maybe a refere= nce to the example section with the names 5/7 or 6/7 can illustrate that th= e current profile does not prevent visually similar characters.


= =C2=A0
=C2=A0
--001a1142c5b2f3ff37055189f78c-- From nobody Fri Jun 9 13:08: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 956EE1200CF for ; Fri, 9 Jun 2017 13:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=filament-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWwHnqTxraVB for ; Fri, 9 Jun 2017 13:08:38 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 1869212932A for ; Fri, 9 Jun 2017 13:08:36 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id i7so37540136ioe.1 for ; Fri, 09 Jun 2017 13:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filament-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=9HvC4zoZjjCW7swGiiBuvn8fAzM3+p1Mb/KhWWz+Iaw=; b=tKaOjBAVN1LDb05U09yhTVQMXd125PM2uXLaDz0Y2xhn4ChdolldlfHIRz9oneycW+ X8rMr4hAm6MqfYr7mVIWtWy9zS/Tj3OmeqFmjT7zMdG0QjG8TPHCyX9TOqugX3rGGYTZ wdbs+MaYbEpUYdVXUqeEk48mOss8LgrS/QBxbw5lzvNtL2tQqWGLilXocgmnayUpkAtr fup/rvkthMVHoTFrOXk6/3yFnNj1CRz1f1jAK5qiQLosMZlUKBx4eZM5bv7Rm6Xvyx6l vO+/iwyp0JSFAeabz6IDCYw4/YiHZ9pc0dXVKfB1Td+QSi0PrdX957loQhAq8GzYrqKj QEVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=9HvC4zoZjjCW7swGiiBuvn8fAzM3+p1Mb/KhWWz+Iaw=; b=ZAwJI7MPK9BZ+qeQSw9IyGAdAYD+TyYQXQG73VscQobkqPR6SYjGqJAadL9lfcBctl DGy7npa9Ry5+DepbXD2mcbP5vLFo5XWD6qYRPRhx/efzC3QNCXA6xV7XKJOuLURZ2hRH 7Q0NpMkNPL3aMPJ2AmLy+Kc+NoArhfh9eKwIJEyU1ya3YV1RZnylSIIVXmjv9y2qkS5R 2FbWh2PLY4yVX9UTC30vk2LhgC7ZHl55v/4OTobJOGvKrp2/3IHEd/LOIPnovWBjCYK8 wv5AMnxnZfaQCgg2qreZOeDw4CSzU0MNX9a1KV+vglqTIZvlMEx5XZBTS0e5kWcFEQvn JIhw== X-Gm-Message-State: AKS2vOy5RChjqWN+MX30OEKYu8++mtDQIhLyqK4zKXKcoxp6hrXVkttd 5RzC2JQPa6vOuFuV X-Received: by 10.107.149.193 with SMTP id x184mr15142637iod.104.1497038915276; Fri, 09 Jun 2017 13:08:35 -0700 (PDT) Received: from aither.local ([2601:282:4202:67d3:505f:11e5:e014:8ed5]) by smtp.gmail.com with ESMTPSA id e32sm309607itd.18.2017.06.09.13.08.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jun 2017 13:08:34 -0700 (PDT) To: Daniel Migault , secdir@ietf.org References: Cc: The IESG , draft-ietf-precis-7700bis.all@ietf.org From: Peter Saint-Andre - Filament Message-ID: Date: Fri, 9 Jun 2017 14:08:33 -0600 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 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-precis-7700bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 20:08:40 -0000 Hi Daniel, thanks for the review. Comments inline. On 6/9/17 11:04 AM, Daniel Migault wrote: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The summary of the review is READY > > > nits: > > COMMENT A) > > """ > 2.1. Rules > > The following rules apply within the Nickname profile of the PRECIS > FreeformClass. > """ > > I might be helpful to add the reference to RFC7564 after the > FreeformClass as you did in section 2.2. Another way could also to > assume in the introduction the reader is familiar with RFC7564. I also > agree RFC7564 is mentioned in the terminology section. It can't hurt to reference RFC 7564 here, too. > COMMENT B) > > """ > 4. Normalization Rule: Apply Unicode Normalization Form KC. Because > """ > > Two unexpected white spaces. Can be fixed by rfc-editor > > COMMENT C) > > """ > 6. Security Considerations > > 6.3. Visually Similar Characters > """ > > Maybe a reference to the example section with the names 5/7 or 6/7 can > illustrate that the current profile does not prevent visually similar > characters. Well, those characters aren't visually similar. Section 12.5 of rfc7546bis talks about this in detail; although it does provide some examples, it might help to add more (e.g., CYRILLIC SMALL LETTER A U+0430 vs. LATIN SMALL LETTER A U+0061). Peter -- Peter Saint-Andre https://filament.com/ +1-720-256-6756 From nobody Fri Jun 9 18:10: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 2E1EA126D45; Fri, 9 Jun 2017 18:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YC34FwNOIJQZ; Fri, 9 Jun 2017 18:10:09 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.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 E4408126C7A; Fri, 9 Jun 2017 18:10:08 -0700 (PDT) X-AuditID: c618062d-8e0d79a00000248b-d8-593b5b4bf22a Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 30.42.09355.B4B5B395; Sat, 10 Jun 2017 04:36:59 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0339.000; Fri, 9 Jun 2017 21:10:10 -0400 From: Daniel Migault To: Peter Saint-Andre - Filament , "secdir@ietf.org" CC: The IESG , "draft-ietf-precis-7700bis.all@ietf.org" Thread-Topic: secdir review of draft-ietf-precis-7700bis-07 Thread-Index: AQHS4VwyiWaohRdhIkiPYG6BT46q/KIc/Wcw Date: Sat, 10 Jun 2017 01:10:10 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118C731CD@eusaamb107.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXRPgq53tHWkwdfZ+hb7PzazWsz4M5HZ YvaZYIsPCx+yOLB4XNo0m91jyZKfTAFMUVw2Kak5mWWpRfp2CVwZ597/YS84JVOx5/Q/5gbG N9JdjJwcEgImErsnLmTtYuTiEBI4yiix/HcPI4SzjFHiztId7CBVbAJGEm2H+sFsEYEYiRUv l7CA2MwChRJrT28As4UFrCTOXW9jg6ixlvj5/hhQPQeQbSSxYEssSJhFQFViy8kWsHJeAV+J C8uvskPsamOUWHy0EWw+p4CDxJ6191lBbEYBMYnvp9YwQewSl7j1ZD4TxNUCEkv2nGeGsEUl Xj7+xwphK0l8/D0fbC+zgKbE+l36EK2KElO6H7JD7BWUODnzCcsERtFZSKbOQuiYhaRjFpKO BYwsqxg5SosLcnLTjQw2MQKj45gEm+4OxvvTPQ8xCnAwKvHwtgVaRwqxJpYVV+YeYpTgYFYS 4dWxAQrxpiRWVqUW5ccXleakFh9ilOZgURLnnXD+QoSQQHpiSWp2ampBahFMlomDU6qBUdt/ f0Dq3o7jJaucGifOnLq/6cQv/QnbEqWfNUwVFLaJ7ag54nHwyZ1HvR69TTKfzj9z7F/fuajl Y8+0qfuP1rX/+vWzZmZCpGpw+94dz6RrGPeXeZTvjuYs4GJPvbosZOILkc0bZvMnnTWsL2Hc fay858D5I13Pj17IYTp/08bbsFMu9kuUlRJLcUaioRZzUXEiADHn6mKKAgAA Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-precis-7700bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 01:10:11 -0000 VGhhbmtzIGZvciB0aGUgcmVzcG9uc2UuIEl0IGFkZHJlc3NlcyBteSBjb21tZW50LiAgDQoNCk15 IGNvbW1lbnQgd2FzIG1vdGl2YXRlZCBieSByZS11c2luZyBhbiBleGFtcGxlIGRldmVsb3BlZCBp biB0aGUgZG9jdW1lbnQgdG8gaWxsdXN0cmF0ZSB0aGF0IG1hcHBpbmcgcnVsZXMgbmVlZHMgdG8g YmUgY29vcmRpbmF0ZWQgd2l0aCB0aGUgb3RoZXIgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuIEhv d2V2ZXIsIGZvciBzb21lIHJlYXNvbnMsIEkgbWlzc2VkIHRoYXQgdGhlIGNhcGl0YWwgbGV0dGVy IG9mIEdSRUVLIFNNQUxMIExFVFRFUiBGSU5BTCBTSUdNQSBhbmQgR1JFRUsgU01BTEwgTEVUVEVS IFNJR01BIGFyZSAic2ltaWxhciIgYmVjYXVzZSBpdCBpcyB0aGUgc2FtZSBVbmljb2RlIGNoYXJh Y3Rlci4gSSBhcG9sb2d5IGZvciB0aGUgY29uZnVzaW9uLg0KDQpJIGFncmVlIHdpdGggeW91IHRo YXQgdGhlIENZUklMTElDIFNNQUxMIExFVFRFUiBBIHZzLiBMQVRJTiBTTUFMTCBMRVRURVIgQSAg ZXhhbXBsZSBpcyBub3QgbmVlZGVkLiANCg0KVGhhbmtzIGZvciB0aGUgcmVzcG9uc2UhDQoNCllv dXJzLCANCg0KRGFuaWVsDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUGV0ZXIg U2FpbnQtQW5kcmUgLSBGaWxhbWVudCBbbWFpbHRvOnBldGVyQGZpbGFtZW50LmNvbV0gDQpTZW50 OiBGcmlkYXksIEp1bmUgMDksIDIwMTcgNDowOSBQTQ0KVG86IERhbmllbCBNaWdhdWx0IDxkYW5p ZWwubWlnYXVsdEBlcmljc3Nvbi5jb20+OyBzZWNkaXJAaWV0Zi5vcmcNCkNjOiBUaGUgSUVTRyA8 aWVzZ0BpZXRmLm9yZz47IGRyYWZ0LWlldGYtcHJlY2lzLTc3MDBiaXMuYWxsQGlldGYub3JnDQpT dWJqZWN0OiBSZTogc2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLXByZWNpcy03NzAwYmlzLTA3 DQoNCkhpIERhbmllbCwgdGhhbmtzIGZvciB0aGUgcmV2aWV3LiBDb21tZW50cyBpbmxpbmUuDQoN Ck9uIDYvOS8xNyAxMTowNCBBTSwgRGFuaWVsIE1pZ2F1bHQgd3JvdGU6DQo+IEhpLA0KPiANCj4g SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGly ZWN0b3JhdGUncyANCj4gb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50 cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIA0KPiBJRVNHLiAgVGhlc2UgY29tbWVudHMgd2VyZSB3 cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIA0KPiBzZWN1cml0eSBhcmVh IGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQg DQo+IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRz Lg0KPiANCj4gVGhlIHN1bW1hcnkgb2YgdGhlIHJldmlldyBpcyBSRUFEWQ0KPiANCj4gDQo+IG5p dHM6DQo+IA0KPiBDT01NRU5UIEEpDQo+IA0KPiAiIiINCj4gMi4xLiAgUnVsZXMNCj4gDQo+ICAg IFRoZSBmb2xsb3dpbmcgcnVsZXMgYXBwbHkgd2l0aGluIHRoZSBOaWNrbmFtZSBwcm9maWxlIG9m IHRoZSBQUkVDSVMNCj4gICAgRnJlZWZvcm1DbGFzcy4NCj4gIiIiDQo+IA0KPiBJIG1pZ2h0IGJl IGhlbHBmdWwgdG8gYWRkIHRoZSByZWZlcmVuY2UgdG8gUkZDNzU2NCBhZnRlciB0aGUgDQo+IEZy ZWVmb3JtQ2xhc3MgYXMgeW91IGRpZCBpbiBzZWN0aW9uIDIuMi4gQW5vdGhlciB3YXkgY291bGQg YWxzbyB0byANCj4gYXNzdW1lIGluIHRoZSBpbnRyb2R1Y3Rpb24gdGhlIHJlYWRlciBpcyBmYW1p bGlhciB3aXRoIFJGQzc1NjQuIEkgYWxzbyANCj4gYWdyZWUgUkZDNzU2NCBpcyBtZW50aW9uZWQg aW4gdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24uDQoNCkl0IGNhbid0IGh1cnQgdG8gcmVmZXJlbmNl IFJGQyA3NTY0IGhlcmUsIHRvby4NCg0KPiBDT01NRU5UIEIpDQo+IA0KPiAiIiIgIA0KPiAgNC4g IE5vcm1hbGl6YXRpb24gUnVsZTogQXBwbHkgVW5pY29kZSBOb3JtYWxpemF0aW9uIEZvcm0gS0Mu ICBCZWNhdXNlIA0KPiAiIiINCj4gDQo+IFR3byB1bmV4cGVjdGVkIHdoaXRlIHNwYWNlcy4gQ2Fu IGJlIGZpeGVkIGJ5IHJmYy1lZGl0b3INCj4gDQo+IENPTU1FTlQgQykNCj4gDQo+ICIiIg0KPiA2 LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCj4gDQo+IDYuMy4gIFZpc3VhbGx5IFNpbWlsYXIg Q2hhcmFjdGVycw0KPiAiIiINCj4gDQo+IE1heWJlIGEgcmVmZXJlbmNlIHRvIHRoZSBleGFtcGxl IHNlY3Rpb24gd2l0aCB0aGUgbmFtZXMgNS83IG9yIDYvNyBjYW4gDQo+IGlsbHVzdHJhdGUgdGhh dCB0aGUgY3VycmVudCBwcm9maWxlIGRvZXMgbm90IHByZXZlbnQgdmlzdWFsbHkgc2ltaWxhciAN Cj4gY2hhcmFjdGVycy4NCg0KV2VsbCwgdGhvc2UgY2hhcmFjdGVycyBhcmVuJ3QgdmlzdWFsbHkg c2ltaWxhci4gU2VjdGlvbiAxMi41IG9mIHJmYzc1NDZiaXMgdGFsa3MgYWJvdXQgdGhpcyBpbiBk ZXRhaWw7IGFsdGhvdWdoIGl0IGRvZXMgcHJvdmlkZSBzb21lIGV4YW1wbGVzLCBpdCBtaWdodCBo ZWxwIHRvIGFkZCBtb3JlIChlLmcuLCBDWVJJTExJQyBTTUFMTCBMRVRURVIgQQ0KVSswNDMwIHZz LiBMQVRJTiBTTUFMTCBMRVRURVIgQSBVKzAwNjEpLg0KDQpQZXRlcg0KDQotLQ0KUGV0ZXIgU2Fp bnQtQW5kcmUNCmh0dHBzOi8vZmlsYW1lbnQuY29tLw0KKzEtNzIwLTI1Ni02NzU2DQo= From nobody Fri Jun 9 21:26: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 30651124D85 for ; Fri, 9 Jun 2017 21:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 GiXWN3FtyHmj for ; Fri, 9 Jun 2017 21:26:37 -0700 (PDT) Received: from nm10-vm5.access.bullet.mail.gq1.yahoo.com (nm10-vm5.access.bullet.mail.gq1.yahoo.com [216.39.63.128]) (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 0644C127201 for ; Fri, 9 Jun 2017 21:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1497068796; bh=cH7vtDViK57/mXQ7To/TjGIFKA4d1kLnHuLOYvAP0Wo=; h=From:Subject:To:Date:From:Subject; b=Wj1+VHQTyr+r4ThLvthqQ2uJgwzHqsSV7ymQfknwkvavABhZfGnlpZLz/gx0VJoAY00o7ZNoHZEXL2P1cSs7LRC9ICpqNpFSWPtkSp0i+fvNmNhSxxEZvOPZQZspFO5HwgGRIOTafPaPBlibbF2Jtr/PPjkXcAoWITDTD9TqtjhZiDU0SF0B0ikj7E8JsZVRPim8W+5AyFuWUuUz4k35WGCrOXCEksGXS4X/NEybIvRYiU5PAA9JIYjTU/6/dU8JZn7UWLRPvkP+8pDe1umExHsADB6bhBBW8a2MjXsQpS+XlkIztKQW8G7F03G91MmcGFNIupVjaQ188S6Kn+tfAQ== Received: from [216.39.60.172] by nm10.access.bullet.mail.gq1.yahoo.com with NNFMP; 10 Jun 2017 04:26:36 -0000 Received: from [98.138.104.97] by tm8.access.bullet.mail.gq1.yahoo.com with NNFMP; 10 Jun 2017 04:26:36 -0000 Received: from [127.0.0.1] by smtp117.sbc.mail.ne1.yahoo.com with NNFMP; 10 Jun 2017 04:26:36 -0000 X-Yahoo-Newman-Id: 183491.25595.bm@smtp117.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: CrWy.vAVM1kKuAGhseym8CBRbqKchdpnJbXYqnqRH27RGP1 ZWEQ5QJwm0nlOgtEZ0HzUy_ilqHfHNH_YquQLQfK8OzQR46n4bvh.K7J7jKC V5KcldYAzxhdp9vye7jbnSKchmLUtcEs25irFT1YpbOEUl7lrI3s8slthR3u 3sQA7l3KpOlWdoPQtjdBKupdKrQlR4Rx3NqOJx6KtPdclSmMHgOUFWlAQlq5 gX1WGRVDbGtrHU8Fz60F6HW9428CoRF4vPoa8cnFlqhqH.4UBuw4uXPl46Pf ylfRsRyw.au66XhHiQhjQQPwsQjS5f1Yg.uk0OXuTGm1H5ekp3ghyOCn_NpM rKz.VA._8YSSP58i_7zoGZ.B_pTkRcG3KtmpGffaCXMrpV4wNZuiAXFev8S. KMFDxmB.9in.ZS741rA1AMlWoR0PkmBuVmnNTlXoiFt0tX1EAwqpIn9lX8xY rVhZL4VsN04.qqijjNCVVKI0ntaQU2amB2gLIpI2Q9UGZHjcRs0Z_UnTwZU0 Zb88XJKGh39Rr6..7s.8qeqRFgPIVpgdrv4Ddkw0- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 46F841C602E; Sat, 10 Jun 2017 00:26:35 -0400 (EDT) From: David Mandelberg To: iesg@ietf.org, secdir@ietf.org, draft-baeuerle-netnews-cancel-lock.all@ietf.org Message-ID: <79785418-2159-2dba-3beb-b9391a5a2ddf@mandelberg.org> Date: Sat, 10 Jun 2017 00:26:31 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WWs76wWj7dFgOxsHagClOqQD1w8jFAm0a" Archived-At: Subject: [secdir] secdir review of draft-baeuerle-netnews-cancel-lock-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: Sat, 10 Jun 2017 04:26:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WWs76wWj7dFgOxsHagClOqQD1w8jFAm0a Content-Type: multipart/mixed; boundary="Iofuau1pFdEWsfGulJDQJwrrF3fj8XTmI"; protected-headers="v1" From: David Mandelberg To: iesg@ietf.org, secdir@ietf.org, draft-baeuerle-netnews-cancel-lock.all@ietf.org Message-ID: <79785418-2159-2dba-3beb-b9391a5a2ddf@mandelberg.org> Subject: secdir review of draft-baeuerle-netnews-cancel-lock-05 --Iofuau1pFdEWsfGulJDQJwrrF3fj8XTmI Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Not ready. The authentication in this document is single-use per article. I.e., once a single supersede or cancel is issued for an article, anybody can "forge" other valid supersedes or cancels for the same article. I assume that a cancel followed by a forged cancel is unimportant, but what about cancel->supersede, supersede->cancel, or supersede->supersede? Also, what about the race condition if the attacker can propagate the forgery faster than the original propagates? This document recommends calculating a single key K for each article (section 4), then publishing base64(hash(base64(K))) values for multiple different hash algorithms. This means that the preimage resistance of the weakest hash algorithm places an upper bound on the security of the authentication, even if the receiver ignores weaker algorithms. (An attacker who can calculate K from the weak hash can generate valid keys for the stronger hashes.) Additionally, while plenty of research goes into preimage security of individual hash algorithms, I don't think as much research goes into preimage security of multiple algorithms used in parallel on the same input. While I don't know of any non-brute-force attacks that can find X given sha256(X) and sha512(X), I see no reason that it wouldn't be easier than the easiest of the two individual preimage attacks. (I am not an expert though, there might be something I'm missing.) Section 4: Is it ever possible for two different (uid, mid) pairs to have the same concatenated value? E.g., alice@example.co + mfoo and alice@example.com + foo. If that ever happened and one of the two articles was canceled, an attacker would be able to cancel the other article. Section 4: I don't understand Q1. Are you asking me if the existing implementations are doing something insecure? (It's not specified well enough for me to tell.) Section 4: I think you should run any user-supplied password through a key derivation function before using it as a MAC key. Section 7: As I understand the terms, you care about preimage resistance, but not second preimage. (I think preimage covers finding any input that results in the specified output, not only the input that originally generated the specified output. But I might be misunderstanding the terms.) Section 7: I don't know where the minimum key sizes come from, but they seem a bit low to me. And for Q2, I don't know, sorry. --=20 David Eric Mandelberg / dseomn http://david.mandelberg.org/ --Iofuau1pFdEWsfGulJDQJwrrF3fj8XTmI-- --WWs76wWj7dFgOxsHagClOqQD1w8jFAm0a Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlk7dPcACgkQRKlmUHCg4sCp7wCfZbQLF6Fy84rnUEdP0W0c5nkx 6XsAoJsLDtsBQpABDSzycNYU8L1FGdy6 =s51B -----END PGP SIGNATURE----- --WWs76wWj7dFgOxsHagClOqQD1w8jFAm0a-- From nobody Sun Jun 11 21:22: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 6DC86129BA5; Sun, 11 Jun 2017 21:22:38 -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 ym7_5yncwqvo; Sun, 11 Jun 2017 21:22:37 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 0C669126CD6; Sun, 11 Jun 2017 21:22:37 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id c10so113377653qtd.1; Sun, 11 Jun 2017 21:22:37 -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=eTn4qLcmnrwe5+OV1XgBHJ2w6tZxLkzGQ1hjGOs3sH4=; b=gJ67h/Dk1uSs1FtnytORtl8EpehmGs5f1FDhM9VK14BR4CZVg44I1ncteiRDAVafI2 oiNRfLzNICA9i0cfhjyy638QpoX/UYtcD5cx0ndJvkEj6PyVa+/AlIRSG5UUJFKWiZul bK5hFgh0ugjAPBW7f95KpRvAeAEeS1FjjkJBY3Y1RvoFU3fi2ni/TjlDRc4VJjB3f61S jnxWUNK9WkRk3HOPLVCP6PIChm7P2zBvkhl2rcvLbubHfabAPrwtfRijqCJVqpDTss+c D5f1bAPVgWxXKmZYplENNNoI9IXRi7rqs8bcrHezU/DMolWcBtAMxFxjmuOVwf2NhSwW XFmg== 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=eTn4qLcmnrwe5+OV1XgBHJ2w6tZxLkzGQ1hjGOs3sH4=; b=r/sL9Ir8NdRW9eIqjDU4jHk9UxjYcD6jly+Q7QI87yarPIm+gaMOlBAniV8I4QnxDW Q3J3R8+JwclWkn8ULA4GgjP4/KxQfIQr7q6Sy1if+E2+rVHdcnDnoz1SeiNHLweSj0/R SuadOST/XL7mzmIcluIKg3dqFsS+KUUO3bMjkKKG69LwUbJRzXt03+EMAxBjXIHfAEbV eaC8IgM7xds/UhbxJnQgz2VsPQRfOmyHjH2K4NTyvOoqXqEVdPn0IVO0CMcS25Ucu6wW 0ZfhMHCYhNo+eil8e2GcRRVdfdDtd+PiCVupmUp5IVe2N6XrN9TSHiZfw6mrhxCloeFw r1uQ== X-Gm-Message-State: AODbwcDUoS+L1AG0MeoVRAIBTfwJe9ekrvcH5J7G3PKKqiZizod4dBnU 42Q0vtij8qIteYi3FaztfFLcnRI8zg== X-Received: by 10.200.46.50 with SMTP id r47mr48524463qta.209.1497241356154; Sun, 11 Jun 2017 21:22:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.41.230 with HTTP; Sun, 11 Jun 2017 21:22:35 -0700 (PDT) From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Date: Sun, 11 Jun 2017 21:22:35 -0700 Message-ID: To: "secdir@ietf.org" , draft-ietf-dnsop-sutld-ps@ietf.org Content-Type: multipart/alternative; boundary="001a1137b0f62d3d0f0551bbabe3" Archived-At: Subject: [secdir] Secdir review of draft-ietf-dnsop-sutld-ps-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, 12 Jun 2017 04:22:38 -0000 --001a1137b0f62d3d0f0551bbabe3 Content-Type: text/plain; charset="UTF-8" I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes experiences from allocations of special-use top-level domain names. As such, it does not contain any new security considerations beyond what's already discussed in underlying RFCs. The security considerations section also reflects this. I have no concerns with this document. Thanks, -- Magnus --001a1137b0f62d3d0f0551bbabe3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed this document a= s part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

This document describes experiences from allocations of special-use top-lev= el domain names.
As such, it does not contain any new security considera= tions beyond what's already discussed in underlying RFCs. The security = considerations section also reflects this. I have no concerns with this doc= ument.

Thanks,
-- Magnus
--001a1137b0f62d3d0f0551bbabe3-- From nobody Mon Jun 12 15:51: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 96133127241 for ; Mon, 12 Jun 2017 15:51:04 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeOEiJqzqRgH for ; Mon, 12 Jun 2017 15:51:02 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 0AE48128DF3 for ; Mon, 12 Jun 2017 15:51:01 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id l89so57662662pfi.2 for ; Mon, 12 Jun 2017 15:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SNc0nsSFiBWkvI/KKAPU4U82JJStmFsoxB/q9vKPKlI=; b=gzcgp7iwrRReUGlZUxLAP7fIzckLihpLt+l1R2KHUl/MSIcr0ORH96vWfDoWoZ5g33 o+4VA0FuzO8sI5nyXB+95W325BfN0FzylysY1TtMHpTIeDrsmJr4AwXaCnq0iV9K/sgA KsBb4oQzUJBAqDpZ+90Hh89KOPq7xScGI/AK5AukAoNunbwWTsUEO3FcIiCwFqsQjpxd e0iGbR3LXrHCPKiSr4XGQuEFJqaPI89oJTb7/p+tFz8tAU6+LBIrhpbM3C9TYf2h+gay vxGG3xmne/gMYns+maLnvici6wDrxF5fa0vzxtzb2MkVt4fCatzLfaJ6TG5zLdONmHdw q+yw== 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=SNc0nsSFiBWkvI/KKAPU4U82JJStmFsoxB/q9vKPKlI=; b=c180eVIHmv01nFg28OQPOddths3VM6JzZiLTBWsvPEOskgxAGuXu4Lns1Hr3jUFbpy nYW42fCeZAqqLYpXuldPIqOtq8YSrDL5FBS/BNL26IwAAUcRXTAIz+F/2K7wOC25hVE6 JX0AyLWQVZdx81amrHCTE880CTwqKsOwaP4zVlA5BWnEGvEeqmqA+DxLu3ADZeJg3T+3 nC8rT5IK2RlKWo20f0hTE/HSohb7X8AxdL6SiqwAMkU/uMiEeFafFj+PQ0/f5Npu+QAh pfSk9nTmn3esnKZ/kTXg4KmoXAN8Vogd/6jH5jU4mg1JNp8yjwNJv0hrWk5eYn9Qc5AS jFgQ== X-Gm-Message-State: AODbwcD+4hOqjxtyrSXjdCyEgpTrlZCfz158VwABjgXqL05CkEQ0eVPD 05++t4+B/PtPL0KDKOhy1a80uzZsvYYp X-Received: by 10.84.225.2 with SMTP id t2mr59001841plj.108.1497307861201; Mon, 12 Jun 2017 15:51:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.168.5 with HTTP; Mon, 12 Jun 2017 15:50:40 -0700 (PDT) In-Reply-To: References: From: Lucien Avramov Date: Mon, 12 Jun 2017 15:50:40 -0700 Message-ID: To: Adam Montville Cc: draft-ietf-bmwg-dcbench-terminology.all@ietf.org, "secdir@ietf.org" , The IESG Content-Type: multipart/alternative; boundary="f403045eb7022ff7b10551cb2746" Archived-At: Subject: Re: [secdir] SECDIR Review of: draft-ietf-bmwg-dcbench-terminology 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, 12 Jun 2017 22:51:04 -0000 --f403045eb7022ff7b10551cb2746 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Adam, Just wanted to check in with you, to see if you accept the way I addressed your comments. Thanks in advance! Lucien On Thu, Jun 8, 2017 at 10:10 PM, Lucien Avramov wrote= : > Hi Adam! > > Many thanks for the review! I addressed your comments and published -10 o= f > the draft (draft-ietf-bmwg-dcbench-terminology-10). > > Please see inline for some comments. > > Thanks a lot for the detail feedback! > > Lucien > > On Mon, Jun 5, 2017 at 10:32 AM, Adam Montville < > adam.w.montville@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. >> These comments were written primarily for the benefit of the security ar= ea >> directors. Document editors and WG chairs should treat these comments ju= st >> like any other last call comments. >> >> Bottom Line: Almost Ready >> >> About Security Considerations >> For your security considerations phrases like "are limited to" and "will >> be", and I would suggest that these are your MUSTs or SHOULDs. Given the >> "MUST NOT" you have in the second paragraph, it seems that "MUST" should= be >> used instead of "SHOULD". In that sense, then, I would suggest the >> following statements be updated: 1) "Benchmarking activities as describe= d >> in this memo MUST be limited to technology characterization using >> controlled stimuli...", "The benchmarking network topology MUST be an >> independent test setup..." >> >> That said, you might consider softening the "MUST NOT" and consequent >> "MUST" statements to "SHOULD NOT" and "SHOULD", respectively. This becau= se >> there may well be circumstances where testing in a production environmen= t >> is necessary. >> >> >> *These are the standard security considerations all BMWG uses for all th= e > drafts. We want to stay with the considerations we chose. * > > >> About Rest of Draft >> The draft describes well-understood concepts of FILO, FIFO, LILO, and >> LIFO. It then goes on to recast these definitions as "first bit last bit= " >> (or "FL"), and "last bit last bit" (or "LL"), and so on. However, the dr= aft >> does not really make use of these alternate expressions for the >> aforementioned well-understood concepts. I recommend picking one of thes= e >> representations and using it consistently throughout; moreover, I recomm= end >> sticking with FILO, FIFO, LILO, and LIFO. >> > > *We do want to stay with FILO, FIFO, LILO and LIFO. The FL, LL, etc were > added as this was sometimes referred to as, not to as FL, LL, etc.* > > >> >> There's a sentence in 2.2 which reads, "Data Center DUTs are frequently >> store-and-forward for smaller packet sizes and then adopting a cut-throu= gh >> behavior." This feels incomplete. When does it adopt cut-through behavio= r? >> Is that adopted for larger packet sizes? Is it worthwhile to talk at all >> about the change threshold? >> > > *I addressed your comment by updating the text in the publication to stat= e > that the threshold change is not matter, what matters is that the test FI= LO > is key, in order to catch these differences of behaviors. * > > > >> >> Section 1.2 describes the generally expected definition format. However, >> section 2 seems to immediately depart from that to some degree by placin= g >> terms as top-level sections (i.e. "2. Latency") with children for >> definition, discussion, and measurement units. To compound this confusio= n, >> section 6 further departs from the expectation set in 1.2 by using the >> top-level section as a grouping construct for "Buffering" (without defin= ing >> "Buffering"). Buffering has two children which are "buffer" and "incast"= . >> Buffer, itself is never defined, but instead has a "definition" subsecti= on >> consisting of many other terms. The same sort of thing happens with "6.= 2 >> Incast". Please pick a format and make clear what things are terms, and >> which are not terms. Then rewrite section 1.2, so that it more properly >> describes what the reader should expect. >> > > *This is just nesting of the format, Incast is a sub of Buffering. We can > change them to top level with Buffering =E2=80=93 Buffer and Buffering = =E2=80=93 Incast, > however we find that less readable for the user and want to keep the > current display/text the way it is.* > > >> >> There are, at several locations, uses of the capitalized word "CAN" in a >> way that suggests normative-type intent. "CAN" does not seem to be an >> RFC2119 keyword. In one case, it seems that "CAN" may actually mean a lo= wer >> case "may" or "can" (see 6.1.1 on page 12). >> > > > *This is fixed, thank you!* > > >> Nits >> Throughout the draft sometimes terms are capitalized, sometimes they are >> not. I believe they should more often not be capitalized, but if they ar= e, >> do so consistently. >> >> Generally speaking (this may be stylistic) the first word after a colon >> (':') should be capitalized. Example: This is. >> > > *This is fixed, thank you!* > >> >> Find acronyms/initializations and ensure they're expanded at least on th= e >> first occurrence (i.e. "PDV" on page 6) >> > > Thanks! > >> >> In the abstract s/as it is to/as to/ >> >> *This is fixed, thank you!* > > >> In 2.1 s/in unit of/in units of/ and s/store forward/store and forward/ >> > > *This is fixed, thank you!* > >> >> In 2.3 s/follow:/follows:/ >> > *This is fixed, thank you!* > >> >> In 2.3, item 2: Is "proceed data" a common term? >> > *This is fixed, thank you!* > >> >> In 4.1 s/test on/tests on/ >> > *This is fixed, thank you!* > >> >> In 4.3 s/of :/of:/ >> > *This is fixed, thank you!* > >> >> In 4.3 s/[4.1s]/section 4.1/ >> > *This is fixed, thank you!* > >> >> In 5.3, if "CAN" is changed to "can", then s/line rate can measured/line >> rate can be measured/ >> > > *This is fixed, thank you!* > > >> In 6.1.1 s/expressed in Byte;/B (bytes),/ or s/expressed in Byte;/Bytes,= / >> > *This is fixed, thank you!* > > >> >> In 6.1.1 s/amount of buffer a single/amount of buffer for a single/ >> > *This is fixed, thank you!* > > >> >> In 6.1.1 recommend striking "it is a burst" >> > *This is fixed, thank you!* > > >> >> In 6.2.1 s/by synchronous/by synchronous arrival time/ >> > *This is fixed, thank you!* > > >> >> In 6.2.2 s/In a ingress/In an ingress/ >> > *This is fixed, thank you!* > > >> >> In 6.2.2 s/In either cases/In either case/ >> > *This is fixed, thank you!* > > >> >> In 6.2.3 s/non null/non-null/ >> > *This is fixed, thank you!* > > >> >> In 7.3 the first paragraph could be improved by simply writing, "When S >> represents the payload bytes, which does not include packet or TCP heade= rs, >> and Ft is the Finishing Time of the last sender, the Goodput, G, is then >> measured by the following formula..." >> > *This is fixed, thank you!* > > >> >> >> Kind regards, >> >> Adam >> >> >> > --f403045eb7022ff7b10551cb2746 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Adam,

Just wanted to check in with y= ou, to see if you accept the way I addressed your comments.

<= /div>
Thanks in advance!
Lucien

On Thu, Jun 8, 2017 at 10:10 PM, Lu= cien Avramov <lucienav@google.com> wrote:
Hi Adam!

Many thanks = for the review! I addressed your comments and published -10 of the draft (d= raft-ietf-bmwg-dcbench-terminology-10).=C2=A0

Please see inline for some comments.

Thanks a lot= for the detail feedback!

Lucien

On Mon, Ju= n 5, 2017 at 10:32 AM, Adam Montville <adam.w.montville@gmail.com= > wrote:
I have reviewed this document as part of the securit= y directorate's ongoing effort to review all IETF documents being proce= ssed by the IESG. These comments were written primarily for the benefit of = the security area directors. Document editors and WG chairs should treat th= ese comments just like any other last call comments.

Bottom Line: Almost Ready

About Security Consid= erations
For your security considerations phrases like "are = limited to" and "will be", and I would suggest that these ar= e your MUSTs or SHOULDs. Given the "MUST NOT" you have in the sec= ond paragraph, it seems that "MUST" should be used instead of &qu= ot;SHOULD". In that sense, then, I would suggest the following stateme= nts be updated: 1) "Benchmarking activities as described in this memo = MUST be limited to technology characterization using controlled stimuli...&= quot;, "The benchmarking network topology MUST be an independent test = setup..."

That said, you might consider softe= ning the "MUST NOT" and consequent "MUST" statements to= "SHOULD NOT" and "SHOULD", respectively. This because = there may well be circumstances where testing in a production environment i= s necessary.


<= div>These are the standard security considera= tions all BMWG uses for all the drafts. We want to stay with the considerat= ions we chose.=C2=A0
=C2=A0
About Rest of Draft
The draft describes well-understood concepts= of FILO, FIFO, LILO, and LIFO. It then goes on to recast these definitions= as "first bit last bit" (or "FL"), and "last bit = last bit" (or "LL"), and so on. However, the draft does not = really make use of these alternate expressions for the aforementioned well-= understood concepts. I recommend picking one of these representations and u= sing it consistently throughout; moreover, I recommend sticking with FILO, = FIFO, LILO, and LIFO.

We do want to stay with FILO, FIFO, LILO and LI= FO. The FL, LL, etc were added as this was sometimes referred to as, not to= as FL, LL, etc.
=C2=A0

The= re's a sentence in 2.2 which reads, "Data Center DUTs are frequent= ly store-and-forward for smaller packet sizes and then adopting a cut-throu= gh behavior." This feels incomplete. When does it adopt cut-through be= havior? Is that adopted for larger packet sizes? Is it worthwhile to talk a= t all about the change threshold?

I addressed your comment by updating the text in the publicati= on to state that the threshold change is not matter, what matters is that t= he test FILO is key, in order to catch these differences of behaviors.=C2= =A0

=C2=A0

S= ection 1.2 describes the generally expected definition format. However, sec= tion 2 seems to immediately depart from that to some degree by placing term= s as top-level sections (i.e. "2. Latency") with children for def= inition, discussion, and measurement units. To compound this confusion, sec= tion 6 further departs from the expectation set in 1.2 by using the top-lev= el section as a grouping construct for "Buffering" (without defin= ing "Buffering"). Buffering has two children which are "buff= er" and "incast". Buffer, itself is never defined, but inste= ad has a "definition" subsection =C2=A0consisting of many other t= erms. The same sort of thing happens with "6.2 Incast". Please pi= ck a format and make clear what things are terms, and which are not terms. = Then rewrite section 1.2, so that it more properly describes what the reade= r should expect.

This is just nesting of the format, Incast is a sub = of Buffering. We can change them to top level with Buffering =E2=80=93 Buff= er and Buffering =E2=80=93 Incast, however we find that less readable for t= he user and want to keep the current display/text the way it is.
<= span class=3D"">
=C2=A0

There are, at several location= s, uses of the capitalized word "CAN" in a way that suggests norm= ative-type intent. "CAN" does not seem to be an RFC2119 keyword. = In one case, it seems that "CAN" may actually mean a lower case &= quot;may" or "can" (see 6.1.1 on page 12).

=C2=A0
This is fixed, thank you!=
=C2=A0
Nits
Throughout the draft so= metimes terms are capitalized, sometimes they are not. I believe they shoul= d more often not be capitalized, but if they are, do so consistently.
=

Generally speaking (this may be stylistic) the first wo= rd after a colon (':') should be capitalized. Example: This is.

This= is fixed, thank you!

Find acronyms/initializatio= ns and ensure they're expanded at least on the first occurrence (i.e. &= quot;PDV" on page 6)

Thank= s!=C2=A0

In the abstract s/as it is to/as to/
This is fixed= , thank you!
=C2=A0
In 2.1 s/in unit of/in u= nits of/ and s/store forward/store and forward/

This is fixed, thank you!

In 2.3 s/follow:/follows:/
<= div>This is fixed, thank you!

<= /div>
In 2.3, item 2: Is "proceed data" a common term?
<= /div>
This is fixed, thank y= ou!

In 4.1 s/test on/tests on/
This is fixed, thank you!

In 4.3 s/of :/of:/
This is fixed, thank you!

In 4.= 3 s/[4.1s]/section 4.1/
This is fixed, thank you!

In 5.3, if "= ;CAN" is changed to "can", then s/line rate can measured/lin= e rate can be measured/

This is fixed, thank you!
=C2=A0
In 6.1.1 s/expressed in Byte;/B (bytes),/ or s/expressed in Byt= e;/Bytes,/
= This is fixed, thank you!
=C2=A0

I= n 6.1.1 s/amount of buffer a single/amount of buffer for a single/
This is fixed, than= k you!
=C2=A0

In 6.1.1 recommend s= triking "it is a burst"
This is fixed, thank you!
=C2=A0

In 6.2.1 s/by synchronou= s/by synchronous arrival time/
This is fixed, thank you!
=C2= =A0

In 6.2.2 s/In a ingress/In an= ingress/
This is fixed, thank you!
=C2=A0

=
In 6.2.2 s/In either cases/In either case/
This is fixed,= thank you!
=C2=A0

In 6.2.3 s/non = null/non-null/
This is fixed, thank you!
=C2=A0

In 7.3 the first paragraph co= uld be improved by simply writing, "When S represents the payload byte= s, which does not include packet or TCP headers, and Ft is the Finishing Ti= me of the last sender, the Goodput, G, is then measured by the following fo= rmula..."
This is fixed, thank you!
=C2=A0

<= /div>

Kind regards,

Adam
<= div>



--f403045eb7022ff7b10551cb2746-- From nobody Mon Jun 12 15:52:54 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 69434128DF3; Mon, 12 Jun 2017 15:52:47 -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, 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 KzWA6wrHrf-7; Mon, 12 Jun 2017 15:52:44 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 A7451127241; Mon, 12 Jun 2017 15:52:44 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id m47so28241430iti.0; Mon, 12 Jun 2017 15:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6WP2KDISxRGfY1TQ49VT1V/pn1zOf4Cwk9B0d710jJw=; b=BdoOMAbFzs/j4K4KBcveW6RCIvGjyCNu0AJ/KJpp0NDv0o3FIXu2y3/9P6lKuovFkP AUYlVPnJ1ZECcE1chug8+6xazp58JNrdqGQhThf06fhJy4iTUAYWNYREINKeLI4Mx5pO M0m2Pv500YTP28OleZcLn9lt+N6LLRS848W/OiMp2rYuvZOzgCdS/OVYkWm23eWYqw2+ MkHg68Qa972GI5Lscpf9+gGFCCGNiy12/ASJIXlGUEyUvahL7T/y4JSdwcCR+wwlAFxc VGkWOismt3WENUpWsm2tJ+gwdSWT27fdCxdEcUK3Fy8aDEKzFeWvsAgR09LXgAzLonUB jx2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6WP2KDISxRGfY1TQ49VT1V/pn1zOf4Cwk9B0d710jJw=; b=ln6SFE2DepDINO7l5ENR6gtpP0wepKoyndVsrw4oUmFyNrHpsjRCml6YMuoLLYMlEu FBXQTGgU/J0OBogSx+yB+xzWaeguKIZ+4kO+M3qLbT6Z0CCir69BmEZ8DnKzmvMul9AT f8YuHwTNW2byaL5dqGMPkF1R6DMz938yvdfbchegDBrCAbBI7j301SK2DvsTxR1ICTy9 fcpWm3G0EIzgGvaozQl8lDAgUDodicKoj3QsOjJNRnKO7QbtAdkjxkdW5XqOQOZ5i3Ju 78qXaTttbYgJW6QMoUz8ig8vPkX/tTT1DYQ8r42YBi6gaIU9LOeTOY3Ty6wQB4ywa4/s 3OVw== X-Gm-Message-State: AODbwcCYv7YYTPFs9okOpO8vKoxEA+YAIJOcLa6bnPjoeVcoibbjfqks b9sd4JnwQzZpQfo9yKdaKqo9meu/eA== X-Received: by 10.36.233.70 with SMTP id f67mr14126260ith.60.1497307963953; Mon, 12 Jun 2017 15:52:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adam Montville Date: Mon, 12 Jun 2017 22:52:33 +0000 Message-ID: To: Lucien Avramov Cc: draft-ietf-bmwg-dcbench-terminology.all@ietf.org, "secdir@ietf.org" , The IESG Content-Type: multipart/alternative; boundary="94eb2c0a89444fce520551cb2d7e" Archived-At: Subject: Re: [secdir] SECDIR Review of: draft-ietf-bmwg-dcbench-terminology 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, 12 Jun 2017 22:52:47 -0000 --94eb2c0a89444fce520551cb2d7e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, I accept. Sorry about that, and thanks for reaching out again to wrangle an answer from me. Adam On Mon, Jun 12, 2017 at 5:51 PM Lucien Avramov wrote: > Hi Adam, > > Just wanted to check in with you, to see if you accept the way I addresse= d > your comments. > > Thanks in advance! > Lucien > > On Thu, Jun 8, 2017 at 10:10 PM, Lucien Avramov > wrote: > >> Hi Adam! >> >> Many thanks for the review! I addressed your comments and published -10 >> of the draft (draft-ietf-bmwg-dcbench-terminology-10). >> >> Please see inline for some comments. >> >> Thanks a lot for the detail feedback! >> >> Lucien >> >> On Mon, Jun 5, 2017 at 10:32 AM, Adam Montville < >> adam.w.montville@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= . >>> These comments were written primarily for the benefit of the security a= rea >>> directors. Document editors and WG chairs should treat these comments j= ust >>> like any other last call comments. >>> >>> Bottom Line: Almost Ready >>> >>> About Security Considerations >>> For your security considerations phrases like "are limited to" and "wil= l >>> be", and I would suggest that these are your MUSTs or SHOULDs. Given th= e >>> "MUST NOT" you have in the second paragraph, it seems that "MUST" shoul= d be >>> used instead of "SHOULD". In that sense, then, I would suggest the >>> following statements be updated: 1) "Benchmarking activities as describ= ed >>> in this memo MUST be limited to technology characterization using >>> controlled stimuli...", "The benchmarking network topology MUST be an >>> independent test setup..." >>> >>> That said, you might consider softening the "MUST NOT" and consequent >>> "MUST" statements to "SHOULD NOT" and "SHOULD", respectively. This beca= use >>> there may well be circumstances where testing in a production environme= nt >>> is necessary. >>> >>> >>> *These are the standard security considerations all BMWG uses for all >> the drafts. We want to stay with the considerations we chose. * >> >> >>> About Rest of Draft >>> The draft describes well-understood concepts of FILO, FIFO, LILO, and >>> LIFO. It then goes on to recast these definitions as "first bit last bi= t" >>> (or "FL"), and "last bit last bit" (or "LL"), and so on. However, the d= raft >>> does not really make use of these alternate expressions for the >>> aforementioned well-understood concepts. I recommend picking one of the= se >>> representations and using it consistently throughout; moreover, I recom= mend >>> sticking with FILO, FIFO, LILO, and LIFO. >>> >> >> *We do want to stay with FILO, FIFO, LILO and LIFO. The FL, LL, etc were >> added as this was sometimes referred to as, not to as FL, LL, etc.* >> >> >>> >>> There's a sentence in 2.2 which reads, "Data Center DUTs are frequently >>> store-and-forward for smaller packet sizes and then adopting a cut-thro= ugh >>> behavior." This feels incomplete. When does it adopt cut-through behavi= or? >>> Is that adopted for larger packet sizes? Is it worthwhile to talk at al= l >>> about the change threshold? >>> >> >> *I addressed your comment by updating the text in the publication to >> state that the threshold change is not matter, what matters is that the >> test FILO is key, in order to catch these differences of behaviors. * >> >> >> >>> >>> Section 1.2 describes the generally expected definition format. However= , >>> section 2 seems to immediately depart from that to some degree by placi= ng >>> terms as top-level sections (i.e. "2. Latency") with children for >>> definition, discussion, and measurement units. To compound this confusi= on, >>> section 6 further departs from the expectation set in 1.2 by using the >>> top-level section as a grouping construct for "Buffering" (without defi= ning >>> "Buffering"). Buffering has two children which are "buffer" and "incast= ". >>> Buffer, itself is never defined, but instead has a "definition" subsect= ion >>> consisting of many other terms. The same sort of thing happens with "6= .2 >>> Incast". Please pick a format and make clear what things are terms, and >>> which are not terms. Then rewrite section 1.2, so that it more properly >>> describes what the reader should expect. >>> >> >> *This is just nesting of the format, Incast is a sub of Buffering. We ca= n >> change them to top level with Buffering =E2=80=93 Buffer and Buffering = =E2=80=93 Incast, >> however we find that less readable for the user and want to keep the >> current display/text the way it is.* >> >> >>> >>> There are, at several locations, uses of the capitalized word "CAN" in = a >>> way that suggests normative-type intent. "CAN" does not seem to be an >>> RFC2119 keyword. In one case, it seems that "CAN" may actually mean a l= ower >>> case "may" or "can" (see 6.1.1 on page 12). >>> >> >> >> *This is fixed, thank you!* >> >> >>> Nits >>> Throughout the draft sometimes terms are capitalized, sometimes they ar= e >>> not. I believe they should more often not be capitalized, but if they a= re, >>> do so consistently. >>> >>> Generally speaking (this may be stylistic) the first word after a colon >>> (':') should be capitalized. Example: This is. >>> >> >> *This is fixed, thank you!* >> >>> >>> Find acronyms/initializations and ensure they're expanded at least on >>> the first occurrence (i.e. "PDV" on page 6) >>> >> >> Thanks! >> >>> >>> In the abstract s/as it is to/as to/ >>> >>> *This is fixed, thank you!* >> >> >>> In 2.1 s/in unit of/in units of/ and s/store forward/store and forward/ >>> >> >> *This is fixed, thank you!* >> >>> >>> In 2.3 s/follow:/follows:/ >>> >> *This is fixed, thank you!* >> >>> >>> In 2.3, item 2: Is "proceed data" a common term? >>> >> *This is fixed, thank you!* >> >>> >>> In 4.1 s/test on/tests on/ >>> >> *This is fixed, thank you!* >> >>> >>> In 4.3 s/of :/of:/ >>> >> *This is fixed, thank you!* >> >>> >>> In 4.3 s/[4.1s]/section 4.1/ >>> >> *This is fixed, thank you!* >> >>> >>> In 5.3, if "CAN" is changed to "can", then s/line rate can measured/lin= e >>> rate can be measured/ >>> >> >> *This is fixed, thank you!* >> >> >>> In 6.1.1 s/expressed in Byte;/B (bytes),/ or s/expressed in Byte;/Bytes= ,/ >>> >> *This is fixed, thank you!* >> >> >>> >>> In 6.1.1 s/amount of buffer a single/amount of buffer for a single/ >>> >> *This is fixed, thank you!* >> >> >>> >>> In 6.1.1 recommend striking "it is a burst" >>> >> *This is fixed, thank you!* >> >> >>> >>> In 6.2.1 s/by synchronous/by synchronous arrival time/ >>> >> *This is fixed, thank you!* >> >> >>> >>> In 6.2.2 s/In a ingress/In an ingress/ >>> >> *This is fixed, thank you!* >> >> >>> >>> In 6.2.2 s/In either cases/In either case/ >>> >> *This is fixed, thank you!* >> >> >>> >>> In 6.2.3 s/non null/non-null/ >>> >> *This is fixed, thank you!* >> >> >>> >>> In 7.3 the first paragraph could be improved by simply writing, "When S >>> represents the payload bytes, which does not include packet or TCP head= ers, >>> and Ft is the Finishing Time of the last sender, the Goodput, G, is the= n >>> measured by the following formula..." >>> >> *This is fixed, thank you!* >> >> >>> >>> >>> Kind regards, >>> >>> Adam >>> >>> >>> >> > --94eb2c0a89444fce520551cb2d7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, I accept. Sorry about that, and thanks for reaching out again to wrang= le an answer from me.

Adam
On Mon, Jun 12, 2017 at 5:51 PM Lucien Avramov <lucienav@google.com> wrote:
Hi Adam,

Just want= ed to check in with you, to see if you accept the way I addressed your comm= ents.

Thanks in advance!
Lucien

On Thu, Jun 8, 2017 at 10:10 PM, Lucien Avramov = <lucienav@googl= e.com> wrote:
Hi Adam!

Many thanks for the review! I addressed you= r comments and published -10 of the draft (draft-ietf-bmwg-dcbench-terminol= ogy-10).=C2=A0

Please see inline for some comments= .

Thanks a lot for the detail feedback!
=
Lucien

On Mon, Jun 5, 2017 at 10:32 AM, Adam Montville <adam.w.montville@gmail.com> wrote:
I have reviewed this doc= ument as part of the security directorate's ongoing effort to review al= l IETF documents being processed by the IESG. These comments were written p= rimarily for the benefit of the security area directors. Document editors a= nd WG chairs should treat these comments just like any other last call comm= ents.

Bottom Line: Almost Ready

About Security Considerations
For your security considerat= ions phrases like "are limited to" and "will be", and I= would suggest that these are your MUSTs or SHOULDs. Given the "MUST N= OT" you have in the second paragraph, it seems that "MUST" s= hould be used instead of "SHOULD". In that sense, then, I would s= uggest the following statements be updated: 1) "Benchmarking activitie= s as described in this memo MUST be limited to technology characterization = using controlled stimuli...", "The benchmarking network topology = MUST be an independent test setup..."

That sa= id, you might consider softening the "MUST NOT" and consequent &q= uot;MUST" statements to "SHOULD NOT" and "SHOULD",= respectively. This because there may well be circumstances where testing i= n a production environment is necessary.


These are the= standard security considerations all BMWG uses for all the drafts. We want= to stay with the considerations we chose.=C2=A0
= =C2=A0
About Rest of Draft
The draft describes well-= understood concepts of FILO, FIFO, LILO, and LIFO. It then goes on to recas= t these definitions as "first bit last bit" (or "FL"), = and "last bit last bit" (or "LL"), and so on. However, = the draft does not really make use of these alternate expressions for the a= forementioned well-understood concepts. I recommend picking one of these re= presentations and using it consistently throughout; moreover, I recommend s= ticking with FILO, FIFO, LILO, and LIFO.

<= /div>
We do want to stay with FILO= , FIFO, LILO and LIFO. The FL, LL, etc were added as this was sometimes ref= erred to as, not to as FL, LL, etc.
=C2=A0

=
There's a sentence in 2.2 which reads, "Data Center DUTs are = frequently store-and-forward for smaller packet sizes and then adopting a c= ut-through behavior." This feels incomplete. When does it adopt cut-th= rough behavior? Is that adopted for larger packet sizes? Is it worthwhile t= o talk at all about the change threshold?

=
I addressed your comment by updating the text in the p= ublication to state that the threshold change is not matter, what matters i= s that the test FILO is key, in order to catch these differences of behavio= rs.=C2=A0

=C2=A0

Secti= on 1.2 describes the generally expected definition format. However, section= 2 seems to immediately depart from that to some degree by placing terms as= top-level sections (i.e. "2. Latency") with children for definit= ion, discussion, and measurement units. To compound this confusion, section= 6 further departs from the expectation set in 1.2 by using the top-level s= ection as a grouping construct for "Buffering" (without defining = "Buffering"). Buffering has two children which are "buffer&q= uot; and "incast". Buffer, itself is never defined, but instead h= as a "definition" subsection =C2=A0consisting of many other terms= . The same sort of thing happens with "6.2 Incast". Please pick a= format and make clear what things are terms, and which are not terms. Then= rewrite section 1.2, so that it more properly describes what the reader sh= ould expect.

This is just nesting of the format, Incast is a sub of B= uffering. We can change them to top level with Buffering =E2=80=93 Buffer a= nd Buffering =E2=80=93 Incast, however we find that less readable for the u= ser and want to keep the current display/text the way it is.
=C2=A0

There are, at several locations, uses of the = capitalized word "CAN" in a way that suggests normative-type inte= nt. "CAN" does not seem to be an RFC2119 keyword. In one case, it= seems that "CAN" may actually mean a lower case "may" = or "can" (see 6.1.1 on page 12).
=C2=A0
This is fixed, thank y= ou!
=C2=A0
Nits
Throughout the d= raft sometimes terms are capitalized, sometimes they are not. I believe the= y should more often not be capitalized, but if they are, do so consistently= .

Generally speaking (this may be stylistic) the f= irst word after a colon (':') should be capitalized. Example: This = is.

This is fixed, thank you!

Find acronyms/initial= izations and ensure they're expanded at least on the first occurrence (= i.e. "PDV" on page 6)

Thanks!=C2=A0

In the abstract s/as it is to/as to/
<= div>
This is= fixed, thank you!
=C2=A0
In 2.1 s/in unit o= f/in units of/ and s/store forward/store and forward/

This is fixed, thank y= ou!

In 2.3 s/follow:/follows:/
This is fixed, thank you!

In 2.3, item 2: Is "proceed data" a common term?<= /div>
This is fixed, t= hank you!

In 4.1 s/test on/tests on/
This is fixed, thank you!=

In 4.3 s/of :/of:/
This is fixed, thank you!

In 4.3 s/[4.1s]/section 4.1/
This is fixed, thank you!

In 5.3, if= "CAN" is changed to "can", then s/line rate can measur= ed/line rate can be measured/

<= b style=3D"font-size:12.8px">This is fixed, thank you!
= =C2=A0
In 6.1.1 s/expressed in Byte;/B (bytes),/ or s/expresse= d in Byte;/Bytes,/
This is fixed, thank you!
=C2=A0

In 6.1.1 s/amount of buffer a single/amount of buffer for a single/<= /div>
This is fix= ed, thank you!
=C2=A0

In 6.1.1 rec= ommend striking "it is a burst"
This is fixed, thank you!
= =C2=A0

In 6.2.1 s/by synchronous/b= y synchronous arrival time/
This is fixed, thank you!
=C2=A0<= /div>

In 6.2.2 s/In a ingress/In an ingress/
This is fix= ed, thank you!
=C2=A0

In 6.2= .2 s/In either cases/In either case/
This is fixed, thank you!
=C2=A0

In 6.2.3 s/non null/non-null/
This is fixed, tha= nk you!
=C2=A0

In 7.3= the first paragraph could be improved by simply writing, "When S repr= esents the payload bytes, which does not include packet or TCP headers, and= Ft is the Finishing Time of the last sender, the Goodput, G, is then measu= red by the following formula..."
<= div>This is fixed, thank you!
=C2=A0


Kind regards,
Adam




--94eb2c0a89444fce520551cb2d7e-- From nobody Mon Jun 12 15:54: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 C5648127241 for ; Mon, 12 Jun 2017 15:54:38 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mu-hbtRiEQyd for ; Mon, 12 Jun 2017 15:54:36 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 9668A128DF3 for ; Mon, 12 Jun 2017 15:54:34 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id 15so30109272pfc.1 for ; Mon, 12 Jun 2017 15:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EFuJf84GO8eqBnySQGwTgrHfpvNvtxynDfdE/uYu3g8=; b=WQJffu5zkU+rUPXDWvVjg+equ8p1WIuNtTD7nYBxwk7WFiVszYPkLCCrdFWCoTndIb OjrVEhO6CUZUN6hzWnCsZBuIqOfqjUq4+xj5FCnjSFCI3ILXcQYzrAyee430ee4FFdlT 5DVmY4RhWCEtxPlzgO+S7IdPcqmoUxqCIvjKc5FsnblFb9T0bHvKfe6RHbdQTSnNPrfE a5o23i/Ugvp+BOrDnManm9vtuRtc45NMzkq5dQUxsOIig4FFpvKGERkBI6hCOxIGsoub /6ZDxbBlC6er+OuZuUlaMqkXSt/gZ/CAEGm/WIcNTpqlXDGaQNj8XS2+pVGCAPkMMCVk YCEg== 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=EFuJf84GO8eqBnySQGwTgrHfpvNvtxynDfdE/uYu3g8=; b=Y5Rud37aiBMNVHC3pYaJf6I7NgoPa8Zke7jt+SsV9UICmeUrcdZpTpSplLjFkh3ZIM BqhkokyI96kiX8VZcSXEg1fY9QaLvnPc1OoCzCvy4VehJ5GRJIR95n77akmpsra88U6p b1J/UZyLe1g00wZPNajdYWCKyiaK3b1xOOSlL4RjTtRevghaFgqFW6JdwpVsHJqkr/EW UCphu4T3jb/A5nKGkZtzPVqmz2T/ycfVTVjobVWu61gu/rjlogy1lmQ6pJgk4y70PrYz NYsy+IhlmVkMIhTVoPacw7yw818OLp4CZZvEc2UbQriKyuTAaVLwQs9RgneEV3xa67m/ /JRQ== X-Gm-Message-State: AODbwcCAQZhlSkbW5GdwUK+rkMv06TAml43ZK7npPrBi+meP6VyzpBn6 RE2GvucG9pvGydoQDPVPuWf5XRL/M317 X-Received: by 10.99.106.2 with SMTP id f2mr57725004pgc.46.1497308074123; Mon, 12 Jun 2017 15:54:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.168.5 with HTTP; Mon, 12 Jun 2017 15:54:13 -0700 (PDT) In-Reply-To: References: From: Lucien Avramov Date: Mon, 12 Jun 2017 15:54:13 -0700 Message-ID: To: Adam Montville Cc: draft-ietf-bmwg-dcbench-terminology.all@ietf.org, "secdir@ietf.org" , Warren Kumari , The IESG , Alfred C Morton , Jacob Rapp Content-Type: multipart/alternative; boundary="94eb2c13f244e105ae0551cb336c" Archived-At: Subject: Re: [secdir] SECDIR Review of: draft-ietf-bmwg-dcbench-terminology 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, 12 Jun 2017 22:54:39 -0000 --94eb2c13f244e105ae0551cb336c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Adam! Appreciate your feedback!! On Mon, Jun 12, 2017 at 3:52 PM, Adam Montville wrote: > Yes, I accept. Sorry about that, and thanks for reaching out again to > wrangle an answer from me. > > Adam > > On Mon, Jun 12, 2017 at 5:51 PM Lucien Avramov > wrote: > >> Hi Adam, >> >> Just wanted to check in with you, to see if you accept the way I >> addressed your comments. >> >> Thanks in advance! >> Lucien >> >> On Thu, Jun 8, 2017 at 10:10 PM, Lucien Avramov >> wrote: >> >>> Hi Adam! >>> >>> Many thanks for the review! I addressed your comments and published -10 >>> of the draft (draft-ietf-bmwg-dcbench-terminology-10). >>> >>> Please see inline for some comments. >>> >>> Thanks a lot for the detail feedback! >>> >>> Lucien >>> >>> On Mon, Jun 5, 2017 at 10:32 AM, Adam Montville < >>> adam.w.montville@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 IES= G. >>>> 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. >>>> >>>> Bottom Line: Almost Ready >>>> >>>> About Security Considerations >>>> For your security considerations phrases like "are limited to" and >>>> "will be", and I would suggest that these are your MUSTs or SHOULDs. G= iven >>>> the "MUST NOT" you have in the second paragraph, it seems that "MUST" >>>> should be used instead of "SHOULD". In that sense, then, I would sugge= st >>>> the following statements be updated: 1) "Benchmarking activities as >>>> described in this memo MUST be limited to technology characterization = using >>>> controlled stimuli...", "The benchmarking network topology MUST be an >>>> independent test setup..." >>>> >>>> That said, you might consider softening the "MUST NOT" and consequent >>>> "MUST" statements to "SHOULD NOT" and "SHOULD", respectively. This bec= ause >>>> there may well be circumstances where testing in a production environm= ent >>>> is necessary. >>>> >>>> >>>> *These are the standard security considerations all BMWG uses for all >>> the drafts. We want to stay with the considerations we chose. * >>> >>> >>>> About Rest of Draft >>>> The draft describes well-understood concepts of FILO, FIFO, LILO, and >>>> LIFO. It then goes on to recast these definitions as "first bit last b= it" >>>> (or "FL"), and "last bit last bit" (or "LL"), and so on. However, the = draft >>>> does not really make use of these alternate expressions for the >>>> aforementioned well-understood concepts. I recommend picking one of th= ese >>>> representations and using it consistently throughout; moreover, I reco= mmend >>>> sticking with FILO, FIFO, LILO, and LIFO. >>>> >>> >>> *We do want to stay with FILO, FIFO, LILO and LIFO. The FL, LL, etc wer= e >>> added as this was sometimes referred to as, not to as FL, LL, etc.* >>> >>> >>>> >>>> There's a sentence in 2.2 which reads, "Data Center DUTs are frequentl= y >>>> store-and-forward for smaller packet sizes and then adopting a cut-thr= ough >>>> behavior." This feels incomplete. When does it adopt cut-through behav= ior? >>>> Is that adopted for larger packet sizes? Is it worthwhile to talk at a= ll >>>> about the change threshold? >>>> >>> >>> *I addressed your comment by updating the text in the publication to >>> state that the threshold change is not matter, what matters is that the >>> test FILO is key, in order to catch these differences of behaviors. * >>> >>> >>> >>>> >>>> Section 1.2 describes the generally expected definition format. >>>> However, section 2 seems to immediately depart from that to some degre= e by >>>> placing terms as top-level sections (i.e. "2. Latency") with children = for >>>> definition, discussion, and measurement units. To compound this confus= ion, >>>> section 6 further departs from the expectation set in 1.2 by using the >>>> top-level section as a grouping construct for "Buffering" (without def= ining >>>> "Buffering"). Buffering has two children which are "buffer" and "incas= t". >>>> Buffer, itself is never defined, but instead has a "definition" subsec= tion >>>> consisting of many other terms. The same sort of thing happens with "= 6.2 >>>> Incast". Please pick a format and make clear what things are terms, an= d >>>> which are not terms. Then rewrite section 1.2, so that it more properl= y >>>> describes what the reader should expect. >>>> >>> >>> *This is just nesting of the format, Incast is a sub of Buffering. We >>> can change them to top level with Buffering =E2=80=93 Buffer and Buffer= ing =E2=80=93 >>> Incast, however we find that less readable for the user and want to kee= p >>> the current display/text the way it is.* >>> >>> >>>> >>>> There are, at several locations, uses of the capitalized word "CAN" in >>>> a way that suggests normative-type intent. "CAN" does not seem to be a= n >>>> RFC2119 keyword. In one case, it seems that "CAN" may actually mean a = lower >>>> case "may" or "can" (see 6.1.1 on page 12). >>>> >>> >>> >>> *This is fixed, thank you!* >>> >>> >>>> Nits >>>> Throughout the draft sometimes terms are capitalized, sometimes they >>>> are not. I believe they should more often not be capitalized, but if t= hey >>>> are, do so consistently. >>>> >>>> Generally speaking (this may be stylistic) the first word after a colo= n >>>> (':') should be capitalized. Example: This is. >>>> >>> >>> *This is fixed, thank you!* >>> >>>> >>>> Find acronyms/initializations and ensure they're expanded at least on >>>> the first occurrence (i.e. "PDV" on page 6) >>>> >>> >>> Thanks! >>> >>>> >>>> In the abstract s/as it is to/as to/ >>>> >>>> *This is fixed, thank you!* >>> >>> >>>> In 2.1 s/in unit of/in units of/ and s/store forward/store and forward= / >>>> >>> >>> *This is fixed, thank you!* >>> >>>> >>>> In 2.3 s/follow:/follows:/ >>>> >>> *This is fixed, thank you!* >>> >>>> >>>> In 2.3, item 2: Is "proceed data" a common term? >>>> >>> *This is fixed, thank you!* >>> >>>> >>>> In 4.1 s/test on/tests on/ >>>> >>> *This is fixed, thank you!* >>> >>>> >>>> In 4.3 s/of :/of:/ >>>> >>> *This is fixed, thank you!* >>> >>>> >>>> In 4.3 s/[4.1s]/section 4.1/ >>>> >>> *This is fixed, thank you!* >>> >>>> >>>> In 5.3, if "CAN" is changed to "can", then s/line rate can >>>> measured/line rate can be measured/ >>>> >>> >>> *This is fixed, thank you!* >>> >>> >>>> In 6.1.1 s/expressed in Byte;/B (bytes),/ or s/expressed in >>>> Byte;/Bytes,/ >>>> >>> *This is fixed, thank you!* >>> >>> >>>> >>>> In 6.1.1 s/amount of buffer a single/amount of buffer for a single/ >>>> >>> *This is fixed, thank you!* >>> >>> >>>> >>>> In 6.1.1 recommend striking "it is a burst" >>>> >>> *This is fixed, thank you!* >>> >>> >>>> >>>> In 6.2.1 s/by synchronous/by synchronous arrival time/ >>>> >>> *This is fixed, thank you!* >>> >>> >>>> >>>> In 6.2.2 s/In a ingress/In an ingress/ >>>> >>> *This is fixed, thank you!* >>> >>> >>>> >>>> In 6.2.2 s/In either cases/In either case/ >>>> >>> *This is fixed, thank you!* >>> >>> >>>> >>>> In 6.2.3 s/non null/non-null/ >>>> >>> *This is fixed, thank you!* >>> >>> >>>> >>>> In 7.3 the first paragraph could be improved by simply writing, "When = S >>>> represents the payload bytes, which does not include packet or TCP hea= ders, >>>> and Ft is the Finishing Time of the last sender, the Goodput, G, is th= en >>>> measured by the following formula..." >>>> >>> *This is fixed, thank you!* >>> >>> >>>> >>>> >>>> Kind regards, >>>> >>>> Adam >>>> >>>> >>>> >>> >> --94eb2c13f244e105ae0551cb336c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Adam!

Appreciate your feedback!!=

On Mo= n, Jun 12, 2017 at 3:52 PM, Adam Montville <adam.w.montville@gmai= l.com> wrote:
Yes, I accept= . Sorry about that, and thanks for reaching out again to wrangle an answer = from me.

Adam<= /span>

On Mon, Jun 12, 2017 at 5:51 PM Lucien Avramov <lucienav@google.com= > wrote:
Hi Ada= m,

Just wanted to check in with you, to see if you accep= t the way I addressed your comments.

Thanks in adv= ance!
Lucien

On Thu, Jun 8, 2017 at 10:10 PM, Lu= cien Avramov <lucienav@google.com> wrote:
Hi Adam!

Many thanks = for the review! I addressed your comments and published -10 of the draft (d= raft-ietf-bmwg-dcbench-terminology-10).=C2=A0

Please see inline for some comments.

Thanks a lot= for the detail feedback!

Lucien

On Mon, Jun 5, 2017 a= t 10:32 AM, Adam Montville <adam.w.montville@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 by t= he IESG. These comments were written primarily for the benefit of the secur= ity area directors. Document editors and WG chairs should treat these comme= nts just like any other last call comments.

Bottom= Line: Almost Ready

About Security Considerations<= /div>
For your security considerations phrases like "are limited t= o" and "will be", and I would suggest that these are your MU= STs or SHOULDs. Given the "MUST NOT" you have in the second parag= raph, it seems that "MUST" should be used instead of "SHOULD= ". In that sense, then, I would suggest the following statements be up= dated: 1) "Benchmarking activities as described in this memo MUST be l= imited to technology characterization using controlled stimuli...", &q= uot;The benchmarking network topology MUST be an independent test setup...&= quot;

That said, you might consider softening the = "MUST NOT" and consequent "MUST" statements to "SH= OULD NOT" and "SHOULD", respectively. This because there may= well be circumstances where testing in a production environment is necessa= ry.


These are the standard security considerations all= BMWG uses for all the drafts. We want to stay with the considerations we c= hose.=C2=A0
=C2=A0
About Rest of Draft=
The draft describes well-understood concepts of FILO, FIFO, LILO= , and LIFO. It then goes on to recast these definitions as "first bit = last bit" (or "FL"), and "last bit last bit" (or &= quot;LL"), and so on. However, the draft does not really make use of t= hese alternate expressions for the aforementioned well-understood concepts.= I recommend picking one of these representations and using it consistently= throughout; moreover, I recommend sticking with FILO, FIFO, LILO, and LIFO= .

We do want to stay with FILO, FIFO, LILO and LIFO. The FL, LL, etc = were added as this was sometimes referred to as, not to as FL, LL, etc.=
=C2=A0

There's a sentence in 2.2 whic= h reads, "Data Center DUTs are frequently store-and-forward for smalle= r packet sizes and then adopting a cut-through behavior." This feels i= ncomplete. When does it adopt cut-through behavior? Is that adopted for lar= ger packet sizes? Is it worthwhile to talk at all about the change threshol= d?

I addressed your c= omment by updating the text in the publication to state that the threshold = change is not matter, what matters is that the test FILO is key, in order t= o catch these differences of behaviors.=C2=A0

=C2=A0

Section 1.2 describes the generally expected = definition format. However, section 2 seems to immediately depart from that= to some degree by placing terms as top-level sections (i.e. "2. Laten= cy") with children for definition, discussion, and measurement units. = To compound this confusion, section 6 further departs from the expectation = set in 1.2 by using the top-level section as a grouping construct for "= ;Buffering" (without defining "Buffering"). Buffering has tw= o children which are "buffer" and "incast". Buffer, its= elf is never defined, but instead has a "definition" subsection = =C2=A0consisting of many other terms. The same sort of thing happens with &= quot;6.2 Incast". Please pick a format and make clear what things are = terms, and which are not terms. Then rewrite section 1.2, so that it more p= roperly describes what the reader should expect.

This is just nesting= of the format, Incast is a sub of Buffering. We can change them to top lev= el with Buffering =E2=80=93 Buffer and Buffering =E2=80=93 Incast, however = we find that less readable for the user and want to keep the current displa= y/text the way it is.
=C2=A0

There are= , at several locations, uses of the capitalized word "CAN" in a w= ay that suggests normative-type intent. "CAN" does not seem to be= an RFC2119 keyword. In one case, it seems that "CAN" may actuall= y mean a lower case "may" or "can" (see 6.1.1 on page 1= 2).

=C2=A0
This is fixed, thank you!
=C2=A0
Nits
Throughout the draft sometimes te= rms are capitalized, sometimes they are not. I believe they should more oft= en not be capitalized, but if they are, do so consistently.

<= /div>
Generally speaking (this may be stylistic) the first word after a= colon (':') should be capitalized. Example: This is.

This is fixed,= thank you!
=

Find acronyms/initializations and ensu= re they're expanded at least on the first occurrence (i.e. "PDV&qu= ot; on page 6)

Thanks!=C2=A0
=
In the abstract s/as it is to/as to/

This is fixed, thank you= !
=C2=A0
In 2.1 s/in unit of/in units of/ an= d s/store forward/store and forward/

This is fixed, thank you!
=
In 2.3 s/follow:/follows:/
This is fixed, thank you!

I= n 2.3, item 2: Is "proceed data" a common term?
This is fixed, thank you!
=

In 4.1 s/test on/tests on/
<= b style=3D"font-size:12.8px">This is fixed, thank you!

=
In 4.3 s/of :/of:/
This is fixed, thank you!

In 4.3 s/[4.1s]/= section 4.1/
Thi= s is fixed, thank you!

In 5.3, if "CAN" = is changed to "can", then s/line rate can measured/line rate can = be measured/

This is fixed, thank you!
=C2=A0
In 6.1.1 s/expressed in Byte;/B (bytes),/ or s/expressed in Byte;/Bytes,/<= /div>
This is fix= ed, thank you!
=C2=A0

In 6.1.1 s/a= mount of buffer a single/amount of buffer for a single/
This is fixed, thank you!<= br>
=C2=A0

In 6.1.1 recommend striking &qu= ot;it is a burst"
This is fixed, thank you!
=C2=A0
<= /div>

In 6.2.1 s/by synchronous/by synchronous arriv= al time/
This is fixed, thank you!
=C2=A0

<= span>
In 6.2.2 s/In a ingress/In an ingress/
This is fixed, thank you!<= br>
=C2=A0

In 6.2.2 s/In either case= s/In either case/
This is fixed, thank you!
=C2=A0
In 6.2.3 s/non null/non-null/
This is fixed, thank you!
=C2=A0

In 7.3 the first paragrap= h could be improved by simply writing, "When S represents the payload = bytes, which does not include packet or TCP headers, and Ft is the Finishin= g Time of the last sender, the Goodput, G, is then measured by the followin= g formula..."
This is fixed, thank you!
=C2=A0
<= br>

Kind regards,

Adam





--94eb2c13f244e105ae0551cb336c-- From nobody Tue Jun 13 08:13:51 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 4396C131C04; Tue, 13 Jun 2017 08:13:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Matthew Miller To: Cc: draft-ietf-precis-7564bis.all@ietf.org, ietf@ietf.org, precis@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149736681626.7439.2555177998557552719@ietfa.amsl.com> Date: Tue, 13 Jun 2017 08:13:36 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-precis-7564bis-07 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, 13 Jun 2017 15:13:36 -0000 Reviewer: Matthew Miller 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-precis-7564bis-07 Reviewer: Matthew A. Miller Review Date: 2017-06-13 IETF LC End Date: 2017-06-13 IESG Telechat date: 2017-07-06 Summary: This document is ready to be published as a Standards Track document. This document defines a framework application protocols use to prepare, compare, and enforce conformance of internationalized strings. It obsoletes RFC 7564. This document is well written, and reinforces the security concerns discussed in Section 12 with references in the most relevant sections throughout the document. While much of it essentially proclaims "be aware herein be dragons", the arguments for not proscribing more are well laid out. Major Issues: NONE Minor Issues: NONE Nits: NONE From nobody Tue Jun 13 13:57:53 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 13CA21296C6; Tue, 13 Jun 2017 13:57:52 -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 jCKjF9Ln2Ew3; Tue, 13 Jun 2017 13:57:50 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 7D954128DE5; Tue, 13 Jun 2017 13:57:50 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id x63so73375701pff.3; Tue, 13 Jun 2017 13:57:50 -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=+wqfUt/u6PBkPfqT1BdBj9TCgJRRgfnhLwXpjWTgfkE=; b=TXLB057JY/M1+QrSxGlUmYfDh3GJrDlo5HcZ3dS9uqCDqffMDZhTKWs+uqcj5sqsmZ QcHlHjXzYMtrYu20n2Syh+eKapSX6If5Iuu9BbiH3LV0fcwiAKcRix6xlsKjsqU8+b9i EwGmQJK/gZ04qsSsmsH9rVlF7jNfyYDn6h4QkZwurl4HaKr+W5FC4B7yM6C3Gn64doUz M4Qp1LavzYTiYyGi8kFELKapEWm7pY3QKtsIB4RcXSGFsyQxPNLABQUdp0EuZ8ndcUE3 YBzBDQ26HEve53TL1SJoXqHZXwNhiW6RTxndj9mL9Xr2Ymcfv36wcU/OiBovkpVqENzN X8NA== 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=+wqfUt/u6PBkPfqT1BdBj9TCgJRRgfnhLwXpjWTgfkE=; b=mW0qaiI9pLPP3aWuEupPSQ20wmw2Q9PkN8v7ISMx9SS4NxVGAhMK7N3VW0a65eoNtZ 5CeWTpmebA51fuwRDycWAw7ouF+h7gZici7/VfbCWFXO+SYIF3eU0Qjvtch1f1ClmCHf IRKmfuM76OnPcCkeTcsZrmi/ZLFSGAVB5oFw7lzS7NZrI26Dw1zBQ2VDVQFMHzEvQp1y TMRJnPZ9fQGVyuspADF7vv7hpR4b52uPFp95BwKmuCk0Oo2iM2M7E8BmW6kC5eIM3H0Z HT0erw9PzxGuT3lrQ71jfEqEstTMHZcSE/u7xdBLks4fHk55OusoIfvICuxJNC0hCQT6 XDww== X-Gm-Message-State: AKS2vOwFzrPvSXGw5QEkksDk4n6phbF62mwZrtk0FTiONmwNiBykqEVx ZEiE4b+j3uvnwJPX945Uszdc1zNxqQ== X-Received: by 10.84.209.199 with SMTP id y65mr1503304plh.205.1497387470191; Tue, 13 Jun 2017 13:57:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.169.13 with HTTP; Tue, 13 Jun 2017 13:57:09 -0700 (PDT) In-Reply-To: <149616615640.19877.7389294095180042080@ietfa.amsl.com> References: <149616615640.19877.7389294095180042080@ietfa.amsl.com> From: Kathleen Moriarty Date: Tue, 13 Jun 2017 16:57:09 -0400 Message-ID: To: Barry Leiba Cc: "secdir@ietf.org" , draft-ietf-sacm-requirements.all@ietf.org, IETF , "sacm@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-sacm-requirements-15 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, 13 Jun 2017 20:57:52 -0000 Hi Barry, Thank you, for your review. It's much appreciated! The SACM WG has had this as a planned working group item and has wanted it published from the start. I checked again at the interim last week and it is the WG's preference to publish this informational draft. I did ask about linking the draft to a wiki. I'm supporting the WG's decision and feel that it is important for their progress to move beyond this milestone. Thanks for catching the nit, we'll make sure that gets corrected. Best, Kathleen On Tue, May 30, 2017 at 1:42 PM, Barry Leiba wrote: > Reviewer: Barry Leiba > Review result: Has Nits > > While I'm calling this document "ready", I really don't see why it > should be published in the RFC series at all. It's well written, and > it seems to be important material for the working group to use as it > develops the SACM architecture, data model and transport protocols, > but does not seem to be of lasting interest after those are done. I'd > rather see it in the working group wiki, and used that way. > > That said, I know the working group wants it published and that my > comment here is likely not to go far, so I'll say that if it's to be > published as an RFC, it's ready. The one nit I note is that in the > XML "title" element you appear to have abbrev="Abbreviated Title", > rather than the more likely abbrev="SACM Requirements". > -- Best regards, Kathleen From nobody Tue Jun 13 15:30: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 0C5FE127735; Tue, 13 Jun 2017 15:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f02mCqTJLJki; Tue, 13 Jun 2017 15:30:17 -0700 (PDT) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (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 54F5A1270FC; Tue, 13 Jun 2017 15:30:16 -0700 (PDT) Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id v5DMUDto027298 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 13 Jun 2017 18:30:14 -0400 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_44CA61B2-9FCD-426C-AD46-31D2C9685887" Date: Tue, 13 Jun 2017 18:30:13 -0400 Message-Id: <5270D796-928E-466F-96D3-3F8A401FFE7D@nrl.navy.mil> To: secdir@ietf.org, iesg@ietf.org, draft-ietf-tcpm-dctcp.all@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: Subject: [secdir] Secdir Review of draft-ietf-tcpm-dctcp-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 22:30:21 -0000 --Apple-Mail=_44CA61B2-9FCD-426C-AD46-31D2C9685887 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF 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. The summary of the review is Almost Ready. This draft concerns a variant of TCP intended for datacenters: DCTCP. Much of this takes advantage of the fact that datacenters are controlled environments managed by a single authority. The chief new feature is that the Explicit Notification = Congestion Field gives information about the amount of congestion present, instead of simply indicating whether there is congestion or not. The Security Considerations section notes that DCTCP inherits the security considerations of RFC3168, The only change that has a potential affect on security beyond those already mentioned = in RFC3168 is a statement that ECT markings (used to indicate whether endpoints explicit congestion notification) markings SHOULD be applied to control packets. RFC3168 does not allow this, and RFC5562 does not = allow this for SYN packets because of the possibility it such packets, since they would live longer, would facilitate SYN = flooding attacks. However, it is argued here that in a controlled environment SYN flooding = would not be an issue.=20 The section ends as follows: The security concerns addressed by both these RFCs might not apply in controlled environments like datacenters, and it might not be necessary to account for the presence of non-ECN servers. Since most servers run virtualized in datacenters, additional security can be imposed in the physical servers to intercept and drop traffic resembling an attack. I wasn=E2=80=99t sure how to take this. The first sentence indicates = uncertainty, but the second sentence gives a clear description of how security can be enforced on the = perimeter in datacenters. It also contradicts the statement at the beginning, that DCTCP inherits the security = considerations of RFC3168. I think that this needs to be stated more clearly. Perhaps, at the beginning you could say = something like=20 DCTCP enhances ECN and thus inherits the security considerations discussed in [RFC3168]. However, because most servers run = virtualized in datacenters, additional security can be imposed in the physical servers to intercept and drop traffic resembling an attack. This = makes it less likely that it will be necessary to account for the presence of non-ECN servers, = thus mitigating the security considerations in RFC3168. =20 Also, a nit: ECT is never defined in the document. =20 =20 Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil = --Apple-Mail=_44CA61B2-9FCD-426C-AD46-31D2C9685887 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; 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.

The summary of the review is Almost Ready.

This draft concerns a variant of TCP =  intended
for datacenters:  DCTCP. =   Much of this takes advantage of the
fact that = datacenters are controlled  environments managed by a single
authority.  The chief new feature is that the Explicit = Notification Congestion
Field  gives information = about the amount of congestion present,
instead of simply = indicating  whether there is congestion or not.

The Security Considerations section notes that DCTCP inherits = the
security considerations of RFC3168,  The only = change
that has a potential affect on security beyond = those already mentioned in
RFC3168 is a statement that ECT = markings (used to indicate whether
endpoints explicit = congestion notification) markings SHOULD be applied
to = control packets.  RFC3168 does not allow this, and RFC5562 does not = allow this for SYN packets because of the possibility
it = such packets, since they would live longer, would facilitate SYN = flooding attacks.
However, it is argued here that in a = controlled environment SYN flooding would not be an
issue. 

The section ends as follows:

The = security concerns addressed
   by both = these RFCs might not apply in controlled environments like
   datacenters, and it might not be necessary to = account for the
   presence of non-ECN = servers.  Since most servers run virtualized in
   datacenters, additional security can be imposed = in the physical
   servers to intercept = and drop traffic resembling an attack.

I wasn=E2=80=99t sure how to take this. =  The first sentence indicates uncertainty, but the second = sentence
gives a clear description of how security = can be enforced on the perimeter in datacenters. It also contradicts = the
statement at the beginning, that DCTCP inherits = the security considerations of RFC3168.  I think that this needs = to
be stated more clearly.  Perhaps, at the = beginning you could say something like 

DCTCP enhances ECN and = thus inherits the security considerations
  =  discussed in [RFC3168].  However, because most servers =  run virtualized in
   datacenters, additional = security can be imposed in the physical
  =  servers to intercept and drop traffic resembling an attack. =  This makes it less likely that
  =  it will be necessary to account for the presence of non-ECN = servers, thus mitigating the
   security = considerations in RFC3168.  

Also, a  nit:  ECT is never = defined in the document.  

  
Catherine Meadows
Naval Research = Laboratory
Code 5543
4555 Overlook Ave., = S.W.
Washington DC, 20375
phone: = 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil

= --Apple-Mail=_44CA61B2-9FCD-426C-AD46-31D2C9685887-- From nobody Tue Jun 13 16:02: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 9084C1293FF; Tue, 13 Jun 2017 16:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=i6v+q1k6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LRiZ4i3H 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 D0y0x0B6-TiA; Tue, 13 Jun 2017 16:02:30 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 655E1126D85; Tue, 13 Jun 2017 16:02:30 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id D4DE020779; Tue, 13 Jun 2017 19:02:29 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 13 Jun 2017 19:02:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=hYpJEJxhfVVoKbe4O9 FJfQCUGyOkOZtXIGVtx8SZlK4=; b=i6v+q1k6/3RkDdyRWdbVjaKk52EJbu9vBG S1ZCp9vy8bvDPu4MjFGYEU26QLhcBr+D88COd7cbIhLEGy8eOCbgvvDpsg1Zrv12 BvwwpPEJ0dTzMzCCBEbKBAvEFPgxg6XjEhcIGE6TKiS6miSiOLaVUxJ2R92vjybS 8N64tHDp9QZYYys6FzQ95yq7KL7g8m4BhAnaFoeTRXLaibxPAHiVHfhDdfBXdilY X3/igy/HJ/5hnF772sPxcfRkwB2fw0+smNnNI/JD4RaBbl52o2zVqIPH70/O+eCS Ul4X0BkVWkijuLoRnCmtr52dQz9NCYEwaK0FQaAWo1ZougjnJcwQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=hYpJEJxhfVVoKbe4O9FJfQCUGyOkOZtXIGVtx8SZlK4=; b=LRiZ4i3H Y+t0L4SqQhDd5ky1syaUs/W1PWVGW74C+Ox/+xXemYFQxSyK2TXxsLDfy8YdvgBb 61HtmKw1RVV1cC25vkvpwGpg98D10LTA26xdS1VsVbLuhmCBIIZoz6PhTFo8CWnB QAN2i+Tv9K8EocfEQOplPwvtaoLKZwEXiupJvLeVt9lnq/prppaVan4O0vSoLw01 zaCvzCrTSjDSzjLF2ZA3n6Y4orSehQAkCaCWSBYhnOcQW0nRhUnOSu97w7LDFrtZ 4fmPaWjpE95PN0Vw+KoIajctdpRx12dyc55F8HDWedHobAFu3lDz6KenNyBRA427 rWLa3Ibjw641pA== X-ME-Sender: X-Sasl-enc: e0uQ2UhIxT09nbCV9NHeq4i1ouZ7RDKecz5XaNtGaO5W 1497394949 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 2ACD47E7A3; Tue, 13 Jun 2017 19:02:29 -0400 (EDT) To: Matthew Miller , secdir@ietf.org References: <149736681626.7439.2555177998557552719@ietfa.amsl.com> Cc: draft-ietf-precis-7564bis.all@ietf.org, ietf@ietf.org, precis@ietf.org From: Peter Saint-Andre Message-ID: <8ea90b99-3005-0afb-da93-63cd1abfc905@stpeter.im> Date: Tue, 13 Jun 2017 17:02:28 -0600 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: <149736681626.7439.2555177998557552719@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] [precis] Secdir last call review of draft-ietf-precis-7564bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 23:02:33 -0000 Hi Matt, thanks for the review - it's much appreciated. Just so you know: through discussion of Daniel Migualt's secdir review of 7700bis (we're progressing them all together this time!), I realized that it might be help to add another example of visually confusing characters to 7564bis, so I plan to mention CYRILLIC SMALL LETTER A U+0430 vs. LATIN SMALL LETTER A U+0061 (which will be more familiar to readers than the Cherokee characters already in the document). Peter On 6/13/17 9:13 AM, Matthew Miller wrote: > Reviewer: Matthew Miller > 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-precis-7564bis-07 > Reviewer: Matthew A. Miller > Review Date: 2017-06-13 > IETF LC End Date: 2017-06-13 > IESG Telechat date: 2017-07-06 > > Summary: > > This document is ready to be published as a Standards Track document. > > This document defines a framework application protocols use to > prepare, compare, and enforce conformance of internationalized strings. > It obsoletes RFC 7564. > > This document is well written, and reinforces the security concerns > discussed in Section 12 with references in the most relevant sections > throughout the document. While much of it essentially proclaims > "be aware herein be dragons", the arguments for not proscribing more > are well laid out. > > Major Issues: NONE > > Minor Issues: NONE > > Nits: NONE > > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > From nobody Tue Jun 13 18:02:51 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 49977129423; Tue, 13 Jun 2017 18:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RSYQUWUkPIAz; Tue, 13 Jun 2017 18:02:30 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B061252BA; Tue, 13 Jun 2017 18:02:30 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1dKwhX-000MWa-2U; Tue, 13 Jun 2017 21:02:27 -0400 Date: Tue, 13 Jun 2017 21:02:22 -0400 From: John C Klensin To: Peter Saint-Andre , Matthew Miller , secdir@ietf.org cc: draft-ietf-precis-7564bis.all@ietf.org, ietf@ietf.org, precis@ietf.org Message-ID: In-Reply-To: <8ea90b99-3005-0afb-da93-63cd1abfc905@stpeter.im> References: <149736681626.7439.2555177998557552719@ietfa.amsl.com> <8ea90b99-3005-0afb-da93-63cd1abfc905@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [secdir] [precis] Secdir last call review of draft-ietf-precis-7564bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 01:02:32 -0000 --On Tuesday, June 13, 2017 17:02 -0600 Peter Saint-Andre wrote: > Hi Matt, thanks for the review - it's much appreciated. > > Just so you know: through discussion of Daniel Migualt's > secdir review of 7700bis (we're progressing them all together > this time!), I realized that it might be help to add another > example of visually confusing characters to 7564bis, so I plan > to mention CYRILLIC SMALL LETTER A U+0430 vs. LATIN SMALL > LETTER A U+0061 (which will be more familiar to readers than > the Cherokee characters already in the document). Peter, I don't want to throw the proverbial spanner in the works, but, just as things changes just as the original PRECIS documents were being published, I wonder if some other things that appear to be in process now could do it to us again. For example, consider draft-freytag-troublesome-characters. Despite having contributed to it and expecting to continue to do so, I've got some misgivings about the document and proposed registry as IETF work but, if it were to be adopted, it seems to me that it would be useful for the PRECIS documents to normatively reference it, especially for Identifier Class. To some extent, that draft is a remedy for some of the issues raised in the long-stalled draft-klensin-idna-5892upd-unicode70, but it doesn't make those issues, and the lack of comprehensiveness of normalization, go away. Probably less important, but it might be advantageous to incorporate some of the "whatever decisions you make, people will probably hold you accountable if there are problems" tone of draft-klensin-idna-rfc5891bis into the PRECIS documents. It might even be that RFC 7940, possibly supplemented by draft-freytag-lager-variant-rules, would be a better, or at least useful alternative, way to present some or all of the PEECIS rule sets than the current approach. On a somewhat different topic, the Greek, Latin, and Cyrillic scripts are so closely related that finding examples of pairs of similar-looking characters is in the low-lying fruit category because the similarities are not coincidences but the result of derivation and extensive borrowing (something of the same thing can be said for the Latin-Cherokee relationship, at least in printed, rather than cureive, forms). The examples that may be more scary, just because there is no evolutionary theory to predict were to look, would be things like the resemblances among the Latin U+006F, the Lao U+0ED0, the Ethiopic U+12D0, the New Tai Lue U+19D0, and of course the ASCII/European digit U+0030 and probably many more, with the group perhaps best described as "open circle graphemes" or something like that. best, john From nobody Tue Jun 13 19:57:57 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 92FC2124D6C; Tue, 13 Jun 2017 19:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 XQ3MpZosngIo; Tue, 13 Jun 2017 19:57:54 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 646B91242F5; Tue, 13 Jun 2017 19:57:54 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id u12so194959389qth.0; Tue, 13 Jun 2017 19:57:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=o9L2u8PeifLTF+dczkSozc7o+yJLe1c8DFS3ZdmfNsQ=; b=kkwKR1X0JIqPrC96Mr3V7skQ3eWYl4YJFJd6yCHl5wCPXC+thtKRmgQl/G6V72w49E TxNFfKc/Q2zLONz3iLMSL52iMfW9UpD3ZQE9jUyZ1I11eLjZhbd2i74WF8d4q1gLD5oq kIv/KiXshFGachY1e0Hidd+9l1nmX+FW9fO+Y/76amW6nr3U7cV+SiKaEBKk1IApanbi qgXPNoEFHaXgYiaOnfPB1xBx7Ie0m8FiTnObCOv0Nc+UB6F5/waB5c0ANS8az1G0bNfA 1WsKg0ldwnHUULsUlUkmVrPKOkJqPMUEsfmiQms/5nPCWgVbbpB0SXCzp5c9/AfVPJ+f md9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=o9L2u8PeifLTF+dczkSozc7o+yJLe1c8DFS3ZdmfNsQ=; b=TWXRqvkEoGgwIM7A6hgfHgp4nFHE2wh63E39O68JdNi81zdLa//adVtQkuAa/fwy+o pn4nsmgCIS6qHds1JZQS/x1m0IHdzvX2rOQcDjjwhYQvCY8qxo5bFCFSZHz0hAhYHssP IJufhpCvFLLqOXWJd0DIM08+PXAQ0x+gBB1Fifebr/B2kA5Go4PrH1aD6KRiquA39uf5 AF2mdqa/KYWxdWYOk2ckyZJNzy3W6ea244EBfr3uto/HkNFaXHs2dZfJWlxoWUFxIbPX 0VyJJai8GetiJ1QHmjlgZnyjPyvWtJnqbStMIyNE1xQdFSSK1iNDY6AV42ipn528SbZS zCbw== X-Gm-Message-State: AKS2vOy9E53/cHli/21YCtiu/KA0Vo7DiqqlxMi8M7kzUJXBl9R1nYFk 5+ABBkCjvC14ocN4Ngjy+S/kfFazLw== X-Received: by 10.237.42.228 with SMTP id t91mr4380297qtd.197.1497409073515; Tue, 13 Jun 2017 19:57:53 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.140.19.200 with HTTP; Tue, 13 Jun 2017 19:57:52 -0700 (PDT) In-Reply-To: References: <20170605165254.GE2903@localhost> <20170606160032.GC3432@localhost> From: Phillip Hallam-Baker Date: Tue, 13 Jun 2017 22:57:52 -0400 X-Google-Sender-Auth: 03y6tAS1Onhjdpcl3_10Fx1plt8 Message-ID: To: Spencer Dawkins at IETF Cc: Nico Williams , David Noveck , Watson Ladd , "secdir@ietf.org" , NFSv4 Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] [nfsv4] SECDIR Review of draft-ietf-nfsv4-umask-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 02:57:55 -0000 On Wed, Jun 7, 2017 at 3:08 AM, Spencer Dawkins at IETF wrote: > The document is approved. We now approve documents with no Discuss ballot > positions, but can still make changes to resolve comments that arise during > IESG Evaluation, if that's appropriate. > > I read Phillip's SECDIR review with interest. It does not seem to apply to > this draft, any more than to the rest of NFSv4, so I wouldn't hold up this > draft to pursue the issues Phillip raised. > > Those issues do seem to be a useful input to NFSv4, as the working group > considers a charter update (after finishing quite a lot of work, and thanks > to you all for that). That was the sense in which it was written. Its like when you take the car in to get the tires changed and they mention it has no brakes. Different things, yes. But something I am going to point out. From nobody Wed Jun 14 10:40:13 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 8B99B1200FC; Wed, 14 Jun 2017 10:40:10 -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 p_9oxJ-pNC3M; Wed, 14 Jun 2017 10:40:03 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35BEF1201F2; Wed, 14 Jun 2017 10:40:03 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id l75so4712182ywc.3; Wed, 14 Jun 2017 10:40:03 -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=b1j10UnxpiFrDeKYCHAlI+kB5GsygW3Vj+Y6sNFXnNw=; b=qqVllfhXUvXfCSt8A0ql5YMqT9UXlLk1mvMe3GwqU/ltv1QpOdwmxqCWvzSgWuq2oA sHy/vYyj/lTB22ov2PQ+feRHYIbY306KOYKtWtOFa3Zb34KQEIx15kvwzsu78SpCghSf bnFiNU74miy6HRu2hRSnSK+CGHF1Fek+K7cCajLh2CfzvjRdw2+sHHXpkkV6Gd2d0KSt ot+OVim4xk0bOMearVVItXz2hmPcFjjNxVhq3sYmtKWfWC/mUhkzFyr4qCGH4TutVOxQ qGEc3T7EUcqpM3ZqDJLkdG5YhNGSknnNFalbpA/IeeZBVMCeBP+gDe7SggsvfwBq5zQu 48wA== 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=b1j10UnxpiFrDeKYCHAlI+kB5GsygW3Vj+Y6sNFXnNw=; b=KPxv9Yx8gZNsdq9yHsXmvAUYuN1xE8OXpl4WEX4RAepmeTmK1df//v4hnA8NJwtte8 8RTUuQS0GWHMgEnlIJY9lbYc+VXX7OEbPrHKHgiQSI8Xg8xKprnmG3cS4NgB31gof3ZY 0cN85feVK+WGZsBC6CnkCqjYQCVRkcLpe/QxCD0UsoCSOZYw5g8U1ThmU4sPDQSF4JcR FDjLky0CvcVzt/EWNLG8tAZX4No7WOtjUbnIFvIHEf+hE+Qs7bFahNQzjd1ZUTZLbOMD zqOGdalHP0jp5tIugpireGjRAMvHHjufQEXvGjl3Gs++x3YOXg0aZLZQNCQh9ashR6D5 vtng== X-Gm-Message-State: AKS2vOwgeWMrX4IDl0q3IL1yxzo2qIK8iTDxmyeO7XzNea6iWzAJ8EL+ dN7WB5pOVAixu1M23hedf6Tr3qUbXg== X-Received: by 10.13.228.69 with SMTP id n66mr1020937ywe.275.1497462002224; Wed, 14 Jun 2017 10:40:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.216.85 with HTTP; Wed, 14 Jun 2017 10:40:01 -0700 (PDT) In-Reply-To: References: <20170605165254.GE2903@localhost> <20170606160032.GC3432@localhost> From: Spencer Dawkins at IETF Date: Wed, 14 Jun 2017 12:40:01 -0500 Message-ID: To: Phillip Hallam-Baker Cc: Nico Williams , David Noveck , Watson Ladd , "secdir@ietf.org" , NFSv4 Content-Type: multipart/alternative; boundary="94eb2c034ce4b51c160551ef0acc" Archived-At: Subject: Re: [secdir] [nfsv4] SECDIR Review of draft-ietf-nfsv4-umask-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 17:40:11 -0000 --94eb2c034ce4b51c160551ef0acc Content-Type: text/plain; charset="UTF-8" Hi, Phillip, On Tue, Jun 13, 2017 at 9:57 PM, Phillip Hallam-Baker wrote: > On Wed, Jun 7, 2017 at 3:08 AM, Spencer Dawkins at IETF > wrote: > > > The document is approved. We now approve documents with no Discuss > ballot > > positions, but can still make changes to resolve comments that arise > during > > IESG Evaluation, if that's appropriate. > > > > I read Phillip's SECDIR review with interest. It does not seem to apply > to > > this draft, any more than to the rest of NFSv4, so I wouldn't hold up > this > > draft to pursue the issues Phillip raised. > > > > Those issues do seem to be a useful input to NFSv4, as the working group > > considers a charter update (after finishing quite a lot of work, and > thanks > > to you all for that). > > That was the sense in which it was written. Its like when you take the > car in to get the tires changed and they mention it has no brakes. > For your amusement, I was trying to install Lubuntu on an older desktop system, and fell down the hall of mirrors of - "oh, it's too old to boot from USB", - "oh, the current 'CD images' won't fit on a 700-MB CD so you need to find an older release", - "oh, it can't create a bootable CD because XP Home didn't support that", - "oh, it has disk errors when installing from CD" ... and in the middle of all that, Mozilla popped up and said "your Mozilla release is no longer supported on your operating system, and the oldest release that would run on your operating system isn't supported either, so you should upgrade your operating system". So, I can relate to your analogy better today than I would have a week ago. > Different things, yes. But something I am going to point out. > And thank you for that. The NFSv4 working group has a recharter discussion on their agenda for Prague, so your timing is perfect for them to consider their security situation. Spencer --94eb2c034ce4b51c160551ef0acc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Phillip,

On Tue, Jun 13, 2017 at 9:57 PM, Phillip Hallam-Baker <phi= ll@hallambaker.com> wrote:
= On Wed, Jun 7, 2017 at 3:08 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gm= ail.com> wrote:

>=C2=A0 The document is approved. We now approve documents with no Discu= ss ballot
> positions, but can still make changes to resolve comments that arise d= uring
> IESG Evaluation, if that's appropriate.
>
> I read Phillip's SECDIR review with interest. It does not seem to = apply to
> this draft, any more than to the rest of NFSv4, so I wouldn't hold= up this
> draft to pursue the issues Phillip raised.
>
> Those issues do seem to be a useful input to NFSv4, as the working gro= up
> considers a charter update (after finishing quite a lot of work, and t= hanks
> to you all for that).

That was the sense in which it was written. Its like when you take t= he
car in to get the tires changed and they mention it has no brakes.

For your amusement, I was trying to install Lub= untu on an older desktop system, and fell down the hall of mirrors of=C2=A0=
  • "oh, it's too old to boot from USB",=C2=A0=
  • "oh, the current 'CD images' won't fit on a 700-M= B CD so you need to find an older release",=C2=A0
  • "oh, it= can't create a bootable CD because XP Home didn't support that&quo= t;,=C2=A0
  • "oh, it has disk errors when installing from CD"= ;
... and in the middle of all that, Mozilla popped up and said &q= uot;your Mozilla release is no longer supported on your operating system, a= nd the oldest release that would run on your operating system isn't sup= ported either, so you should upgrade your operating system".
=

So, I can relate to your analogy better today than I wo= uld have a week ago.
=C2=A0
Different things, yes. But something I am going to point out.

And thank you for t= hat.=C2=A0

The NFSv4 working group has a recharter discussion on their agenda for= Prague, so your timing is perfect for them to consider their security situ= ation.

Spencer
--94eb2c034ce4b51c160551ef0acc-- From nobody Thu Jun 15 07:33:48 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 CF300129505 for ; Thu, 15 Jun 2017 07:33:46 -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.54.1 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <149753722684.13069.15824600000796391760.idtracker@ietfa.amsl.com> Date: Thu, 15 Jun 2017 07:33:46 -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, 15 Jun 2017 14:33:47 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-06-22 Reviewer LC end Draft Ben Laurie 2017-06-05 draft-ietf-v6ops-v4v6-xlat-prefix-01 Adam Montville R2017-06-13 draft-ietf-bmwg-dcbench-terminology-10 Russ Mundy 2017-06-13 draft-ietf-bmwg-dcbench-methodology-09 Sandra Murphy 2017-06-09 draft-ietf-pals-p2mp-pw-lsp-ping-03 Liang Xia R2017-04-20 draft-ietf-avtcore-rfc5285-bis-12 For telechat 2017-07-06 Reviewer LC end Draft Tim Polk 2017-06-28 draft-ietf-trill-rbridge-multilevel-05 Vincent Roca 2017-06-28 draft-ietf-trill-mtu-negotiation-05 Joseph Salowey 2017-06-27 draft-ietf-precis-7613bis-07 Last calls: Reviewer LC end Draft Tobias Gondrom 2017-05-14 draft-ietf-calext-caldav-attachments-02 Hilarie Orman 2017-06-16 draft-ietf-dmm-mag-multihoming-03 Radia Perlman 2017-06-27 draft-ietf-sipcore-content-id-06 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-10 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Catherine Meadows R2017-06-29 draft-ietf-opsawg-capwap-alt-tunnel-09 Next in the reviewer rotation: Tim Polk Vincent Roca Joseph Salowey Rich Salz Yaron Sheffer Rifaat Shekh-Yusef Melinda Shore Robert Sparks Takeshi Takahashi Tina Tsou From nobody Thu Jun 15 14:15:03 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 8F0801294C8; Tue, 6 Jun 2017 07:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1496759765; bh=nWK/LY5ZXpjjY3TQ9l+XXpRD7hDQ/8KQekp7p3arRkE=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=LqELp4sKygILlYbX94g8JOn8pQaIYB9wcK9A1Xd9DP1nSnqSqOFj+upOBrlmf3cNF eT7PZHioPj2v/WEUt8DMHddmaliMuXMxYeCLqq+YEQX0jTf7LGrs6GNrGqpw15bbEg 1BE27Pl+GssLkYSDHSmn0KZJUmA6CdsRIuRNycz0= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E180812946A for ; Tue, 6 Jun 2017 07:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01] 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 sHMFAjogmhOv for ; Tue, 6 Jun 2017 07:36:02 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B28E1270A0 for ; Tue, 6 Jun 2017 07:35:58 -0700 (PDT) Received: from [221.216.48.160] (helo=[192.168.1.3]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1dIFaO-0006iQ-IP for new-work@ietf.org; Tue, 06 Jun 2017 14:35:56 +0000 To: new-work@ietf.org From: Xueyuan Jia Message-ID: Date: Tue, 6 Jun 2017 22:35:53 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Language: en-GB Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.22 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 15 Jun 2017 14:15:00 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Web Platform Working Group (until 2017-07-05) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 14:36:06 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review a draft charter for the Web Platform Working Group: http://w3c.github.io/charter-html/webplat-wg.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2017-07-05 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [1], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Yves Lafon , or Xiaoqian Wu , Web Platform WG Team Contacts. Thank you, Xueyuan Jia, W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Thu Jun 15 14:15:08 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 7A4A21294F0; Tue, 6 Jun 2017 07:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1496759943; bh=SHQj5FrZbhptSoBLWFDiCZu/kVJYLBCHV2kPnnJWS0w=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=sLdjBtOLYQcNugmo4C9ZIy+F7ff0OA20pIbI2KrL+HDPnuOilY4J/18Pc9ynzwTmJ 2ljwKjxfjLxNPNPMSYPWyyuwlK84Z0z60TOe/EfExUsyHdUN1FYT2OO9UplnGR3Jyx 01D5yMcHozutxd38F8ap5dnAPmaISiJP0v7vnS5k= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E961294F0 for ; Tue, 6 Jun 2017 07:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01] 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 8g_d8mpJ3SOU for ; Tue, 6 Jun 2017 07:39:01 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 860D5129456 for ; Tue, 6 Jun 2017 07:38:59 -0700 (PDT) Received: from [221.216.48.160] (helo=[192.168.1.3]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1dIFdK-0006sA-5P for new-work@ietf.org; Tue, 06 Jun 2017 14:38:58 +0000 To: new-work@ietf.org From: Xueyuan Jia Message-ID: <6ae57b9e-71f8-e4ad-7fb5-345f42aeab12@w3.org> Date: Tue, 6 Jun 2017 22:38:52 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Language: en-GB Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.22 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 15 Jun 2017 14:15:01 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Service Workers Working Group (until 2017-07-05) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 14:39:04 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review a draft charter for the Service Workers Working Group: https://w3c.github.io/charter-drafts/sw-charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2017-07-05 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [1], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Wendy Seltzer, W3C Strategy Lead, at . Thank you, Xueyuan Jia, W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Thu Jun 15 14:15:12 2017 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 680FD131849; Tue, 13 Jun 2017 06:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1497359060; bh=xdn2wMVNgSEnQm0cfknsuufg9mXk2WuN0lObmx42kuA=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=qGybtByvNDnp5XGGU0JKkYnIEjfAVNjexRONB4znJIjv9UMWCn6HXd0hInclZKj3G XBtvP2VRWVrxEGLDpRJckPTht/q3/lCFNOkiw3s1bZLEiJKyjCOqagTJbQrMIf19WZ dsTow+qdQt/gh4+4fAaf8SFjBOdzkwhiNzjE/GYE= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DAA131849 for ; Tue, 13 Jun 2017 06:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01, 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 2zqsFQgENaAk for ; Tue, 13 Jun 2017 06:04:16 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F33131840 for ; Tue, 13 Jun 2017 06:04:16 -0700 (PDT) Received: from [123.118.18.68] (helo=[192.168.1.3]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1dKlUU-0009pz-JV for new-work@ietf.org; Tue, 13 Jun 2017 13:04:14 +0000 To: new-work@ietf.org From: Xueyuan Jia Message-ID: <8f1bf6d4-fc0d-67ca-692b-9c5f9e295e6f@w3.org> Date: Tue, 13 Jun 2017 21:04:10 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Language: en-GB Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.22 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 15 Jun 2017 14:15:01 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: WebAssembly Working Group (until 2017-07-12) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 13:04:20 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review a draft charter for the WebAssembly Working Group: https://w3c.github.io/charter-drafts/webassembly.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2017-07-12 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [1], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Eric Prud'hommeaux, proposed Staff Contact, at . Thank you, Xueyuan Jia, W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Thu Jun 15 19:16:03 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCEF129404 for ; Thu, 15 Jun 2017 19:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdGogTZd60tC for ; Thu, 15 Jun 2017 19:15:50 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0118.outbound.protection.outlook.com [104.47.33.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0AB2127871 for ; Thu, 15 Jun 2017 19:15:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Bo98rZfXjJd5HSQ0UYzGIPQI+CjMWOS/ktbCqBw2dhA=; b=J4UXyX0wp+THmZznu8SHRk0vk1RFqwqZA/oNaLaWV+meg+KO3gsWzWoHAvytlut21+tA/SlSOX+GESuIq4Kct31JyGHXXBxuNUMBWO8S+LqPh60dhrZfnBf4uKfBDBpn15Irns/d1Q84h/9gMRGvogFKF/5/1tOOKg/vYjVGb5I= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0119.namprd21.prod.outlook.com (10.173.189.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.3; Fri, 16 Jun 2017 02:15:47 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1199.007; Fri, 16 Jun 2017 02:15:47 +0000 From: Mike Jones To: Steve KENT , "secdir@ietf.org" CC: Kathleen Moriarty , Eric Rescorla , "secdir@mit.edu" Thread-Topic: SECDIR review of draft-ietf-jones-cose-rsa-03 Thread-Index: AQHS2VoBpt0pt0IJLE6kGvr040XfZKIR/WjggAE84GqAE581MA== Date: Fri, 16 Jun 2017 02:15:46 +0000 Message-ID: References: <13f9d58aea3e4c49aa8367f7eac63d79@CY1PR0601MB023.008f.mgd2.msft.net>, <2a6e1bfad8814c9ca9d0b5ba1a3f457a@CY1PR0601MB023.008f.mgd2.msft.net> In-Reply-To: <2a6e1bfad8814c9ca9d0b5ba1a3f457a@CY1PR0601MB023.008f.mgd2.msft.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetBy=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-15T19:15:45.8253896-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: raytheon.com; dkim=none (message not signed) header.d=none; raytheon.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:9::5ef] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0119; 7:KrEutSRWrKLZrrA0OxEFoCeHUMjun3lQ6Cxu5eFGWfHG5q75qLdl3TAVsD1OzOHnknsG/LoLezwDwwMvWBTS8qkOkslCVnszfETZbs4XkNXjuQIIbZORLK5I6qVbedO1Fl2IqMN8cVnwaX/nNOChB1ukytyQbJn6BGknMsZT+Lmzy9I0914rFdvJfAPD+YoG2lzaRsrIPYc/Em1lsla3Q2mz3mf3NXLe7CKwkuMWz8WCLaRXVvmw1LCrhSVGlg5Nrt2dP24frk2cxR49tH1WJ+X/fNiLMDJlTyplqvzk81SV3DAAhpoCBFzA/0q7b+R16LvSgAyF5wDOaB7JstwvU2LyANoZiCzgQRFNa9ziT2GiQjdshGWpP3cQ/J3gm/Xdl8OfBTTlIzcO3dYjxOJHLDC+9XTsYhawsCQ+u6sF3mN4rKT6f4Cbzg73/IPes/n14sDHLFxn/uCLqZjMQ3SGPCFX1EWGyX/ccNe91HHffw4r4cQuLHgp0Qpz7Z88Rk0tMhOdLYSU/8Vdn+/IaSfyV7NhhRYVC2sbst17JJHOa0AR6Yabki07f5kZfwQA6Je0xoLY6gCZMe7OxFxjS4ofe9MJW4khdssjxYBgsVFeLVNHk4hXwo8EHSvIvLV3gQ1p8EkHqPx8IrB/jX3TFI1H5gC+146mYLvmj8SnBMfseiRUfd/JhTqIQXsIjezGJvg+raS4RqMmPUKPSGiX16V4bSz73g2Hb9odo9eqqRqQ91wq0fJOnlkVg1gpW7m19wmyiBn223QfOnqkQvW2vbpJfR/UPQRGB0uAudt6wj2PjrNe8PrT+UzxvmVGiFaZzFNk x-ms-office365-filtering-correlation-id: 484f6769-bebe-40c5-58f9-08d4b45d99d1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500039)(300135000095)(300000501039)(300135300095)(300000502039)(300135100095)(22001)(2017030254075)(48565401081)(300000503039)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504039)(300135200095)(300000505039)(300135600095)(300000506035)(300135500095); SRVR:CY4PR21MB0119; x-ms-traffictypediagnostic: CY4PR21MB0119: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(31418570063057)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0119; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0119; x-forefront-prvs: 0340850FCD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39400400002)(39410400002)(39840400002)(39860400002)(39450400003)(209900001)(43784003)(377454003)(790700001)(25786009)(606005)(189998001)(2501003)(6436002)(14454004)(53546009)(2906002)(10090500001)(86612001)(5005710100001)(86362001)(8990500004)(4326008)(3660700001)(3280700002)(33656002)(584604001)(39060400002)(6116002)(8936002)(81166006)(122556002)(229853002)(6246003)(6306002)(54896002)(7696004)(53936002)(76176999)(8676002)(2900100001)(102836003)(50986999)(54356999)(230783001)(7906003)(54906002)(72206003)(99286003)(38730400002)(10290500003)(478600001)(966005)(55016002)(2950100002)(5660300001)(7736002)(236005)(77096006)(74316002)(9686003)(53376002)(6506006)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0119; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504FD6F8A39CEBF51CCEEABF5C10CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2017 02:15:47.0112 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0119 Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-jones-cose-rsa-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 02:15:54 -0000 --_000_CY4PR21MB0504FD6F8A39CEBF51CCEEABF5C10CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable https://tools.ietf.org/html/draft-jones-cose-rsa-04 contains the changes we= discussed, Steve. Thanks again for the useful review! -- Mike P.S. I also thanked you in the publication announcement at http://self-iss= ued.info/?p=3D1697 and as @selfissued. From: Steve KENT [mailto:steve.kent@raytheon.com] Sent: Saturday, June 3, 2017 7:36 AM To: Mike Jones ; secdir@mit.edu Cc: Kathleen Moriarty Subject: Re: SECDIR review of draft-ietf-jones-cose-rsa-03 Mike, I think the text you cited re "trust criteria" is good. Yes, let's see what the CFRG suggests re a reference. deleting the last sentence in 6.3 work for me. Steve ________________________________ From: Mike Jones > Sent: Friday, June 2, 2017 4:14:28 PM To: Steve KENT; secdir@mit.edu Cc: Kathleen Moriarty Subject: RE: SECDIR review of draft-ietf-jones-cose-rsa-03 Thanks for your useful review, Steve. Replies are inline below... From: Steve KENT [mailto:steve.kent@raytheon.com] Sent: Tuesday, May 30, 2017 8:34 AM To: secdir@mit.edu Cc: Mike Jones >; Kathleen Moriarty > Subject: SECDIR review of draft-ietf-jones-cose-rsa-03 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written with the intent of improving security requirements and = considerations in IETF drafts. Comments not addressed in last call may be = included in AD reviews during the IESG review. Document editors and WG cha= irs should treat these comments just like any other last call comments. This document defines algorithm encodings and representations for using RSA= algorithms in the context of COSE messages (draft-ietf-cose-msg). Encodin= gs for the use of RSASSA-PSS signatures, RSAES-OAEP encryption, and RSA key= s are specified in this document. This is a very brief document, only 8 pages, including the usual RFC boiler= plate. Most of the document consists of tables specifying the numeric value= s assigned to RSA algorithms (and parameters thereof) used for encryption a= nd signing in the COSE message context. Section 2 defines the parameters for RSASSA-PSS, appropriately citing RFC 3= 447. Section 3 provides analogous specs for RSAES-OAEP. Section 4 defines RSA key pair parameter identifiers, including support fo= r multi-prime RSA keys, based on conventions described in RFC 3447. Security Considerations are the topic of Section 6. Section 6.1 establishes= 2K bit keys as a minimum SHOULD size, but also establishes 16K keys as a m= aximum SHOULD. The text notes that very large keys create a possible DoS at= tack surface, and it suggests (lower case "recommend") that a size check be= performed before beginning crypto operations. The final paragraph of this = subsection includes text that does not seems very useful, as it is too vagu= e. Specifically it says "...no cryptography would be done except with keys = of legitimate parties." The term "legitimate" is too vague to be useful. Do= es it mean that only keys extracted from verified public key certificates o= r acquired through trusted channels are to be employed? The second counterm= easure noted here, i.e., that applications can specified maximum as well as= minimum key sizes, seems much more useful. Rather than talking about "legitimate participants", how about I instead ta= lk about "parties trusted by the recipient" or possibly "after making a tru= st decision about the key"? The notion is that you should only perform cry= pto after making a trust decision about the key. This concept is further s= pelled out in Appendix D (Notes on Key Selection) of RFC 7515 (https://tool= s.ietf.org/html/rfc7515#appendix-D) as: 4. Make trust decisions about the keys. Signatures made with keys not meeting the application's trust criteria would not be accepted. Such criteria might include, but is not limited to, the source of the key, whether the TLS certificate validates for keys retrieved from URLs, whether a key in an X.509 certificate is backed by a valid certificate chain, and other information known by the application. Section 6.2 opens with the following statement: "There is a theoretical has= h substitution attack that can be mounted against RSASSA-PSS." This sentenc= e should include a reference to a paper that describes this attack. I've asked the CFRG for a reference. We'll see what they come up with. I'm thinking that it might also be valuable to add this Security Considerat= ions text about RSASSA-PSS from Section 8.3 of RFC 7518 (https://tools.ietf= .org/html/rfc7518#section-8.3): Keys used with RSAES-PKCS1-v1_5 must follow the constraints in Section 7.2 of RFC 3447= . Also, keys with a low public key exponent value, as described in Section 3 of "Twenty Years of Attacks on the RSA Cryptosystem" [Boneh99], must not be used. Similarly, the closing sentence of Section 6.3 also would benefit from a re= ference to a paper that supports the author's assertion that using SHA-1 in= this context does not enable any (known) attacks. I'm actually thinking that that this sentence should just be deleted, as I = doubt that any supporting references can be found - for the simple reason t= hat you typically can't prove a negative, nor would anybody likely publish = saying "There are no practical attacks yet." Since researchers wouldn't pu= blish this, I probably shouldn't say it in an RFC either. Thanks agai= n, -- Mike --_000_CY4PR21MB0504FD6F8A39CEBF51CCEEABF5C10CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

https://tools.ietf.org/html/draft-jones-cose-rsa-04 cont= ains the changes we discussed, Steve.  Thanks again for the useful rev= iew!

 

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     -- Mike

 

P.S.  I also thanked you in the publication = announcement at http://self-issued.info/?p=3D= 1697 and as @selfissued.

 

 

From: Steve KENT [mailto:steve.kent@= raytheon.com]
Sent: Saturday, June 3, 2017 7:36 AM
To: Mike Jones <Michael.Jones@microsoft.com>; secdir@mit.edu Cc: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Subject: Re: SECDIR review of draft-ietf-jones-cose-rsa-03

 

Mike,

 

I think the text you cited re "trust cr= iteria" is good.

 

Yes, let's see what the CFRG suggests re a r= eference.

 

deleting the last sentence in 6.3 work for m= e.

 

Steve

From: Mike J= ones <Michael.Jones@micro= soft.com>
Sent: Friday, June 2, 2017 4:14:28 PM
To: Steve KENT; secdir@mit.edu=
Cc: Kathleen Moriarty
Subject: RE: SECDIR review of draft-ietf-jones-cose-rsa-03

 

Thanks for your useful review, Steve.=   Replies are inline below…

 

From: Steve KENT [mailto:steve.kent@raytheon.com]
Sent: Tuesday, May 30, 2017 8:34 AM
To: secdir@mit.edu
Cc: Mike Jones <Mi= chael.Jones@microsoft.com>; Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com><= br> Subject: SECDIR review of draft-ietf-jones-cose-rsa-03

 

I have reviewed this doc= ument as part of the security directorate's ongoing effort to review all IE= TF documents being processed by the IESG.  These comments were written= with the intent of improving security requirements and considerations in IETF drafts.  Comments not address= ed in last call may be included in AD reviews during the IESG review. = Document editors and WG chairs should treat these comments just like any o= ther last call comments.

 

This document defines al= gorithm encodings and representations for using RSA algorithms in the conte= xt of COSE messages (draft-ietf-cose-msg).  Encodings for the use of R= SASSA-PSS signatures, RSAES-OAEP encryption, and RSA keys are specified in this document.

 

This is a very brief doc= ument, only 8 pages, including the usual RFC boilerplate. Most of the docum= ent consists of tables specifying the numeric values assigned to RSA algori= thms (and parameters thereof) used for encryption and signing in the COSE message context.

 

Section 2 defines the pa= rameters for RSASSA-PSS, appropriately citing RFC 3447. Section 3 provides = analogous specs for RSAES-OAEP.

 

Section 4 defines RSA ke= y pair parameter identifiers, including  support for multi-prime RSA k= eys, based on conventions described in RFC 3447.

 

Security Considerations = are the topic of Section 6. Section 6.1 establishes 2K bit keys as a minimu= m SHOULD size, but also establishes 16K keys as a maximum SHOULD. The text = notes that very large keys create a possible DoS attack surface, and it suggests (lower case “recommen= d”) that a size check be performed before beginning crypto operations= . The final paragraph of this subsection includes text that does not seems = very useful, as it is too vague. Specifically it says “…no cryptography would be done except with keys of le= gitimate parties.” The term “legitimate” is too vague to = be useful. Does it mean that only keys extracted from verified public key c= ertificates or acquired through trusted channels are to be employed? The second countermeasure noted here, i.e., that applications can specifie= d maximum as well as minimum key sizes, seems much more useful.

&nbs= p;

Rather than talking about “legi= timate participants”, how about I instead talk about “parties t= rusted by the recipient” or possibly “after making a trust deci= sion about the key”?  The notion is that you should only perform cry= pto after making a trust decision about the key.  This concept is furt= her spelled out in Appendix D (Notes on Key Selection) of RFC 7515 (https://tools.ietf.org/= html/rfc7515#appendix-D)  as:

   4.  Make t= rust decisions about the keys.  Signatures made with keys

    &nbs= p;  not meeting the application's trust criteria would not be

    &nbs= p;  accepted.  Such criteria might include, but is not limited to= ,

    &nbs= p;  the source of the key, whether the TLS certificate validates for

    &nbs= p;  keys retrieved from URLs, whether a key in an X.509 certificate

    &nbs= p;  is backed by a valid certificate chain, and other information=

    &nbs= p;  known by the application.

 

Section 6.2 opens with t= he following statement: “There is a theoretical hash substitution att= ack that can be mounted against RSASSA-PSS.” This sentence should inc= lude a reference to a paper that describes this attack.

 

I’ve asked the CFRG for a reference.  We’= ;ll see what they come up with.

 

I’m thinking that it might also be valuable to add = this Security Considerations text about RSASSA-PSS from Section 8.3 of RFC = 7518 (https://t= ools.ietf.org/html/rfc7518#section-8.3):

 =

   Keys=
 used with RSAES-PKCS1-v1_5 must follow the constraints in
   Section 7.2 of=
 RFC 3447.  Also, keys with a low public key exponent
   valu=
e, as described in Section 3 of "Twenty Years of Attacks on the

   RSA =
Cryptosystem" [=
Boneh99], must not be used.


 


Similarly, the closing s=
entence of Section 6.3 also would benefit from a reference to a paper that =
supports the author’s assertion that using SHA-1 in this context does=
 not enable any (known) attacks.

 

I’m actually thinking that that= this sentence should just be deleted, as I doubt that any supporting refer= ences can be found – for the simple reason that you typically can’t prove a negative, nor would anybody likely publish s= aying “There are no practical attacks yet.”  Since researc= hers wouldn’t publish this, I probably shouldn’t say it in an R= FC either.

 

      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       Thanks again,

      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       -- Mike

 

--_000_CY4PR21MB0504FD6F8A39CEBF51CCEEABF5C10CY4PR21MB0504namp_-- From nobody Thu Jun 15 20:47:33 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 C7A99128B91; Thu, 15 Jun 2017 20:47:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liang Xia To: Cc: draft-ietf-avtcore-rfc5285-bis.all@ietf.org, ietf@ietf.org, avt@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149758483978.11296.2498869353473500417@ietfa.amsl.com> Date: Thu, 15 Jun 2017 20:47:19 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-avtcore-rfc5285-bis-12 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, 16 Jun 2017 03:47:20 -0000 Reviewer: Liang Xia Review result: Ready This document is ready to be published as a Standards Track document. This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session. This document obsoletes RFC5285. This document has addressed all the issues I raised in Secdir review of -09 version, and is a well written now. I don't have any more comments. From nobody Thu Jun 15 22:39:53 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 51AAB1200F3; Thu, 15 Jun 2017 22:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JiDu0ejswe8H; Thu, 15 Jun 2017 22:39:44 -0700 (PDT) Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF2B21293D9; Thu, 15 Jun 2017 22:39:41 -0700 (PDT) Received: from in01.mta.xmission.com ([166.70.13.51]) by out01.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1dLjyu-0004Kr-Rb; Thu, 15 Jun 2017 23:39:40 -0600 Received: from [72.250.219.84] (helo=rumpleteazer.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1dLjyt-00038g-Oa; Thu, 15 Jun 2017 23:39:40 -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 v5G5dKf4000835; Thu, 15 Jun 2017 23:39:20 -0600 Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id v5G5dKjP000834; Thu, 15 Jun 2017 23:39:20 -0600 Date: Thu, 15 Jun 2017 23:39:20 -0600 Message-Id: <201706160539.v5G5dKjP000834@rumpleteazer.rhmr.com> From: "Hilarie Orman" Reply-To: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org Cc: draft-ietf-dmm-mag-multihoming.all@ietf.org X-XM-SPF: eid=1dLjyt-00038g-Oa; ; ; mid=<201706160539.v5G5dKjP000834@rumpleteazer.rhmr.com>; ; ; hst=in01.mta.xmission.com; ; ; ip=72.250.219.84; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-AID: U2FsdGVkX1+nuNg9kR9esVtjDLO+SeXs X-SA-Exim-Connect-IP: 72.250.219.84 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ****;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 503 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 3.6 (0.7%), b_tie_ro: 2.4 (0.5%), parse: 1.22 (0.2%), extract_message_metadata: 6 (1.3%), get_uri_detail_list: 2.9 (0.6%), tests_pri_-1000: 4.3 (0.8%), tests_pri_-950: 1.89 (0.4%), tests_pri_-900: 1.54 (0.3%), tests_pri_-400: 29 (5.7%), check_bayes: 27 (5.4%), b_tokenize: 10 (2.0%), b_tok_get_all: 8 (1.5%), b_comp_prob: 3.5 (0.7%), b_tok_touch_all: 3.5 (0.7%), b_finish: 0.73 (0.1%), tests_pri_0: 449 (89.2%), check_dkim_signature: 0.57 (0.1%), check_dkim_adsp: 4.7 (0.9%), tests_pri_500: 3.4 (0.7%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Archived-At: Subject: [secdir] Security review of draft-ietf-dmm-mag-multihoming-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 05:39:46 -0000 Security review of MAG Multipath Binding Option draft-ietf-dmm-mag-multihoming-03.txt 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. If you've been frustrated by being limited to only one IP tunnel between a mobile access gateway and a local mobility anchor, then you'll be glad to know that this draft fixes the problem and enables multiple care-of addresses and IP tunnels. Now mobile devices can be assigned to any applicable tunnel between the MAG and the LMA. For security considerations, the authors predictably defer to RFC5213, "Proxy Mobile IPv6", and assert "no impact on the protocol security". However, there is one security issue that is mentioned in RFC5213 that is exacerbated by the current draft. I.e., To address the threat related to a compromised mobile access gateway, the local mobility anchor, before accepting a Proxy Binding Update message for a given mobile node, may ensure that the mobile node is attached to the mobile access gateway that sent the Proxy Binding Update message. The RFC has no recommendation for a solution, but because there are now multiple tunnels, this assurance may be more difficult to obtain. For example, if the LMA expects to contact some kind of trusted entity that is keeping track of the mobile devices that the MAG is sending on a tunnel, then the MAG and LMA may now have to keep track of multiple trusted entities, one for each tunnel. Whether or not this is a realistic scenario is not something that I can judge because RFC5213 punts on what seems to be an important security issue. Is there any reason to worry about reuse of CoAs? Could packets from one tunnel get a CoA that was recently used by another tunnel, and could delayed packets get routed through the wrong tunnel? Just asking. Nits. On page 3 there is a paragraph beginning "In the continuation of c, a Proxy Mobile IPv6 ..." There is no explanation of "c". Is this a remnant of a list of items "a, b, c"? On page 4 there is Figure 1 showing four flows and two tunnels. The text immediately preceding that says that "Flow-1,2 and 3 are distributed either on Tunnel-1 (over LTE) or Tunnel-2 (over WLAN)", but the diagram shows Flow-1 on Tunnel-1 and Flow-2,3 on Tunnel-2. I think the text should indicate that the first three flows are each assigned to a single tunnel. The authors probably meant that either Tunnel-1 or Tunnel-2 could have been assigned, but the choice was to put Flow-1 on Tunnel-1 and the other flows on Tunnel-2. I had to read over the text several times before I was sure of the intent. Hilarie From nobody Thu Jun 22 10:48: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 BABD1128BB7; Thu, 22 Jun 2017 10:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7gIlcOzcnsQP; Thu, 22 Jun 2017 10:48:42 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEA491252BA; Thu, 22 Jun 2017 10:48:41 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 3711728B003B; Thu, 22 Jun 2017 13:48:41 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id D3F1B1F8036; Thu, 22 Jun 2017 13:48:40 -0400 (EDT) From: Sandra Murphy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jun 2017 13:48:38 -0400 Message-Id: To: IETF Security Directorate , draft-ietf-pals-p2mp-pw-lsp-ping@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [secdir] secdir review of draft-ietf-pals-p2mp-pw-lsp-ping-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 17:48:44 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is No Concerns except Nits for the draft. This draft introduces a new sub-TLD to LSP-PIMG for P2MP, for the = purpose of monitoring P2PM PW. Note: there is quite a deep stack of RFCs on which this draft is based. = I read a lot of them but not all and I can't claim that I now understand how this all works. Take that = into consideration in my comments. --Sandy Nits: There are many use or non-use of "a" and "the", leaving the reader = confused as to whether one or many of the objects are being discussed. There are related mismatches of = subject and verb. A few examples: P2MP PWs are carried over P2MP MPLS LSP - PWs over a LSP? over LSPs in = general? One PW over multiple LSPs? The P2MP MPLS LSP are - LSP is or LSPs are receiver at P2MP MPLS LSP tail - at a tail? at the tails? and so forth. There is a terminology section that covers basic concepts like ATM and = LSR, but not acronyms used here like ACH, T-PW, AC, GAL, etc are not mentioned. I could not find the term P-tree in the references. Web searches found = one vendor's literature and presentations that use that term. If it is vendor specific, it should be changed. section 5 says: The LSP Ping Echo request IPv4/UDP packets is encapsulated with the MPLS label stack as described in previous sections, followed by = one of the two encapsulation options: Section 6 says For an Aggregate Inclusive P-tree arrangement, the echo request packet is sent over the P2MP MPLS LSP with one of the following two encapsulation options: I could not resolve the two encapsulation options, whether these were = two cases each with its own pair of choices, or one encapsulation encapsulated in the other. It could be made = clearer. The security consideration section says it introduces no new "security = considerations" beyond those that apply to RFC6425. It is true it introduces no new vulnerabilities, but it does = introduce a new set of objects (P2MP PWs) that could be affected by any security issues in RFC6425. RFC6425 introduces the TLVs and sub-TLVs to LSP PING for the purpose of = monitoring P2MP LSPs. Its security considerations section says it does not introduce "security concerns" = beyond those described in RFC4379. It is probably true it introduces no new vulnerabilities, but it does = introduce a new set of objects (P2MP LSPs) that could be affected by any security issues in RFC4379. RFC4379 (LSP Ping) security considerations section covers several points = about the security of LSP Ping. The following is a concern over an apparent lack of concern in the stack = of RFCs on which this draft is based - for which this draft is not responsible. I can hardly blame this draft for some issue I have in the deep stack of = RFCs on which it builds. RFC4379 says in part that Unsophisticated replay and spoofing attacks involving faking or replaying MPLS echo reply messages are unlikely to be effective. These replies would have to match the Sender's Handle and Sequence Number of an outstanding MPLS echo request message. A non-matching replay would be discarded as the sequence has moved on, thus a spoof has only a small window of opportunity. However, to provide a stronger defense, an implementation MAY also validate the TimeStamp Sent by requiring and exact match on this field. It is not clear to me that this includes consideration of actions by a legitimate LSP Ping participant. A legitimate LSP Ping participant is in a position in an AS to easily produce spoofed echo requests or to spoof replies to a echo request because it sees the echo requests to which it replies. Consequences of spoofing a request or, particularly, a reply (or in P2PM = LSP, a bunch of replies) are not mentioned. Operators I've asked usually say that MPSL is not generally used between ASs. However, inter-AS use of LSP-Ping is mentioned in many of the tree = of RFCs on which this draft is built - 4379 and 7117, also found in 8029, = 6074, 6514, 7582, 7899, 7900... And many web searches find vendor = documentation and operator tutorial sites about the use of inter-AS LSPs - there = appear to be three options, one of which is to let the signalling protocols pass = between the ASs. I don't know how widely that would be useful (the responses of the = operators I've spoken to seem to indicate it is not widely used). But the consequences of a legitimate but misbehaving LSP Ping speaker in one AS affecting the ops and management of another ought to be mentioned somewhere, somehow, at least as a cautionary "don't shoot yourself"= From nobody Thu Jun 22 15:43:32 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 15C9C129496; Thu, 22 Jun 2017 15:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VH8RO4rlcQQn; Thu, 22 Jun 2017 15:43:27 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0098.outbound.protection.outlook.com [104.47.41.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DA49127868; Thu, 22 Jun 2017 15:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3oZKMAHgnUcNOd4hk+vsu5Wp1R4P6iaHYo3Y1DAM4f4=; b=G8Kd/iPi4QHeRmSD/GjNloQYEL4aH9sJBJc0WZNIZkcHfuq3NgKcRYmmN9aBhSBtJBckbKd1MBymPSCGGtmmQsgVVu0hJk5UAzKsiNDg1su9hN20UlAgZ5lxPCI/n4rqs9oWeoNTeIZPfUXON4CHCo4SVoZgErGyR9Cn5kkCOeE= Received: from CO2PR05MB2774.namprd05.prod.outlook.com (10.166.200.26) by CO2PR05MB2712.namprd05.prod.outlook.com (10.166.200.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.10; Thu, 22 Jun 2017 22:43:22 +0000 Received: from CO2PR05MB2774.namprd05.prod.outlook.com ([10.166.200.26]) by CO2PR05MB2774.namprd05.prod.outlook.com ([10.166.200.26]) with mapi id 15.01.1178.023; Thu, 22 Jun 2017 22:43:22 +0000 From: Santosh Esale To: Yoav Nir , "secdir@ietf.org" CC: "mpls@ietf.org" , "ietf@ietf.org" , "BRUNGARD, DEBORAH A" , "draft-ietf-mpls-app-aware-tldp.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-mpls-app-aware-tldp-08 Thread-Index: AQHS4KDQZGAu47rNb06vXUX2WNUYyKIxG0oA Date: Thu, 22 Jun 2017 22:43:22 +0000 Message-ID: References: <149695844237.15142.17304755568511932911@ietfa.amsl.com> In-Reply-To: <149695844237.15142.17304755568511932911@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO2PR05MB2712; 7:zPg/aRa9PQ6EjbAn1rptM8EEkl25dn7rbwOwy9eL87yBany9y5/0/3G2xl17WvmVbHrXi9D4+9nqUoggHfSdGXlUFZrYPSVlu7WWoloduz6JU1hCt0MVl4GHzJIaqDeqsI0cKrKs0jK8SEF+kojFwNc1b1yPGfpQ9LXN+DTfGFvJiHOKzuCwXpCAdRGdUqInHP1GstP1eTsU2W6Uzfuloeu6mLMzhSfMeigR6dEuSw7rUpGascXSuYHZtrJId+NgNJgqNQqpEhXugCQbrH4R1TC7Cl7rMzhMVP06eFbTTkoerB3P/Dm1KtRoz9CrIYQIOco87cbYabUJqZon+u5ymm0dQtNA22/D2fev4PtRm5WJj6l2p6fBocarR8xRyf9N3eYRKf4BkhGYH+BbS+UP81YT2fzTaMVB1WqavrONNCFc4HaKKYUPL01S36DDxhnWhfA7XukYSkv8eO8kR5TGNF61zTebPwhPcjvz9ORfreO/qO9zh5s60J42FrTEO/9768R6mtyWss/0WDi+Z3bs0l3INUTHMWmqD3UelyTQJ3iUPDjVDMHdilAWtckVsuttjtDrYmf4QpHrbQgXXDE6Ya2QGDt//DDSVRND57OP6Wm2tgvXPWpORjf6FHWOvnZ3DzxfAetcRnEg/5SFhwbu9LNtnzz+6aEqVTEz/CtnF0XtEtMoxfyU8ZCZVz6N73N8zqg/C+bnJn85+RAtyb+L12UNH20LlB4KGkTefK9J4VaW2sSD4ROC+V2HekmHJUhYUe1LGvaKn8f6zBcXXmxZC4gYxVpy8o0C10u8AIu8OCY= x-ms-office365-filtering-correlation-id: f268fd6a-9ff5-415c-b7e2-08d4b9c0162c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CO2PR05MB2712; x-ms-traffictypediagnostic: CO2PR05MB2712: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CO2PR05MB2712; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CO2PR05MB2712; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39410400002)(39840400002)(39850400002)(39450400003)(39860400002)(24454002)(377454003)(122556002)(54356999)(76176999)(50986999)(38730400002)(39060400002)(2900100001)(54906002)(189998001)(6246003)(6512007)(305945005)(345774005)(53546010)(53936002)(25786009)(229853002)(8936002)(2906002)(8676002)(81166006)(3846002)(83506001)(6506006)(5660300001)(478600001)(4001350100001)(14454004)(2950100002)(6116002)(36756003)(102836003)(3280700002)(6436002)(230783001)(66066001)(4326008)(99286003)(2501003)(77096006)(3660700001)(7736002)(86362001)(6486002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2712; H:CO2PR05MB2774.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <18E78FFDEF8011419B26FF1F80A43B53@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2017 22:43:22.2190 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2712 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-mpls-app-aware-tldp-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, 22 Jun 2017 22:43:30 -0000 SGkgWW9hdiwNCiAgICAgICBUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuIFBsZWFzZSBmaW5kIGNv bW1lbnRzIGlubGluZS4NCg0KT24gNi84LzE3LCAyOjQ3IFBNLCAiWW9hdiBOaXIiIDx5bmlyLmll dGZAZ21haWwuY29tPiB3cm90ZToNCg0KPlJldmlld2VyOiBZb2F2IE5pcg0KPlJldmlldyByZXN1 bHQ6IEhhcyBOaXRzDQo+DQo+SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBv ZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncw0KPm9uZ29pbmcNCj5lZmZvcnQgdG8gcmV2aWV3 IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuIFRoZXNlDQo+ Y29tbWVudHMNCj53ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUg c2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuDQo+RG9jdW1lbnQNCj5lZGl0b3JzIGFuZCBXRyBjaGFp cnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXINCj5sYXN0 IGNhbGwNCj5jb21tZW50cy4NCj4NCj5NeSBiaWdnZXN0IGlzc3VlIHdpdGggdGhpcyBkb2N1bWVu dCBpcyB0aGF0IGl0IGlzIGhhcmQgdG8gcmVhZC4gIEZvcg0KPmV4YW1wbGUsDQo+dGhlIEludHJv ZHVjdGlvbiBleHBhbmRzIHRMRFAgdG8gInRhcmdldGVkIExEUCIsIGFuZCB0aGUgSW50cm9kdWN0 aW9uDQo+YmVnaW5zDQo+d2l0aCAiTERQIHVzZXMgZXh0ZW5kZWQgZGlzY292ZXJ5Li4uIiwgYnV0 IExEUCBpdHNlbGYgaXMgb25seSBleHBhbmRlZCB0bw0KPiJsYWJlbCBkaXN0cmlidXRpb24gcHJv dG9jb2wiIGluIHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zIHNlY3Rpb24uDQoNClVwZGF0ZWQgdGV4 dCBhcyDigJxSZWNlbnQgdGFyZ2V0ZWQgTGFiZWwgRGlzdHJpYnV0aW9uIFByb3RvY29sICh0TERQ KQ0KYXBwbGljYXRpb25zIC4uIg0KDQo+U2ltaWxhcmx5LA0KPnRoZSBtdWNoLW92ZXJsb2FkZWQg dGVybSAiYXBwbGljYXRpb24iIGlzIG5ldmVyIGV4cGxhaW5lZCBleGNlcHQgdGhhdCBzb21lDQo+ YXBwbGljYXRpb25zIGFyZSAidGFyZ2V0ZWQiIGFuZCB0aGF0ICJGRUMgMTI4IHBzZXVkb3dpcmUi IGlzIGFuIGV4YW1wbGUNCj5vZiBhbg0KPmFwcGxpY2F0aW9uLiAgSSBhbSBzdXJlIHRoaXMgbWFr ZXMgc2Vuc2UgdG8gcGFydGljaXBhbnRzIG9mIHRoZSBNUExTDQo+d29ya2luZw0KPmdyb3VwLCBi dXQgdG8gb3RoZXJzIHRoaXMgaXMgbXVjaCBoYXJkZXIuIFRoZXJlIG5lZWRzIHRvIGJlIGF0IGxl YXN0IGENCj5yZWZlcmVuY2UgdG8gUkZDIDUwMzYgd2hlcmUgdGhlc2UgdGVybXMgYXJlIGJldHRl ciBleHBsYWluZWQgKFJGQyA1MDM2IGlzDQo+cmVmZXJlbmNlZCBidXQgb25seSBhcyB0aGUgZG9j dW1lbnQgd2hlcmUgdExEUCBhZGphY2VuY3kgaXMgZGVzY3JpYmVkKS4NCg0KUmVmZXJlbmNlZCBS RkM1MDM2IGluIHRoZSBzZWNvbmQgcGFyYWdyYXBoIHRoYXQgaW50cm9kdWNlcyB0aGUgYXBwbGlj YXRpb24NCmtleXdvcmQuDQoiQXBwbGljYXRpb25zIFtSRkM1MDM2XSBzdWNoIGFzIFJlbW90ZSBM RkEgYW5kIEJHUCBhdXRvIGRpc2NvdmVyZWTigKYiDQo+DQo+Tml0czoNCj5UaGUgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMgc2VjdGlvbiBiZWdpbnMgd2l0aCAiVGhlIENhcGFiaWxpdHkgcHJvY2Vk dXJlDQo+ZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgd2lsbCBhcHBseSBhbmQgZG9lcyBub3Qg aW50cm9kdWNlIGFueSBjaGFuZ2UNCj50byBMRFANCj5TZWN1cml0eSBDb25zaWRlcmF0aW9ucyIu ICBUaGUgcHJvY2VkdXJlIHdpbGwgYXBwbHkgd2hhdD8gIE9yIHdpbGwgYXBwbHkNCj50bw0KPndo YXQ/ICBJIHRoaW5rIHRoZSB3b3JkcyAid2lsbCBhcHBseSBhbmQiIGFyZSBzdXBlcmZsdW91cy4N Cg0KQ29ycmVjdCA6KSBSZW1vdmVkLiBOb3cgaXQgcmVhZHMgYXMgIlRoZSBDYXBhYmlsaXR5IHBy b2NlZHVyZSBkZXNjcmliZWQgaW4NCnRoaXMgDQpkb2N1bWVudCBkb2VzIG5vdCBpbnRyb2R1Y2Ug YW55IGNoYW5nZSB0by4uIg0KPg0KPlRoZSBzZWNvbmQgcGFyYWdyYXBoIHNlZW1zIHRvIGJlIHJl cGVhdGluZyBwYXJ0IG9mIHRoZSAocmF0aGVyIGV4dGVuc2l2ZSkNCj5zZWN1cml0eSBjb25zaWRl cmF0aW9ucyBvZiBSRkMgNTAzNiwgYnV0IGl0IGRvZXMgbm90IHNheSB3aHkgKG9yIGV2ZW4NCj53 aGV0aGVyKQ0KPnRoYXQgcGFydGljdWxhciBhbnRpLURvUyBtZWFzdXJlIGFwcGxpZXMgaW4gcGFy dGljdWxhciB0byB0aGUgbWVjaGFuaXNtDQo+ZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQuIElP VyB3aHkgaXMgdGhpcyBtZWFzdXJlIHNpbmdsZWQgb3V0IGZyb20NCj5hbW9uZyB0aGUNCj50aHJl ZSBwYWdlcyBvZiBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmcm9tIFJGQyA1MDM2Pw0KDQpUaGlz IHBhcnQgb2Ygc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaXMgcmVwZWF0ZWQgYXMgaXQgaXMgcmVs YXRlZCB0bw0KZXh0ZW5kZWQgDQpoZWxsb3MgdGhhdCBhcmUgcmVxdWlyZWQgdG8gZXN0YWJsaXNo IHRMRFAgc2Vzc2lvbi4gVGhlIG1lY2hhbmlzbQ0KZGVzY3JpYmVkIGluIA0KdGhpcyBkb2N1bWVu dCB1cGRhdGVzIHRMRFAgc2Vzc2lvbiBlc3RhYmxpc2htZW50IHByb2NlZHVyZXMuIFRoZSB0ZXh0 IGlzDQp1cGRhdGVkDQp0byBjb3ZleSB0aGUgaW50ZW50aW9uLg0KDQo+VGhlIHRoaXJkIHBhcmFn cmFwaCBpcyBub3QgY2xlYXIgdG8gbWUuIEl0IHRhbGtzIGFib3V0IHR3byBub2RlcyBub3QNCj5l c3RhYmxpc2hpbmcgYSB0TERQIHNlc3Npb24gaWYgdGhleSBkb24ndCBzdXBwb3J0IHRoZSBzYW1l IGFwcGxpY2F0aW9uLiBJDQo+ZG9uJ3QNCj5rbm93IHdoeSB0aGF0IGJlbG9uZ3MgaW4gdGhlIHNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24uIFRoZSBTSE9VTEQNCj5OT1QNCj4oZXN0YWJs aXNoIGEgc2Vzc2lvbikgbWFuZGF0ZSBkZWZpbml0ZWx5IGRvZXMgbm90IGJlbG9uZyB0aGVyZS4N Cg0KUmVtb3ZlZCB0aGUgZW50aXJlIGxpbmUgdGhhdCBzdGF0ZWQgdGhlICdTSE9VTEQgTk9UIHBh cnQnLiBBZ3JlZSwgdGhhdA0KdGV4dCANCmRvZXMgbm90IGJlbG9uZyBoZXJlLiBUaGUgdGhpcmQg cGFyYWdyYXBoIGlzIGFkZGVkIHRvIGFkZHJlc3MgQnJ1bm/igJlzDQpjb21tZW50cyANCmR1cmlu ZyByb3V0aW5nIGRpcmVjdG9yYXRlIHJldmlldy4gVGhlIGludGVudGlvbiBpcyB0byBzdGF0ZSBj bGVhcmx5IC0gVGhlDQpJbml0aWF0aW5nIGFuZCByZWNlaXZpbmcgTFNSIE1VU1Qgb25seSBhZHZl cnRpc2UgVEEtSWRzIHRoYXQgdGhleSBzdXBwb3J0Lg0KDQpUaGUgdXBkYXRlZCBzZWN1cml0eSBw YXJhZ3JhcGggcmVhZHMgYXMgZm9sbG93cyAtDQoNCiAgVGhlIENhcGFiaWxpdHkgcHJvY2VkdXJl IGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IGRvZXMgbm90DQogICBpbnRyb2R1Y2UgYW55IGNo YW5nZSB0byBMRFAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBkZXNjcmliZWQNCmlu IFtSRkM1MDM2XS4NCg0KICAgQXMgZGVzY3JpYmVkIGluIFtSRkM1MDM2XSwgRG9TIGF0dGFja3Mg dmlhIEV4dGVuZGVkIEhlbGxvcywgd2hpY2ggYXJlDQogICByZXF1aXJlZCB0byBlc3RhYmxpc2gg YSB0TERQIHNlc3Npb24sIGNhbiBiZSBhZGRyZXNzZWQgYnkgZmlsdGVyaW5nDQogICBFeHRlbmRl ZCBIZWxsb3MgdXNpbmcgYWNjZXNzIGxpc3RzIHRoYXQgZGVmaW5lIGFkZHJlc3NlcyB3aXRoIHdo aWNoDQogICBFeHRlbmRlZCBEaXNjb3ZlcnkgaXMgcGVybWl0dGVkLiAgRnVydGhlciwgYXMgZGVz Y3JpYmVkIGluIHNlY3Rpb24NCiAgIDUuMiBvZiB0aGlzIGRvY3VtZW50LCBhIExTUiBjYW4gZW1w bG95IGEgcG9saWN5IHRvIGFjY2VwdCBhbGwgYXV0by0NCiAgIGRpc2NvdmVyZWQgRXh0ZW5kZWQg SGVsbG9zIGZyb20gdGhlIGNvbmZpZ3VyZWQgc291cmNlIGFkZHJlc3Nlcw0KICAgbGlzdC4NCg0K ICAgQWxzbyBmb3IgdGhlIHR3byBMU1JzIHN1cHBvcnRpbmcgVEFDLCB0aGUgdExEUCBzZXNzaW9u IGlzIG9ubHkNCiAgIGVzdGFibGlzaGVkIGFmdGVyIHN1Y2Nlc3NmdWwgbmVnb3RpYXRpb24gb2Yg dGhlIFRBQy4gVGhlIGluaXRpYXRpbmcNCiAgIGFuZCByZWNlaXZpbmcgTFNSIE1VU1Qgb25seSBh ZHZlcnRpc2UgVEEtSWRzIHRoYXQgdGhleSBzdXBwb3J0LiBJbg0KICAgb3RoZXIgd29yZHMsIHdo YXQgdGhleSBhcmUgY29uZmlndXJlZCBmb3Igb3ZlciB0aGUgdExEUCBzZXNzaW9uLg0KDQoNClRo YW5rcywNClNhbnRvc2ggKE9uIGJlaGFsZiBvZiBBdXRob3JzKQ0KPg0KPg0KDQo= From nobody Thu Jun 22 18:00:54 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 B0DAB126C83; Thu, 22 Jun 2017 18:00:52 -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 VaeqQbDlhnNj; Thu, 22 Jun 2017 18:00:51 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::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 CC4EF129BBD; Thu, 22 Jun 2017 18:00:50 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id p66so18097199oia.0; Thu, 22 Jun 2017 18:00:50 -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=paq7hmN+QPPBZyg5NFO0TrgTneqTGfgZkyfZJdILZ4k=; b=ir22b0eLLD/HNIbidQYbWz/OAAFNBmRCEwsty0nPpCJX6eH0nLGhdllsFhu4xTPnXs A/xfhlUAFXnWTskEAjDeIfbnNhBNowG3wpCmb6D0ErjuxlJE18eDC9S5fdICyN6MO0qR Y3/YtNVz6udqfIdH23MwREZdjV5PVh3/2bry4lcWhuFj2l+dxTHI9Dv1WvllsspXaR+p B8YDAa04tH/SjvLXY5BYDZROkuwyyDIl6Y0xByGiwVvPs056LEQvKHden8BuqssykW1J NMQDZkxTPGpSW2NWcp2ptgzV4j9pZE1HPuLgMkeRJLZk7fJo1hQrzdX3qWv2DYMsXbBt mPLg== 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=paq7hmN+QPPBZyg5NFO0TrgTneqTGfgZkyfZJdILZ4k=; b=fLPHTwgJndXWyaP5wGAg8u+NyIgBJq30C5ER3TNB7kHAzAYZdqbPLnTEuVD1df3d2s X1HTi4egOFRiH3svlgO/5J5F84+Y41tvcn9EUCfvHtIwDIjbccUT1WKVwQItqKOsGEpe TXch2mRqehUVpksjaZnFXmfLVNfY33d/8QSoB1dl0atlIG1ePu4GmEdswgb8eSVOLjgT wU3xWkWdMgwsp0Ld+hRyo/VYA7oDSg8UdojaqB4Xb/Toj62CNEUMly/cvjOq9gGGZQRI 7ww7ywZOIsmRwQcO5Iw+ekg6BtK+O/e2M9LVePL7603mSI37VtTi/gRPF733W9Hqpasc kr3w== X-Gm-Message-State: AKS2vOzq3tBe8PLtBv6c/U1sn8ZeXAKWqPzxKl0GYA8ktUhfRPv83az9 4M+MIsVPLRjRchv5kw68eaB31gspf+// X-Received: by 10.202.237.199 with SMTP id l190mr2442606oih.128.1498179649900; Thu, 22 Jun 2017 18:00:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.145.37 with HTTP; Thu, 22 Jun 2017 18:00:49 -0700 (PDT) From: Radia Perlman Date: Thu, 22 Jun 2017 18:00:49 -0700 Message-ID: To: draft-ietf-sipcore-content-id.all@ietf.org, The IESG , "secdir@ietf.org" Content-Type: multipart/alternative; boundary="001a113d265ad7a2cd055296217b" Archived-At: Subject: [secdir] secdir review of draft-ietf-sipcore-content-id-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, 23 Jun 2017 01:00:53 -0000 --001a113d265ad7a2cd055296217b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These 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. What this RFC does is define a syntax that allows a part of a SIP message to refer to another part of the SIP message. This was previously possible only if the referred-to-part was a body part and this spec generalizes that to allow references to an entire body. It is very difficult to read this by itself, even though it is very short. I'd think it would be better to just make this minor modification to the base RFC. And if we want to have these tiny RFCs, I understand that it's unusual for someone to just read one rather than the whole group...it's really the case of a SECDIR person being assigned a specific RFC that might not be caught up on all the jargon for that WG. However, I think each RFC should be understandable. There ought to be a "context", that includes what other RFCs should be read first, and in particular, either an acronym dictionary or a pointer to an RFC that has explanations for all the acronyms in the little RFC. I found one technical point that seems like an important inconsistency: Section 3.2 says the Content-ID header field must be unique in the context of a given SIP message, while section 3.4.1 says it must be globally unique. The difference is important; globally unique is hard and ugly. I hope that section 3.4.1 is wrong. More examples - with annotations - would be helpful, as would an explanation of how people work around this limitation today. Perhaps also an explanation understandable to an ordinary human as to what problem they are trying to solve and the context in which that problem comes up. Perhaps also worth asking is how the sender of a SIP message is supposed to know whether the recipient of the SIP message can handle this new syntax, and perhaps what it would do if it couldn=E2=80=99t. I suspect they have a = good answer to these questions, but they would be worth stating. The security considerations section says "The Content-ID header field value MUST NOT reveal sensitive user information. If the message-body associated with the Content-ID header field is an encrypted body, it MUST NOT be possible to derive a key that can be used to decrypt the body from the Content-ID header field value." It seems to me that that text should be in the body of the RFC, because it is specifying what must be done, rather than what I usually think of for security considerations, which would say "if you didn't do what we said in section XXX, the following bad things could happen." But as long as peo= ple read the security considerations section, it's OK. Radia --001a113d265ad7a2cd055296217b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed this docu= ment as part of the security directorate's
ongoing effort to review all IETF= documents being processed by the
IESG.=C2=A0 These comments were written primar= ily for the benefit of the
security area directors.=C2=A0 Document editors and W= G chairs should treat
these comments just like any other last call comments.

What this RFC does is define a syntax that allows a p= art of a SIP message to refer to another part of the SIP message. This was = previously possible only if the referred-to-part was a body part and this s= pec generalizes that to allow references to an entire body.

It is very difficult to read this by itself, even though it = is very short.=C2=A0 I'd think it would be better to just make this min= or modification to the base RFC.=C2=A0 And if we want to have these tiny RF= Cs, I understand that it's unusual for someone to just read one rather = than the whole group...it's really the case of a SECDIR person being as= signed a specific RFC that might not be caught up on all the jargon for tha= t WG.=C2=A0 However, I think each RFC should be understandable.=C2=A0 There= ought to be a "context", that includes what other RFCs should be= read first, and in particular, either an acronym dictionary or a pointer t= o an RFC that has explanations for all the acronyms in the little RFC.

I = found one technical point that seems like an important inconsistency: Secti= on 3.2 says the Content-ID header field must be unique in the context of a = given SIP message, while section 3.4.1 says it must be globally unique. The= difference is important; globally unique is hard and ugly. I hope that sec= tion 3.4.1 is wrong.

More examples - with= annotations - would be helpful, as would an explanation of how people work= around this limitation today. Perhaps also an explanation understandable t= o an ordinary human as to what problem they are trying to solve and the con= text in which that problem comes up.
=C2=A0
Perhaps als= o worth asking is how the sender of a SIP message is supposed to know wheth= er the recipient of the SIP message can handle this new syntax, and perhaps= what it would do if it couldn=E2=80=99t. I suspect they have a good answer= to these questions, but they would be worth stating.

<= /div>
The security considerations section says
"The Content-ID header field va= lue MUST NOT reveal sensitive user
   information.

   If the message-body associated with the Content-ID header field is an
   encrypted body, it MUST NOT be possible to derive a key that can be
   used to decrypt the body from the Content-ID header field value."


It seems to me that that text should be in the body of the RFC, be=
cause it
is specifying what must be =
done, rather than what I usually think of for
security considerations, which would say "if you didn't =
do what we said
in section XXX, the =
following bad things could happen."  But as long as people
read the security considerations section, it=
9;s OK.

Radia





--001a113d265ad7a2cd055296217b-- From nobody Fri Jun 23 05:03: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 83A3C128DF3; Fri, 23 Jun 2017 05:03:41 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9jZ_cZ7DVZa; Fri, 23 Jun 2017 05:03:39 -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 9C5E41200C5; Fri, 23 Jun 2017 05:03:38 -0700 (PDT) X-AuditID: c1b4fb2d-edfff7000000080d-3c-594d03987b78 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D8.35.02061.8930D495; Fri, 23 Jun 2017 14:03:36 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.25]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0339.000; Fri, 23 Jun 2017 14:03:35 +0200 From: Christer Holmberg To: Radia Perlman , "draft-ietf-sipcore-content-id.all@ietf.org" , The IESG , "secdir@ietf.org" Thread-Topic: secdir review of draft-ietf-sipcore-content-id-06 Thread-Index: AQHS67wrEUOHkTkxaE620T1+A1izWKIyVWmQ Date: Fri, 23 Jun 2017 12:03:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CC1C55A@ESESSMB109.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CC1C55AESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7t+4MZt9Ig30/LS1mnt3FYjHjz0Rm iy1z3rJafFj4kMWBxWPnrLvsHkuW/GQKYIrisklJzcksSy3St0vgyri1+DdTwa9tjBWTHyxg bGDs2cTYxcjJISFgInHzcQNTFyMXh5DAEUaJ5tX/WSGcxYwS13vfs3cxcnCwCVhIdP/TBomL CJxilHg2ZS8LSFxYwE7i8qkMkEEiAvYSUz9sZ4SwjSSaPjwBs1kEVCXebnrFBmLzCvhKLDw9 DSwuJBAgce3PAVYQm1MgUGLWtkvsIDajgJjE91NrmEBsZgFxiVtP5jNBHCogsWTPeWYIW1Ti 5eN/rBC2kkTjkiesEPX5El0X9rBA7BKUODnzCcsERuFZSEbNQlI2C0nZLKBvmAU0Jdbv0oco UZSY0v2QHcLWkGidM5cdWXwBI/sqRtHi1OLi3HQjY73Uoszk4uL8PL281JJNjMCoOrjlt+4O xtWvHQ8xCnAwKvHw1vz2iRRiTSwrrsw9xCjBwawkwsv4HyjEm5JYWZValB9fVJqTWnyIUZqD RUmc12HfhQghgfTEktTs1NSC1CKYLBMHp1QDo++0n+pWl+/EWFyREqq4rlrZ8Z8vW6MkWODi 5u0JAYZuubfO/lkeOi80dlb1lKhPMzY46u9/vfVYZ9iHVTHLZQR2pFjNWPbm/MHLbROj/4oo tutmdO2q7U2wXNC1scncRbbv947OldM1RVp/HWO55ZX+JEHP8lkXz5M93/cecv1/03dC6rNg DiWW4oxEQy3mouJEAK90vcmmAgAA Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-sipcore-content-id-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, 23 Jun 2017 12:03:41 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CC1C55AESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmFkaWEsDQoNClRoYW5rIFlvdSBmb3IgdGhlIHJldmlldyEgUGxlYXNlIHNlZSBpbmxpbmUu DQoNCj5JIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0 eSBkaXJlY3RvcmF0ZSdzDQo+b25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3Vt ZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlDQo+SUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUg d3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZQ0KPnNlY3VyaXR5IGFyZWEg ZGlyZWN0b3JzLiAgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdA0K PnRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0K Pg0KPldoYXQgdGhpcyBSRkMgZG9lcyBpcyBkZWZpbmUgYSBzeW50YXggdGhhdCBhbGxvd3MgYSBw YXJ0IG9mIGEgU0lQIG1lc3NhZ2UgdG8gcmVmZXIgdG8gYW5vdGhlciBwYXJ0IG9mIHRoZSBTSVAg bWVzc2FnZS4NCj5UaGlzIHdhcyBwcmV2aW91c2x5IHBvc3NpYmxlIG9ubHkgaWYgdGhlIHJlZmVy cmVkLXRvLXBhcnQgd2FzIGEgYm9keSBwYXJ0IGFuZCB0aGlzIHNwZWMgZ2VuZXJhbGl6ZXMgdGhh dCB0byBhbGxvdyByZWZlcmVuY2VzIHRvIGFuIGVudGlyZSBib2R5Lg0KPg0KPkl0IGlzIHZlcnkg ZGlmZmljdWx0IHRvIHJlYWQgdGhpcyBieSBpdHNlbGYsIGV2ZW4gdGhvdWdoIGl0IGlzIHZlcnkg c2hvcnQuICBJJ2QgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIHRvIGp1c3QgbWFrZSB0aGlzIG1p bm9yIG1vZGlmaWNhdGlvbiB0byB0aGUgYmFzZSBSRkMuDQoNClRoZSBXRyBkaXNjdXNzZWQgdGhh dCBhbHRlcm5hdGl2ZSwgYnV0IHRoaXMgd2FzIHRoZSBhZ3JlZWQgd2F5IGZvcndhcmQuDQoNCj5B bmQgaWYgd2Ugd2FudCB0byBoYXZlIHRoZXNlIHRpbnkgUkZDcywgSSB1bmRlcnN0YW5kIHRoYXQg aXQncyB1bnVzdWFsIGZvciBzb21lb25lIHRvIGp1c3QgcmVhZCBvbmUgcmF0aGVyIHRoYW4gdGhl IHdob2xlIGdyb3VwLi4uaXQncyByZWFsbHkNCj50aGUgY2FzZSBvZiBhIFNFQ0RJUiBwZXJzb24g YmVpbmcgYXNzaWduZWQgYSBzcGVjaWZpYyBSRkMgdGhhdCBtaWdodCBub3QgYmUgY2F1Z2h0IHVw IG9uIGFsbCB0aGUgamFyZ29uIGZvciB0aGF0IFdHLiAgSG93ZXZlciwgSSB0aGluaw0KPmVhY2gg UkZDIHNob3VsZCBiZSB1bmRlcnN0YW5kYWJsZS4NCg0KQXMgYSBnZW4tYXJ0IHJldmlld2VyLCBJ IGhlYXIgd2hhdCB5b3UgYXJlIHNheWluZywgYW5kIGluIHRoZSBiZWdpbm5pbmcgSSBtb3JlIG9y IGxlc3MgaGFkIHRoZSBzYW1lIG9waW5pb24uIEhvd2V2ZXIsIGxhdGVyIEkgaGF2ZSByZWFsaXpl ZCB0aGF0IHRvIG1ha2UgZWFjaCBSRkMg4oCcdW5kZXJzdGFuZGFibGXigJ0gb24gaXRzIG93biB3 b3VsZCBtZWFuIGNvcHkvcGFzdGluZyBsb3RzIG9mIHRleHQgZnJvbSBvdGhlciBSRkNzLCBhbmQv b3IgYWRkaW5nIGxvdHMgb2YgY2xhcmlmaWNhdGlvbiB0ZXh0LiBTbywgbm93YWRheXMsIHdoZW4g SSByZXZpZXcgYSBkb2N1bWVudCwgSSB0cnkgdG8gbWFrZSBzdXJlIHRoYXQgdGhlcmUgYXJlIHJl ZmVyZW5jZXMgd2hlcmUgSSBjYW4gZ28gYW5kIGZpbmQgZXh0cmEgaW5mb3JtYXRpb24uDQoNCj5U aGVyZSBvdWdodCB0byBiZSBhICJjb250ZXh0IiwgdGhhdCBpbmNsdWRlcyB3aGF0IG90aGVyIFJG Q3Mgc2hvdWxkIGJlIHJlYWQgZmlyc3QsIGFuZCBpbiBwYXJ0aWN1bGFyLCBlaXRoZXIgYW4gYWNy b255bSBkaWN0aW9uYXJ5IG9yIGENCj5wb2ludGVyIHRvIGFuIFJGQyB0aGF0IGhhcyBleHBsYW5h dGlvbnMgZm9yIGFsbCB0aGUgYWNyb255bXMgaW4gdGhlIGxpdHRsZSBSRkMuDQoNCkkgZ3Vlc3Mg aXQgaXMgYXNzdW1lZCB0aGF0IHRoZSBOb3JtYXRpdmUgUmVmZXJlbmNlcyBwcm92aWRlIHN1Y2gg 4oCcY29udGV4dOKAnS4NCg0KPkkgZm91bmQgb25lIHRlY2huaWNhbCBwb2ludCB0aGF0IHNlZW1z IGxpa2UgYW4gaW1wb3J0YW50IGluY29uc2lzdGVuY3k6IFNlY3Rpb24gMy4yIHNheXMgdGhlIENv bnRlbnQtSUQgaGVhZGVyDQo+ZmllbGQgbXVzdCBiZSB1bmlxdWUgaW4gdGhlIGNvbnRleHQgb2Yg YSBnaXZlbiBTSVAgbWVzc2FnZSwgd2hpbGUgc2VjdGlvbiAzLjQuMSBzYXlzIGl0IG11c3QgYmUg Z2xvYmFsbHkgdW5pcXVlLg0KPlRoZSBkaWZmZXJlbmNlIGlzIGltcG9ydGFudDsgZ2xvYmFsbHkg dW5pcXVlIGlzIGhhcmQgYW5kIHVnbHkuIEkgaG9wZSB0aGF0IHNlY3Rpb24gMy40LjEgaXMgd3Jv bmcuDQoNClNlY3Rpb24gMy40LjEgSVMgd3JvbmcgOikgSXQgd2lsbCBiZSBmaXhlZCBpbiB0aGUg bmV4dCB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudC4NCg0KPk1vcmUgZXhhbXBsZXMgLSB3aXRoIGFu bm90YXRpb25zIC0gd291bGQgYmUgaGVscGZ1bCwgYXMgd291bGQgYW4gZXhwbGFuYXRpb24gb2Yg aG93IHBlb3BsZSB3b3JrIGFyb3VuZA0KPnRoaXMgbGltaXRhdGlvbiB0b2RheS4gUGVyaGFwcyBh bHNvIGFuIGV4cGxhbmF0aW9uIHVuZGVyc3RhbmRhYmxlIHRvIGFuIG9yZGluYXJ5IGh1bWFuIGFz IHRvIHdoYXQgcHJvYmxlbQ0KPnRoZXkgYXJlIHRyeWluZyB0byBzb2x2ZSBhbmQgdGhlIGNvbnRl eHQgaW4gd2hpY2ggdGhhdCBwcm9ibGVtIGNvbWVzIHVwLg0KDQpXZSBkbyB0cnkgdG8gZXhwbGFp biB0aGUgd29yayBhcm91bmQgaW4gc2VjdGlvbnMgMS4zIGFuZCAxLjQuIEJ1dCwgSSBhZ3JlZSB3 ZSBjb3VsZCBhZGQgYWN0dWFsIFNJUCBtZXNzYWdlcyB0byB0aGUgZXhhbXBsZXMgaW4gc2VjdGlv bnMgMS40LjEgYW5kIDEuNC4yIHRvIG1ha2UgaXQgbW9yZSBjbGVhci4NCg0KPlBlcmhhcHMgYWxz byB3b3J0aCBhc2tpbmcgaXMgaG93IHRoZSBzZW5kZXIgb2YgYSBTSVAgbWVzc2FnZSBpcyBzdXBw b3NlZCB0byBrbm93IHdoZXRoZXIgdGhlIHJlY2lwaWVudCBvZg0KPnRoZSBTSVAgbWVzc2FnZSBj YW4gaGFuZGxlIHRoaXMgbmV3IHN5bnRheCwgYW5kIHBlcmhhcHMgd2hhdCBpdCB3b3VsZCBkbyBp ZiBpdCBjb3VsZG7igJl0LiBJIHN1c3BlY3QgdGhleSBoYXZlDQo+YSBnb29kIGFuc3dlciB0byB0 aGVzZSBxdWVzdGlvbnMsIGJ1dCB0aGV5IHdvdWxkIGJlIHdvcnRoIHN0YXRpbmcuDQoNClRoZSBu b3JtYWwgU0lQIHByb2NlZHVyZXMgb2YgUkZDIDMyNjEgYXBwbHkuIEl0IHRoZSBzZW5kZXIgcmVx dWlyZXMgdGhlIHJlY2VpdmVyIHRvIHVuZGVyc3RhbmQgYSBjZXJ0YWluIGV4dGVuc2lvbiAoaGVh ZGVyIGZpZWxkcyBldGMpIGluIG9yZGVyIHRvIGFjY2VwdCB0aGUgbWVzc2FnZSB0aGVyZSBpcyBh IG1lY2hhbmlzbSBmb3IgdGhhdC4NCg0KPlRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0 aW9uIHNheXMNCj4iVGhlIENvbnRlbnQtSUQgaGVhZGVyIGZpZWxkIHZhbHVlIE1VU1QgTk9UIHJl dmVhbCBzZW5zaXRpdmUgdXNlciBpbmZvcm1hdGlvbi4NCg0KPg0KDQo+ICAgSWYgdGhlIG1lc3Nh Z2UtYm9keSBhc3NvY2lhdGVkIHdpdGggdGhlIENvbnRlbnQtSUQgaGVhZGVyIGZpZWxkIGlzIGFu DQoNCj4gICBlbmNyeXB0ZWQgYm9keSwgaXQgTVVTVCBOT1QgYmUgcG9zc2libGUgdG8gZGVyaXZl IGEga2V5IHRoYXQgY2FuIGJlDQoNCj4gICB1c2VkIHRvIGRlY3J5cHQgdGhlIGJvZHkgZnJvbSB0 aGUgQ29udGVudC1JRCBoZWFkZXIgZmllbGQgdmFsdWUuIg0KDQo+DQoNCj5JdCBzZWVtcyB0byBt ZSB0aGF0IHRoYXQgdGV4dCBzaG91bGQgYmUgaW4gdGhlIGJvZHkgb2YgdGhlIFJGQywgYmVjYXVz ZSBpdA0KDQo+aXMgc3BlY2lmeWluZyB3aGF0IG11c3QgYmUgZG9uZSwgcmF0aGVyIHRoYW4gd2hh dCBJIHVzdWFsbHkgdGhpbmsgb2YgZm9yDQoNCj5zZWN1cml0eSBjb25zaWRlcmF0aW9ucywgd2hp Y2ggd291bGQgc2F5ICJpZiB5b3UgZGlkbid0IGRvIHdoYXQgd2Ugc2FpZA0KDQo+aW4gc2VjdGlv biBYWFgsIHRoZSBmb2xsb3dpbmcgYmFkIHRoaW5ncyBjb3VsZCBoYXBwZW4uIiAgQnV0IGFzIGxv bmcgYXMgcGVvcGxlDQoNCj5yZWFkIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9u LCBpdCdzIE9LLg0KDQoNCg0KU28sIEnigJlsbCBrZWVwIHRoZSB0ZXh0IGluIHRoZSBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucy4NCg0KDQoNClJlZ2FyZHMsDQoNCg0KDQpDaHJpc3Rlcg0KDQoNCg0K DQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B4CC1C55AESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw cmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1M UHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tR0I7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIu MHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9 IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5IaSBSYWRpYSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRo YW5rIFlvdSBmb3IgdGhlIHJldmlldyEgUGxlYXNlIHNlZSBpbmxpbmUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+Jmd0 O0kgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRp cmVjdG9yYXRlJ3M8YnI+DQomZ3Q7b25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRv Y3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlPGJyPg0KJmd0O0lFU0cuJm5ic3A7IFRoZXNl IGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZTxi cj4NCiZndDtzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4mbmJzcDsgRG9jdW1lbnQgZWRpdG9ycyBh bmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdDxicj4NCiZndDt0aGVzZSBjb21tZW50cyBqdXN0IGxp a2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjVwdCI+Jmd0O1doYXQgdGhpcyBSRkMgZG9lcyBpcyBkZWZpbmUgYSBzeW50YXggdGhhdCBhbGxv d3MgYSBwYXJ0IG9mIGEgU0lQIG1lc3NhZ2UgdG8gcmVmZXIgdG8gYW5vdGhlciBwYXJ0IG9mIHRo ZSBTSVAgbWVzc2FnZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku NXB0Ij5UaGlzIHdhcyBwcmV2aW91c2x5IHBvc3NpYmxlIG9ubHkgaWYgdGhlIHJlZmVycmVkLXRv LXBhcnQgd2FzIGEgYm9keSBwYXJ0IGFuZCB0aGlzIHNwZWMgZ2VuZXJhbGl6ZXMgdGhhdCB0byBh bGxvdyByZWZlcmVuY2VzIHRvIGFuIGVudGlyZQ0KIGJvZHkuPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+Jmd0O0l0IGlzIHZlcnkg ZGlmZmljdWx0IHRvIHJlYWQgdGhpcyBieSBpdHNlbGYsIGV2ZW4gdGhvdWdoIGl0IGlzIHZlcnkg c2hvcnQuJm5ic3A7IEknZCB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8ganVzdCBtYWtlIHRo aXMgbWlub3IgbW9kaWZpY2F0aW9uIHRvIHRoZSBiYXNlIFJGQy4mbmJzcDsNCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5UaGUgV0cgZGlzY3Vzc2VkIHRoYXQgYWx0ZXJuYXRpdmUsIGJ1dCB0aGlzIHdhcyB0aGUg YWdyZWVkIHdheSBmb3J3YXJkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+Jmd0O0FuZCBp ZiB3ZSB3YW50IHRvIGhhdmUgdGhlc2UgdGlueSBSRkNzLCBJIHVuZGVyc3RhbmQgdGhhdCBpdCdz IHVudXN1YWwgZm9yIHNvbWVvbmUgdG8ganVzdCByZWFkIG9uZSByYXRoZXIgdGhhbiB0aGUgd2hv bGUgZ3JvdXAuLi5pdCdzIHJlYWxseQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS41cHQiPnRoZSBjYXNlIG9mIGEgU0VDRElSIHBlcnNvbiBiZWluZyBhc3NpZ25lZCBh IHNwZWNpZmljIFJGQyB0aGF0IG1pZ2h0IG5vdCBiZSBjYXVnaHQgdXAgb24gYWxsIHRoZSBqYXJn b24gZm9yIHRoYXQgV0cuJm5ic3A7IEhvd2V2ZXIsIEkgdGhpbmsNCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5lYWNoIFJGQyBzaG91bGQgYmUgdW5kZXJzdGFu ZGFibGUuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QXMgYSBnZW4tYXJ0IHJldmlld2VyLCBJIGhl YXIgd2hhdCB5b3UgYXJlIHNheWluZywgYW5kIGluIHRoZSBiZWdpbm5pbmcgSSBtb3JlIG9yIGxl c3MgaGFkIHRoZSBzYW1lIG9waW5pb24uIEhvd2V2ZXIsIGxhdGVyIEkgaGF2ZSByZWFsaXplZCB0 aGF0IHRvIG1ha2UgZWFjaCBSRkMg4oCcdW5kZXJzdGFuZGFibGXigJ0NCiBvbiBpdHMgb3duIHdv dWxkIG1lYW4gY29weS9wYXN0aW5nIGxvdHMgb2YgdGV4dCBmcm9tIG90aGVyIFJGQ3MsIGFuZC9v ciBhZGRpbmcgbG90cyBvZiBjbGFyaWZpY2F0aW9uIHRleHQuIFNvLCBub3dhZGF5cywgd2hlbiBJ IHJldmlldyBhIGRvY3VtZW50LCBJIHRyeSB0byBtYWtlIHN1cmUgdGhhdCB0aGVyZSBhcmUgcmVm ZXJlbmNlcyB3aGVyZSBJIGNhbiBnbyBhbmQgZmluZCBleHRyYSBpbmZvcm1hdGlvbi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS41cHQiPiZndDtUaGVyZSBvdWdodCB0byBiZSBhICZxdW90O2NvbnRl eHQmcXVvdDssIHRoYXQgaW5jbHVkZXMgd2hhdCBvdGhlciBSRkNzIHNob3VsZCBiZSByZWFkIGZp cnN0LCBhbmQgaW4gcGFydGljdWxhciwgZWl0aGVyIGFuIGFjcm9ueW0gZGljdGlvbmFyeSBvciBh PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPnBvaW50ZXIgdG8g YW4gUkZDIHRoYXQgaGFzIGV4cGxhbmF0aW9ucyBmb3IgYWxsIHRoZSBhY3JvbnltcyBpbiB0aGUg bGl0dGxlIFJGQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSBndWVzcyBpdCBpcyBhc3N1bWVkIHRoYXQgdGhl IE5vcm1hdGl2ZSBSZWZlcmVuY2VzIHByb3ZpZGUgc3VjaCDigJxjb250ZXh04oCdLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZndDtJIGZvdW5kIG9uZSB0ZWNobmljYWwgcG9pbnQgdGhhdCBzZWVtcyBsaWtlIGFuIGlt cG9ydGFudCBpbmNvbnNpc3RlbmN5OiBTZWN0aW9uIDMuMiBzYXlzIHRoZSBDb250ZW50LUlEIGhl YWRlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mZ3Q7PC9zcGFuPmZpZWxkIG11c3QgYmUgdW5pcXVlIGluIHRoZSBjb250ZXh0IG9mIGEgZ2l2 ZW4gU0lQIG1lc3NhZ2UsIHdoaWxlIHNlY3Rpb24gMy40LjEgc2F5cyBpdCBtdXN0IGJlIGdsb2Jh bGx5IHVuaXF1ZS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPlRoZSBkaWZmZXJlbmNlIGlzIGltcG9ydGFudDsgZ2xvYmFs bHkgdW5pcXVlIGlzIGhhcmQgYW5kIHVnbHkuIEkgaG9wZSB0aGF0IHNlY3Rpb24gMy40LjEgaXMg d3JvbmcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+U2VjdGlvbiAzLjQuMSBJUyB3cm9uZyA6KSBJdCB3aWxsIGJlIGZpeGVk IGluIHRoZSBuZXh0IHZlcnNpb24gb2YgdGhlIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtNb3Jl IGV4YW1wbGVzIC0gd2l0aCBhbm5vdGF0aW9ucyAtIHdvdWxkIGJlIGhlbHBmdWwsIGFzIHdvdWxk IGFuIGV4cGxhbmF0aW9uIG9mIGhvdyBwZW9wbGUgd29yayBhcm91bmQ8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozwvc3Bhbj50aGlzIGxp bWl0YXRpb24gdG9kYXkuIFBlcmhhcHMgYWxzbyBhbiBleHBsYW5hdGlvbiB1bmRlcnN0YW5kYWJs ZSB0byBhbiBvcmRpbmFyeSBodW1hbiBhcyB0byB3aGF0IHByb2JsZW0NCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPnRoZXkg YXJlIHRyeWluZyB0byBzb2x2ZSBhbmQgdGhlIGNvbnRleHQgaW4gd2hpY2ggdGhhdCBwcm9ibGVt IGNvbWVzIHVwLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPldlIGRvIHRyeSB0byBleHBsYWluIHRoZSB3b3JrIGFyb3VuZCBp biBzZWN0aW9ucyAxLjMgYW5kIDEuNC4gQnV0LCBJIGFncmVlIHdlIGNvdWxkIGFkZCBhY3R1YWwg U0lQIG1lc3NhZ2VzIHRvIHRoZSBleGFtcGxlcyBpbiBzZWN0aW9ucyAxLjQuMSBhbmQgMS40LjIg dG8gbWFrZSBpdCBtb3JlIGNsZWFyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O1BlcmhhcHMgYWxzbyB3b3J0aCBhc2tpbmcg aXMgaG93IHRoZSBzZW5kZXIgb2YgYSBTSVAgbWVzc2FnZSBpcyBzdXBwb3NlZCB0byBrbm93IHdo ZXRoZXIgdGhlIHJlY2lwaWVudCBvZg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+dGhlIFNJUCBtZXNzYWdlIGNhbiBoYW5k bGUgdGhpcyBuZXcgc3ludGF4LCBhbmQgcGVyaGFwcyB3aGF0IGl0IHdvdWxkIGRvIGlmIGl0IGNv dWxkbuKAmXQuIEkgc3VzcGVjdCB0aGV5IGhhdmUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPmEgZ29vZCBhbnN3ZXIgdG8g dGhlc2UgcXVlc3Rpb25zLCBidXQgdGhleSB3b3VsZCBiZSB3b3J0aCBzdGF0aW5nLjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPlRoZSBub3JtYWwgU0lQIHByb2NlZHVyZXMgb2YgUkZDIDMyNjEgYXBw bHkuIEl0IHRoZSBzZW5kZXIgcmVxdWlyZXMgdGhlIHJlY2VpdmVyIHRvIHVuZGVyc3RhbmQgYSBj ZXJ0YWluIGV4dGVuc2lvbiAoaGVhZGVyIGZpZWxkcyBldGMpIGluIG9yZGVyIHRvIGFjY2VwdCB0 aGUgbWVzc2FnZSB0aGVyZQ0KIGlzIGEgbWVjaGFuaXNtIGZvciB0aGF0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mZ3Q7VGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gc2F5czxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZxdW90 OzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj5UaGUgQ29udGVudC1J RCBoZWFkZXIgZmllbGQgdmFsdWUgTVVTVCBOT1QgcmV2ZWFsIHNlbnNpdGl2ZSB1c2VyPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPmluZm9ybWF0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHBy ZT4mZ3Q7PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+Jmd0OzxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IElm IHRoZSBtZXNzYWdlLWJvZHkgYXNzb2NpYXRlZCB3aXRoIHRoZSBDb250ZW50LUlEIGhlYWRlciBm aWVsZCBpcyBhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT4mZ3Q7PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgZW5jcnlwdGVkIGJvZHksIGl0IE1VU1QgTk9UIGJl IHBvc3NpYmxlIHRvIGRlcml2ZSBhIGtleSB0aGF0IGNhbiBiZTxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT4mZ3Q7PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgdXNl ZCB0byBkZWNyeXB0IHRoZSBib2R5IGZyb20gdGhlIENvbnRlbnQtSUQgaGVhZGVyIGZpZWxkIHZh bHVlLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT4mZ3Q7PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+Jmd0Ozxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SXQgc2VlbXMgdG8gbWUgdGhhdCB0aGF0IHRleHQgc2hv dWxkIGJlIGluIHRoZSBib2R5IG9mIHRoZSBSRkMsIGJlY2F1c2UgaXQ8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+Jmd0OzxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+aXMgc3BlY2lmeWlu ZyB3aGF0IG11c3QgYmUgZG9uZSwgcmF0aGVyIHRoYW4gd2hhdCBJIHVzdWFsbHkgdGhpbmsgb2Yg Zm9yPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPiZndDs8c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPnNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLCB3aGljaCB3b3VsZCBzYXkgJnF1b3Q7aWYg eW91IGRpZG4ndCBkbyB3aGF0IHdlIHNhaWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ Jmd0OzxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+aW4gc2VjdGlvbiBYWFgsIHRoZSBmb2xsb3dp bmcgYmFkIHRoaW5ncyBjb3VsZCBoYXBwZW4uJnF1b3Q7Jm5ic3A7IEJ1dCBhcyBsb25nIGFzIHBl b3BsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT4mZ3Q7PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5yZWFkIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLCBpdCdzIE9L LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNvLCBJ4oCZbGwga2VlcCB0aGUgdGV4dCBpbiB0aGUgU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UmVnYXJkcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5DaHJpc3RlcjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B4CC1C55AESESSMB109erics_-- From nobody Fri Jun 23 13:17:21 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 B2832129401; Fri, 23 Jun 2017 13:17:14 -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 GLdz0j8YgBHW; Fri, 23 Jun 2017 13:17: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 0307D12941D; Fri, 23 Jun 2017 13:17:12 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v5NKH7bg023415 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 23 Jun 2017 15:17:08 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CC1C55A@ESESSMB109.ericsson.se> Date: Fri, 23 Jun 2017 15:17:07 -0500 Cc: Radia Perlman , "draft-ietf-sipcore-content-id.all@ietf.org" , The IESG , "secdir@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B4CC1C55A@ESESSMB109.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-sipcore-content-id-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, 23 Jun 2017 20:17:15 -0000 [snip] > On Jun 23, 2017, at 7:03 AM, Christer Holmberg = wrote: >=20 > >It is very difficult to read this by itself, even though it is very = short. I'd think it would be better to just make this minor = modification to the base RFC.=20 > =20 > The WG discussed that alternative, but this was the agreed way = forward. > =20 > >And if we want to have these tiny RFCs, I understand that it's = unusual for someone to just read one rather than the whole group...it's = really > >the case of a SECDIR person being assigned a specific RFC that might = not be caught up on all the jargon for that WG. However, I think > >each RFC should be understandable.=20 > =20 > As a gen-art reviewer, I hear what you are saying, and in the = beginning I more or less had the same opinion. However, later I have = realized that to make each RFC =E2=80=9Cunderstandable=E2=80=9D on its = own would mean copy/pasting lots of text from other RFCs, and/or adding = lots of clarification text. So, nowadays, when I review a document, I = try to make sure that there are references where I can go and find extra = information. > =20 > >There ought to be a "context", that includes what other RFCs should = be read first, and in particular, either an acronym dictionary or a > >pointer to an RFC that has explanations for all the acronyms in the = little RFC. > =20 > I guess it is assumed that the Normative References provide such = =E2=80=9Ccontext=E2=80=9D. > =20 >=20 Would an informational reference to RFC 5411 (The Hitchhiker=E2=80=99s = Guide to SIP) be helpful? Maybe if it were cited early in the = introduction as a place to look for more information about the various = SIP RFCs? Thanks! Ben.= From nobody Fri Jun 23 13:25:35 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 B44111293D9; Fri, 23 Jun 2017 13:25:34 -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, 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=stpeter.im header.b=XuMrT1Iu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nXsYfYp4 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 G-YA7y4yUOSt; Fri, 23 Jun 2017 13:25:32 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 988D112943C; Fri, 23 Jun 2017 13:25:32 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id D9F4C20D2C; Fri, 23 Jun 2017 16:25:31 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 23 Jun 2017 16:25:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=m89Z2sg84W5HEJcRce fmSyCTT/Yym/7rkqtq+2c79JE=; b=XuMrT1IuuJjVAmI3g/XVqcK1dJ6G5JnsdI WaCz1Ya6Hj2InSYP6kankNOznKD/pzojBtwYPRWlggbJYuOzY1e+AonBsixGyqYZ oLQ5hkJ0Xugh0HPCn2S67SnT2T8mcLc7IwoJC3QzsJMOBZ+19+KAs34psMmzHA8R 0fu21ClK5oSpVekNyzqJUlYcqoYmZM44bdsEYghvXkHgbv7UvziVLPssrXha8lyp wyugjYye4xQc8/MQFyLnieWjAYUZRAzjdHQ0K8bGeLI634/a0ywxrELA87B8DNDa dCuNC0aHhLXSdCwvZPhRKNUgz5iDw65AVvabkk2TTHYx7sKJBpmg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=m89Z2sg84W5HEJcRcefmSyCTT/Yym/7rkqtq+2c79JE=; b=nXsYfYp4 9YsJWx8jYfdeU4l4tTzjZv/QfeCOUzWZkqAy+YJmzg72UgdNq4cwmq++7tCmz2FX EDeMO3b/BmLsddiguFVBSKLaE7ZdPNzgyaPfYdjyQJRQgYqaiFcmYIfYhj0bJ2XJ O7W10j6lLUdQIEe2MbRCpgrYh5tipARf8EABDQelZzeTbasBCsYdp0KJUNXwXKIF CIoZRX2l4c5GDc5ssmV5hDsyC4U19Pin/UZRTBZsjIvTEPuuz6niCt5hUF4g36mh NICE3zK70qzNHyftF/nxkkCtQe7iJj25iZpY+GOtQIKJSVAbMR5cNta3NTu4EPtI nkWOh93YvjDQdA== X-ME-Sender: X-Sasl-enc: AvkEJi7ALSA9VHw+2BZ4ozCZ+qc/arQAlXavjCIJO6Ap 1498249531 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 0C24E24009; Fri, 23 Jun 2017 16:25:30 -0400 (EDT) To: John C Klensin , Matthew Miller , secdir@ietf.org References: <149736681626.7439.2555177998557552719@ietfa.amsl.com> <8ea90b99-3005-0afb-da93-63cd1abfc905@stpeter.im> Cc: draft-ietf-precis-7564bis.all@ietf.org, ietf@ietf.org, precis@ietf.org From: Peter Saint-Andre Message-ID: <74ad8473-6036-2965-6833-7d59b0f9b038@stpeter.im> Date: Fri, 23 Jun 2017 14:25:29 -0600 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=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] [precis] Secdir last call review of draft-ietf-precis-7564bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 20:25:35 -0000 Hi John, Thanks for your note, and my apologies for the slow reply. Comments inline. On 6/13/17 7:02 PM, John C Klensin wrote: > > > --On Tuesday, June 13, 2017 17:02 -0600 Peter Saint-Andre > wrote: > >> Hi Matt, thanks for the review - it's much appreciated. >> >> Just so you know: through discussion of Daniel Migualt's >> secdir review of 7700bis (we're progressing them all together >> this time!), I realized that it might be help to add another >> example of visually confusing characters to 7564bis, so I plan >> to mention CYRILLIC SMALL LETTER A U+0430 vs. LATIN SMALL >> LETTER A U+0061 (which will be more familiar to readers than >> the Cherokee characters already in the document). > > Peter, > > I don't want to throw the proverbial spanner in the works, but, > just as things changes just as the original PRECIS documents > were being published, I wonder if some other things that appear > to be in process now could do it to us again. > > For example, consider draft-freytag-troublesome-characters. > Despite having contributed to it and expecting to continue to do > so, I've got some misgivings about the document and proposed > registry as IETF work but, if it were to be adopted, it seems to > me that it would be useful for the PRECIS documents to > normatively reference it, especially for Identifier Class. Given that we're dealing with a seemingly tenuous hypothetical, the best approach might be for that I-D (if eventually published as an RFC) to update the relevant PRECIS and IDNA RFCs? We'll need to do that for the IDNA RFCs anyway because they're not currently under revision, as the PRECIS RFCs are. > To > some extent, that draft is a remedy for some of the issues > raised in the long-stalled draft-klensin-idna-5892upd-unicode70, > but it doesn't make those issues, and the lack of > comprehensiveness of normalization, go away. I'm not sure that anything could make those issues go away. > Probably less important, but it might be advantageous to > incorporate some of the "whatever decisions you make, people > will probably hold you accountable if there are problems" tone > of draft-klensin-idna-rfc5891bis into the PRECIS documents. It > might even be that RFC 7940, possibly supplemented by > draft-freytag-lager-variant-rules, would be a better, or at > least useful alternative, way to present some or all of the > PEECIS rule sets than the current approach. One question in my mind is whether an approach such as that of RFC 7940 is so much better that it's worth scrapping / rewriting the PRECIS bis I-Ds along those lines. Right now it's not even clear what criteria we'd use to judge "better" or "useful" here - presumably specification clarity and precision, algorithmic completeness, and reduced error rates in code implementations might factor into the decision. But I don't sense that we have a good handle on making these decisions yet. Another tradeoff here is making the relatively small fixes to the PRECIS RFCs in a relatively short amount of time (measured in IETF years) vs. making a larger overhaul in a longer amount of time (and whether there is sufficient energy to do so). Given our track record in internationalization, I'd prefer to get these PRECIS fixes done now and then look at a larger effort. > On a somewhat different topic, the Greek, Latin, and Cyrillic > scripts are so closely related that finding examples of pairs of > similar-looking characters is in the low-lying fruit category > because the similarities are not coincidences but the result of > derivation and extensive borrowing (something of the same thing > can be said for the Latin-Cherokee relationship, at least in > printed, rather than cureive, forms). Indeed. > The examples that may be > more scary, just because there is no evolutionary theory to > predict were to look, would be things like the resemblances > among the Latin U+006F, the Lao U+0ED0, the Ethiopic U+12D0, the > New Tai Lue U+19D0, and of course the ASCII/European digit > U+0030 and probably many more, with the group perhaps best > described as "open circle graphemes" or something like that. Well, circles are common enough, so it's reasonable that they'd show up in many different contexts as both letters and numbers (which is why we have confusion between the letter "O" and the number zero even in the basic Latin repertoire) and even as punctuation marks and symbols. But I like the examples you've mentioned and will add them to 7564bis to further illustrate the problem, all the while understanding full well that a complete list of examples or an explanation of why such examples are problematic is outside the scope of this specification (which is why we point to UTR36 and UTS39). Peter From nobody Sat Jun 24 07:03:52 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 7B38F1273E2 for ; Sat, 24 Jun 2017 07:03:50 -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.55.1 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <149831303041.7852.13400625401210958427.idtracker@ietfa.amsl.com> Date: Sat, 24 Jun 2017 07:03:50 -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: Sat, 24 Jun 2017 14:03:50 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-07-06 Reviewer LC end Draft Tim Polk 2017-06-28 draft-ietf-trill-rbridge-multilevel-06 Vincent Roca 2017-06-28 draft-ietf-trill-mtu-negotiation-05 Joseph Salowey 2017-06-27 draft-ietf-precis-7613bis-07 Sean Turner 2017-06-29 draft-ietf-manet-rfc5444-usage-06 David Waltermire 2017-06-29 draft-ietf-bier-architecture-07 For telechat 2017-08-03 Reviewer LC end Draft Rifaat Shekh-Yusef 2017-07-07 draft-ietf-teas-gmpls-lsp-fastreroute-09 Last calls: Reviewer LC end Draft Tobias Gondrom 2017-05-14 draft-ietf-calext-caldav-attachments-02 Ben Laurie R2017-06-29 draft-ietf-avtcore-aria-srtp-09 Rich Salz 2017-07-19 draft-bormann-hybi-ws-wk-00 Yaron Sheffer 2017-07-17 draft-weis-gdoi-rekey-ack-05 Melinda Shore 2017-07-05 draft-ietf-httpbis-early-hints-03 Robert Sparks 2017-07-03 draft-ietf-webpush-vapid-03 Takeshi Takahashi 2017-06-30 draft-ietf-spring-oam-usecase-06 Tina Tsou 2017-06-29 draft-ietf-trill-arp-optimization-08 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-11 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Catherine Meadows R2017-06-29 draft-ietf-opsawg-capwap-alt-tunnel-09 Brian Weis 2017-06-29 draft-ietf-idr-bgp-prefix-sid-06 From nobody Sat Jun 24 08:39:53 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 918FC12441E; Sat, 24 Jun 2017 08:39:47 -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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UDp3wkxNyld; Sat, 24 Jun 2017 08:39:45 -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 0047B1205D3; Sat, 24 Jun 2017 08:39:44 -0700 (PDT) X-AuditID: c1b4fb2d-54bff70000001f08-08-594e87be01fb Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 63.F1.07944.EB78E495; Sat, 24 Jun 2017 17:39:43 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.25]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Sat, 24 Jun 2017 17:39:42 +0200 From: Christer Holmberg To: Ben Campbell CC: Radia Perlman , "draft-ietf-sipcore-content-id.all@ietf.org" , The IESG , "secdir@ietf.org" Thread-Topic: secdir review of draft-ietf-sipcore-content-id-06 Thread-Index: AQHS67wrEUOHkTkxaE620T1+A1izWKIyVWmQgABs9oCAAWVIMA== Date: Sat, 24 Jun 2017 15:39:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CC1E66C@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CC1C55A@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGbFdVHd/u1+kwcbHPBbzO0+zW8w8u4vF YsaficwWW+a8ZbX4sPAhiwOrx85Zd9k9liz5yeQxa+cTlgDmKC6blNSczLLUIn27BK6MT9te MBVcEKlYdGINUwNjj0gXIyeHhICJRNul1exdjFwcQgJHGCXOdX1ignAWM0pcf/mEsYuRg4NN wEKi+582SIOIgJLE8+atLCA1zAKnGCUm9ZxiBakRFrCTuHwqA6LGXmLqh+2MELaTRP/SaWA2 i4CqxIPGK2A2r4CvxPpNT5hBbCGBk4wSm6YVg9icQL2td7pYQWxGATGJ76fWMIHYzALiEree zGeCOFpAYsme88wQtqjEy8f/WCFsJYkV2y+BncwsoCmxfpc+RKuixJTuh+wQawUlTs58wjKB UXQWkqmzEDpmIemYhaRjASPLKkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzAWDq45bfuDsbV rx0PMQpwMCrx8E6o8YsUYk0sK67MPcQowcGsJMLLEw4U4k1JrKxKLcqPLyrNSS0+xCjNwaIk zuuw70KEkEB6YklqdmpqQWoRTJaJg1OqgXHRiXs7amdtX8Papm3tWb1ymoTjvbjTcyyeLGHs nCQWz/bS2fVabu7KiXmHexsOuj44dbFwU7zhx4eza3z2MzOlfZgnvlfXvsjVLU3ncnXOrDxd e/f/JXcXWDxZJeY8bSmzgfmawLKqy3zv/9w33Gb8McTCUWh69ZypUzo+X7/t+/2PhVbczhdK LMUZiYZazEXFiQDWmrS4oQIAAA== Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-sipcore-content-id-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: Sat, 24 Jun 2017 15:39:48 -0000 SGksDQoNCj4+Pkl0IGlzIHZlcnkgZGlmZmljdWx0IHRvIHJlYWQgdGhpcyBieSBpdHNlbGYsIGV2 ZW4gdGhvdWdoIGl0IGlzIHZlcnkgc2hvcnQuICBJJ2QgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVy IHRvIGp1c3QgbWFrZSB0aGlzIG1pbm9yIG1vZGlmaWNhdGlvbiB0byB0aGUgYmFzZSBSRkMuIA0K Pj4gIA0KPj4gVGhlIFdHIGRpc2N1c3NlZCB0aGF0IGFsdGVybmF0aXZlLCBidXQgdGhpcyB3YXMg dGhlIGFncmVlZCB3YXkgZm9yd2FyZC4NCj4+ICANCj4+PiBBbmQgaWYgd2Ugd2FudCB0byBoYXZl IHRoZXNlIHRpbnkgUkZDcywgSSB1bmRlcnN0YW5kIHRoYXQgaXQncyANCj4+PiB1bnVzdWFsIGZv ciBzb21lb25lIHRvIGp1c3QgcmVhZCBvbmUgcmF0aGVyIHRoYW4gdGhlIHdob2xlIA0KPj4+IGdy b3VwLi4uaXQncyByZWFsbHkgdGhlIGNhc2Ugb2YgYSBTRUNESVIgcGVyc29uIGJlaW5nIGFzc2ln bmVkIGEgc3BlY2lmaWMgUkZDIHRoYXQgbWlnaHQgbm90IGJlIGNhdWdodCANCj4+PiB1cCBvbiBh bGwgdGhlIGphcmdvbiBmb3IgdGhhdCBXRy4gIEhvd2V2ZXIsIEkgdGhpbmsgZWFjaCBSRkMgc2hv dWxkIGJlIHVuZGVyc3RhbmRhYmxlLg0KPj4gIA0KPj4gQXMgYSBnZW4tYXJ0IHJldmlld2VyLCBJ IGhlYXIgd2hhdCB5b3UgYXJlIHNheWluZywgYW5kIGluIHRoZSBiZWdpbm5pbmcgSSBtb3JlIG9y IGxlc3MgaGFkIHRoZSBzYW1lIG9waW5pb24uIA0KPj4gSG93ZXZlciwgbGF0ZXIgSSBoYXZlIHJl YWxpemVkIHRoYXQgdG8gbWFrZSBlYWNoIFJGQyDigJx1bmRlcnN0YW5kYWJsZeKAnSBvbiBpdHMg b3duIHdvdWxkIG1lYW4gY29weS9wYXN0aW5nIA0KPj4gbG90cyBvZiB0ZXh0IGZyb20gb3RoZXIg UkZDcywgYW5kL29yIGFkZGluZyBsb3RzIG9mIGNsYXJpZmljYXRpb24gdGV4dC4gU28sIG5vd2Fk YXlzLCB3aGVuIEkgcmV2aWV3IGEgZG9jdW1lbnQsIA0KPj4gSSB0cnkgdG8gbWFrZSBzdXJlIHRo YXQgdGhlcmUgYXJlIHJlZmVyZW5jZXMgd2hlcmUgSSBjYW4gZ28gYW5kIGZpbmQgZXh0cmEgaW5m b3JtYXRpb24uDQo+PiAgDQo+Pj4gVGhlcmUgb3VnaHQgdG8gYmUgYSAiY29udGV4dCIsIHRoYXQg aW5jbHVkZXMgd2hhdCBvdGhlciBSRkNzIHNob3VsZCANCj4+PiBiZSByZWFkIGZpcnN0LCBhbmQg aW4gcGFydGljdWxhciwgZWl0aGVyIGFuIGFjcm9ueW0gZGljdGlvbmFyeSBvciBhIHBvaW50ZXIg dG8gYW4gUkZDIHRoYXQgDQo+Pj4gaGFzIGV4cGxhbmF0aW9ucyBmb3IgYWxsIHRoZSBhY3Jvbnlt cyBpbiB0aGUgbGl0dGxlIFJGQy4NCj4+ICANCj4+IEkgZ3Vlc3MgaXQgaXMgYXNzdW1lZCB0aGF0 IHRoZSBOb3JtYXRpdmUgUmVmZXJlbmNlcyBwcm92aWRlIHN1Y2gg4oCcY29udGV4dOKAnS4NCj4+ ICANCj4+IA0KPiBXb3VsZCBhbiBpbmZvcm1hdGlvbmFsIHJlZmVyZW5jZSB0byBSRkMgNTQxMSAo VGhlIEhpdGNoaGlrZXLigJlzIEd1aWRlIHRvIFNJUCkgYmUgaGVscGZ1bD8gTWF5YmUgaWYgaXQg DQo+IHdlcmUgY2l0ZWQgZWFybHkgaW4gdGhlIGludHJvZHVjdGlvbiBhcyBhIHBsYWNlIHRvIGxv b2sgZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHZhcmlvdXMgU0lQIFJGQ3M/DQoNCkkg YWN0dWFsbHkgaGFkIGEgbG9vayBpbiBSRkMgNTQxMSwgYnV0IGl0IGRvZXNuJ3QgY2xhcmlmeSB0 aGlzLg0KDQpXZSBoYXZlIGRlZmluZWQgbG90cyBvZiBuZXcgU0lQIGhlYWRlciBmaWVsZHMgb3Zl ciB0aGUgeWVhcnMsIGFuZCBJIHRoaW5rIHBlb3BsZSBrbm93IGhvdyB0byAiZml0IiB0aGVtIGlu dG8gdGhlIEFCTkYuIEhhdmluZyBzYWlkIHRoYXQsIElGIHdlIHdhbnQgdG8gY2xhcmlmeSB0aGlz LCBJIHRoaW5rIGl0IHNob3VsZCBiZSBkb25lIGluIDMyNjEsIDU0MTEsIG9yIHNvbWUgb3RoZXIg Z2VuZXJpYyBkb2N1bWVudC4gDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From nobody Sun Jun 25 13:03:14 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62320126BF6 for ; Sun, 25 Jun 2017 13:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYV7sVElGirM for ; Sun, 25 Jun 2017 13:03:12 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C12A71241FC for ; Sun, 25 Jun 2017 13:03:12 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id z22so58725239uah.1 for ; Sun, 25 Jun 2017 13:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=8y+O4Hx34d4YsPPwefjysSO0EU0+Df5uA2B8gF4ByW8=; b=uIJtGcz/gsRErzrPRRolN5S3Y/5RI2Uyt1K1xn8CnJL5scXWeu+ByTD1jUvQPIKYaG 6vLCpENHr9mc1++HbD+A7zbOO5+EV564k/IbhMKV+RHLl5s5g/vG+SCaaA+Hk3m32SL3 zXZHWMQKBl4wz4nv4cl4Dnjzrpt7tjiAvzUJMOxLcUHCXUbT3iXfwPwYObrkLeUP46DW 4hKfe5Kb4qjBJcnBnaC6xnY8N9WNKq0KalUsV3vZttXte3mguevwEfyJAI88VaoEFFHL cmJHYgQjpTWV6QzuTRYm/TdVGCom9VantmZvas0RQAV4q3TP4h7Mm7QeD3FKygzlBRsx gCCg== 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=8y+O4Hx34d4YsPPwefjysSO0EU0+Df5uA2B8gF4ByW8=; b=mD6YJARMInKGMACanBS6U3ZzGU+IwQaSY2vg/9nbqbzBigP/pXPVa/qdK0gSXLW5X/ G/Spdg+3dM/OP1DiVZGF+MmL3nj6YglSqspdzoWa2mYfSzaasMh2fZRfnNMm/cnphXr4 m6TcnAbqcfaeGAIx9gWR0Lbwho6JKKGheHqTjrAmwYXMYz2hpFvw/N/0i5CSyn5bwtIw Li5d5DhA7XKa4ZlYcMvytPXkfXdHehJPmKMmtUFmolbi61QSBYx2viytwSY36gr5TYX7 nLFyZJauHWvCOnbj0k6xjCICsUqPZk80zOyx7VgBlrH4rYg8acCVEEg+zDfrYrHQQRsH T7Yw== X-Gm-Message-State: AKS2vOxI7HsXi+J9qSVnZdWVi9UGz/IeFj1Kl+mBFSnFcG3UdrmYmz3S zN4bPC1s8Hb6UG3QzhRcTl/q6Si1oVnW X-Received: by 10.176.10.13 with SMTP id q13mr10026871uah.54.1498420991530; Sun, 25 Jun 2017 13:03:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.48.13 with HTTP; Sun, 25 Jun 2017 13:03:10 -0700 (PDT) From: Ben Laurie Date: Sun, 25 Jun 2017 21:03:10 +0100 Message-ID: To: The IESG , "secdir@ietf.org" , draft-ietf-avtcore-aria-srtp.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [secdir] Security review of draft-ietf-avtcore-aria-srtp-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: Sun, 25 Jun 2017 20:03:14 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is ready with nits. This is essentially a drop-in replacement of AES for SRTP with ARIA, a cipher I've never heard of. Because it is a drop-in replacement, it uses SHA-1. Probably it would be better practice to update the hash function to something more modern. The I-D also somewhat eccentrically says that no security problems have been found with ARIA whilst referencing a paper on a meet-in-the-middle attack on reduced round ARIA. I am not sure what to make of this, though clearly it is not a fatal flaw. From nobody Sun Jun 25 22:50:08 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 9DCC6127058; Sun, 25 Jun 2017 22:50:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey To: Cc: draft-ietf-precis-7613bis.all@ietf.org, iesg@ietf.org, precis@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149845620057.31750.11952736688634266964@ietfa.amsl.com> Date: Sun, 25 Jun 2017 22:50:00 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-precis-7613bis-07 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, 26 Jun 2017 05:50:01 -0000 Reviewer: Joseph Salowey Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is document is ready with nits. This document is an update to RFC 7613. A few Minor comments: 1. I think it would be good to show the zero-length password is not allowed in table 4 (18 | <> | zero-length password). There are lots of cases where allowing zero-length passwords has led to problems. Disallowing zero-length passwords is helpful. 2. Comparisons of passwords is a touchy subject. I can't think of a case where it would be preferable to do a direct password comparison. In most cases the comparison will be done against a salted-hashed transform of the password or involve some other cryptographic operation. I think it would be good to discuss this briefly in the security considerations section, sample text below "Password Comparison Verification of passwords during authentication will not use the comparison defined in section 4.2.3. Instead cryptographic calculations are performed to verify the password. In most cases the password will be prepared as in section 4.2.1 and meet the rules enforced in section 4.2.2 before the calculations are performed." From nobody Mon Jun 26 04:40:49 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D2A129AF4 for ; Mon, 26 Jun 2017 04:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgMJlO2OGJfz for ; Mon, 26 Jun 2017 04:40:45 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0132.outbound.protection.outlook.com [104.47.0.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 669001272E1 for ; Mon, 26 Jun 2017 04:40:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fGTQKPwGfQDCwc+TSD9Cn4pLUhFSDQW6wMDMqLihfGs=; b=cYQjhrDfzj2WDnGiRnmHnhYaS49pFPFdvP3fYa/0ebsX1IjMaw8vZVbeAfPsctz+8Y0N3+VbroYVz4zX7kQMS4aCvjFo6D6BzGj1QgxsZQL7gR2UPKX80ldlgjV0WDrmJzwykK7xYnKeT/VvXZeXBlIm8IOAb6Asf+XqC0hK8wI= Received: from AM4PR07MB1715.eurprd07.prod.outlook.com (10.166.133.23) by AM4PR07MB1219.eurprd07.prod.outlook.com (10.164.81.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.5; Mon, 26 Jun 2017 11:40:41 +0000 Received: from AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::d832:c9c1:9dfa:23af]) by AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::d832:c9c1:9dfa:23af%13]) with mapi id 15.01.1220.009; Mon, 26 Jun 2017 11:40:41 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: Watson Ladd , "secdir@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@tools.ietf.org" , "iseg@ietf.org" Thread-Topic: Review of draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHS7nEK8Ccj6Q4tyk+FfpziyYjc3g== Date: Mon, 26 Jun 2017 11:40:41 +0000 Message-ID: <3FEF62DE-B27E-4937-95E9-B2AFF1523004@nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; x-originating-ip: [212.88.252.216] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB1219; 7:WmbVLrz3l4UFYtWIJo8vn88c7VwCmXkLptynpeN0Bk+SrJn+ETkKJ0+uJBKGPUlm3xy4bxPW3UP/zHav+N3ARUfCLZf9IO0G2nUXfulancqQMB1Gx6HtM0cN4GEsi663M/Wyj3/mMwd+9adbKOqP4/GaYc//q5RRc7X0GJcGHdCwHrX2u08qf4LOKHYGR9iVItzAQbL5U878hO2upUKIsKSV1CXZ+EUNfYzXy7MocfKB6HkZrkpHv1lcFHFVqIfGOVavBh1K8HYchXyAT904IviCoVJDnT7E2zmeavvCEy5avy7srRaXvd5IE7RoUG2KR4i0gKQ1Fshl6wcETpgQkpxYzAwx+FwnewgYphN5kuAl9EU/YLjXADqHZXtdtws6cnEe4SZkhE2V9NggKg6NG1X5tpbDArclroM1UyLS1YNuKC5g29EMYbJCJeSlpB66SDM8ELB2Wd3GMtf2OKiTMmaF0wR6fxckqbdDFKMd0kzHx8lsvWac2TyZKHrSwap2mU4fxlC04aWMrJ6zSfpjFBK+HeISBp5rPbilWLDuNhDslVKNt1idugVqg/O7zSUIrnRnXQ/nLDf21OBvAvquGYlA8ShSBZ+fN8EPz4ANCkvsPpZiFeq6HG4huLkysthjQOJGAasZ/xH3Ce2bILz9GDtbNSXeLcwVySWt2KUm3w214V6QNsLoWIS1CYJj6MSAyi1rRcd+gWy8k01Xy79eww8+bKqqMsM8/ZCqGBpe3ViLB8x/knca1S+Y/L1vwiUuIoeVAMQd/m2syDlh0VjXGXWHy4sKkWWpA+rqVxxwEXk= x-ms-office365-filtering-correlation-id: 45e27afe-004d-4d3a-3930-08d4bc882cbe x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095); SRVR:AM4PR07MB1219; x-ms-traffictypediagnostic: AM4PR07MB1219: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(278178393323532)(26388249023172)(236129657087228)(192374486261705)(138986009662008)(82608151540597)(62221491112393)(48057245064654)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR07MB1219; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR07MB1219; x-forefront-prvs: 0350D7A55D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39450400003)(39840400002)(39850400002)(39400400002)(39410400002)(43544003)(16064003)(66654002)(2900100001)(6486002)(101416001)(478600001)(14454004)(229853002)(33656002)(83716003)(39060400002)(7736002)(8936002)(53546010)(54356999)(9326002)(8676002)(50986999)(81166006)(66066001)(76176999)(5660300001)(2950100002)(189998001)(25786009)(6436002)(102836003)(3846002)(99286003)(6116002)(82746002)(230783001)(3660700001)(6512007)(6506006)(5250100002)(2501003)(2201001)(53936002)(54896002)(3280700002)(6306002)(6246003)(36756003)(86362001)(38730400002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1219; H:AM4PR07MB1715.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_3FEF62DEB27E493795E9B2AFF1523004nokiacom_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2017 11:40:41.5820 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1219 Archived-At: Subject: Re: [secdir] Review of draft-ietf-v6ops-unique-ipv6-prefix-per-host 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, 26 Jun 2017 11:40:48 -0000 --_000_3FEF62DEB27E493795E9B2AFF1523004nokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgV2F0c29uLA0KDQpNeSBhcG9sb2dpZXMgZm9yIHRoZSBkZWxheSBpbiBhbnN3ZXIuIEl0cyBi ZWVuIGEgaGVjdGljIHRpbWUgZm9yIG1lLiBNYW55IHRoYW5rcyBmb3IgeW91ciByZXZpZXcuDQoN CkkgbW9kaWZpZWQgdGhlIHRleHQgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHRvIGlu Y2x1ZGUgeW91ciBzdWdnZXN0aW9uIHRvIG1ha2UgdGhlIGNvcnJlbGF0aW9uIGJldHdlZW4gYm90 aCBtb3JlIGNsZWFyLg0KDQo8Pg0KICAgICAgICAgICAgICAgIDx0PlRoZSBtZWNoYW5pY3Mgb2Yg SVB2NiBwcml2YWN5IGV4dGVuc2lvbnMgPHhyZWYgdGFyZ2V0PSJSRkM0OTQxIj5SRkM0OTQxPC94 cmVmPg0KICAgICAgICAgICAgICAgICAgaXMgY29tcGF0aWJsZSB3aXRoIGFzc2lnbm1lbnQgb2Yg YW4gVW5pcXVlIElQdjYgUHJlZml4IHBlciBIb3N0Lg0KICAgICAgICAgICAgICAgICAgVGhlIGNv bWJpbmF0aW9uIG9mIGJvdGggSVB2NiBwcml2YWN5IGV4dGVuc2lvbnMNCiAgICAgICAgICAgICAg ICAgIGFuZCBvcGVyYXRvciBiYXNlZCBhc3NpZ25tZW50IG9mIGEgVW5pcXVlIElQdjYgUHJlZml4 IHBlciBIb3N0IHByb3ZpZGVzDQogICAgICAgICAgICAgICAgICBlYWNoIGltcGxlbWVudGluZyBv cGVyYXRvciBhIHRvb2wgdG8gbWFuYWdlIGFuZCBwcm92aWRlIHN1YnNjcmliZXIgc2VydmljZXMN CiAgICAgICAgICAgICAgICAgIGFuZCBoZW5jZSByZWR1Y2VzIHRoZSBleHBlcmllbmNlZCBwcml2 YWN5IHdpdGhpbiBlYWNoIG9wZXJhdG9yIGNvbnRyb2xsZWQgZG9tYWluLg0KICAgICAgICAgICAg ICAgICAgSG93ZXZlciwgYmV5b25kIHRoZSBvcGVyYXRvciBjb250cm9sbGVkIGRvbWFpbiwgSVB2 NiBwcml2YWN5IGV4dGVuc2lvbnMgcHJvdmlkZQ0KICAgICAgICAgICAgICAgICAgdGhlIGRlc2ly ZWQgcHJpdmFjeSBhcyBkb2N1bWVudGVkIGluIDx4cmVmIHRhcmdldD0iUkZDNDk0MSI+UkZDNDk0 MTwveHJlZj4uPC90Pg0KPD4NCg0KVGhhbmtzIGFuZCB0YWtlIGNhcmUsDQoNCkcvDQoNCkZyb206 IFdhdHNvbiBMYWRkIDx3YXRzb25ibGFkZEBnbWFpbC5jb20+DQpEYXRlOiBNb25kYXksIDUgSnVu ZSAyMDE3IGF0IDA3OjEwDQpUbzogInNlY2RpckBpZXRmLm9yZyIgPHNlY2RpckBpZXRmLm9yZz4s ICJkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC5hbGxAdG9vbHMu aWV0Zi5vcmciIDxkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC5h bGxAdG9vbHMuaWV0Zi5vcmc+LCAiaXNlZ0BpZXRmLm9yZyIgPGlzZWdAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZXZpZXcgb2YgZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhv c3QNClJlc2VudC1Gcm9tOiA8YWxpYXMtYm91bmNlc0BpZXRmLm9yZz4sIDx3YXRzb25ibGFkZEBn bWFpbC5jb20+DQpSZXNlbnQtVG86IDxqb2huX2Jyem96b3dza2lAY29tY2FzdC5jb20+LCA8Z3Vu dGVyLnZhbl9kZV92ZWxkZUBub2tpYS5jb20+LCA8cmJvbmljYUBqdW5pcGVyLm5ldD4sIDxsZWVA YXNnYXJkLm9yZz4sIDxmcmVkYmFrZXIuaWV0ZkBnbWFpbC5jb20+LCA8YmNsYWlzZUBjaXNjby5j b20+LCA8d2FycmVuQGt1bWFyaS5uZXQ+LCBSb24gQm9uaWNhIDxyYm9uaWNhQGp1bmlwZXIubmV0 PiwgPGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LmFsbEBpZXRm Lm9yZz4NClJlc2VudC1EYXRlOiBNb25kYXksIDUgSnVuZSAyMDE3IGF0IDA3OjM0DQoNCkkgaGF2 ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9y YXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBw cm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFy aWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuICBEb2N1 bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1 c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpUaGUgc3VtbWFyeSBvZiB0 aGUgcmV2aWV3IGlzIHRoYXQgdGhpcyBkb2N1bWVudCBpcyBoYXMgb25lIHN1YnN0YW50aWFsIGlz c3VlIHBsdXMgYSBmb3JtYXR0aW5nIG5pdDogdGhlIGF1dGhvciBuYW1lcyBhcmUgcnVubmluZyBp bnRvIHRoZSB0aXRsZS4gUGVyaGFwcyB0aGlzIGNhbiBiZSBmaXhlZA0KDQpUaGUgc3Vic3RhbnRp YWwgY29tbWVudCBpcyB0aGF0IHRoZSBpbnRlcmFjdGlvbiBvZiBwcml2YWN5IGFkZHJlc3NlcyB3 aXRoIGdpdmluZyBlYWNoIHN1YnNjcmliZXIgYSB1bmlxdWUgSVB2NiBhZGRyZXNzIHByZWZpeCBz cGFjZSBpcyBub3QgZGlzY3Vzc2VkIGluIHRoaXMgZG9jdW1lbnQgYXQgYWxsLiBUaGlzIHNlZW1z IGxpa2UgYSBzZWN1cml0eSBpc3N1ZSB0aGF0IHNob3VsZCBiZSBhZGRyZXNzZWQgYXMgaXQgcmVk dWNlcyBwcml2YWN5IGNvbXBhcmVkIHRvIGEgc2hhcmVkIHByZWZpeCBmb3IgYWxsIHVzZXJzLiAo T3IgbWF5YmUgSSBhbSBjb21wbGV0ZWx5IHdyb25nOiBJIGRvIG5vdCBrbm93IElQdjYgaW4gZ3Jl YXQgZGV0YWlsKS4gQXQgbWluaW11bSBpdCBzaG91bGQgYmUgZGlzY3Vzc2VkIGluIHRoZSBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLCBldmVuIGlmIGV4cGxpY2l0bHkgZGlzbWlzc2Vk Lg0KDQpTaW5jZXJlbHksDQpXYXRzb24NCg== --_000_3FEF62DEB27E493795E9B2AFF1523004nokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: <05F915446622E94DB3ADD373443C7C06@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5z DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjU5NS4wcHQgODQyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJF Ti1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIFdh dHNvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5NeSBhcG9sb2dpZXMgZm9yIHRoZSBkZWxheSBp biBhbnN3ZXIuIEl0cyBiZWVuIGEgaGVjdGljIHRpbWUgZm9yIG1lLiBNYW55IHRoYW5rcyBmb3Ig eW91ciByZXZpZXcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBtb2RpZmllZCB0aGUgdGV4dCBp biB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgdG8gaW5jbHVkZSB5b3VyIHN1Z2dlc3Rpb24g dG8gbWFrZSB0aGUgY29ycmVsYXRpb24gYmV0d2VlbiBib3RoIG1vcmUgY2xlYXIuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+Jmx0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmx0O3QmZ3Q7VGhlIG1lY2hhbmljcyBvZiBJUHY2IHByaXZhY3kgZXh0 ZW5zaW9ucyAmbHQ7eHJlZiB0YXJnZXQ9JnF1b3Q7UkZDNDk0MSZxdW90OyZndDtSRkM0OTQxJmx0 Oy94cmVmJmd0Ow0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZu YnNwOyZuYnNwO2lzIGNvbXBhdGlibGUgd2l0aCBhc3NpZ25tZW50IG9mIGFuIFVuaXF1ZSBJUHY2 IFByZWZpeCBwZXIgSG9zdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJm5ic3A7IFRoZSBjb21iaW5hdGlvbiBvZiBib3RoIElQdjYgcHJpdmFjeSBleHRlbnNpb25z DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7 YW5kIG9wZXJhdG9yIGJhc2VkIGFzc2lnbm1lbnQgb2YgYSBVbmlxdWUgSVB2NiBQcmVmaXggcGVy IEhvc3QgcHJvdmlkZXMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDsmbmJzcDtlYWNoIGltcGxlbWVudGluZyBvcGVyYXRvciBhIHRvb2wgdG8gbWFuYWdl IGFuZCBwcm92aWRlIHN1YnNjcmliZXIgc2VydmljZXMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDthbmQgaGVuY2UgcmVkdWNlcyB0aGUgZXhw ZXJpZW5jZWQgcHJpdmFjeSB3aXRoaW4gZWFjaCBvcGVyYXRvciBjb250cm9sbGVkIGRvbWFpbi4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDtI b3dldmVyLCBiZXlvbmQgdGhlIG9wZXJhdG9yIGNvbnRyb2xsZWQgZG9tYWluLCBJUHY2IHByaXZh Y3kgZXh0ZW5zaW9ucyBwcm92aWRlDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJm5ic3A7Jm5ic3A7dGhlIGRlc2lyZWQgcHJpdmFjeSBhcyBkb2N1bWVudGVkIGlu ICZsdDt4cmVmIHRhcmdldD0mcXVvdDtSRkM0OTQxJnF1b3Q7Jmd0O1JGQzQ5NDEmbHQ7L3hyZWYm Z3Q7LiZsdDsvdCZndDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZsdDsmZ3Q7PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+VGhhbmtzIGFuZCB0YWtlIGNhcmUsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ Ry88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5XYXRzb24gTGFkZCAmbHQ7d2F0c29uYmxh ZGRAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIDUgSnVuZSAyMDE3IGF0 IDA3OjEwPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtzZWNkaXJAaWV0Zi5vcmcmcXVvdDsgJmx0O3Nl Y2RpckBpZXRmLm9yZyZndDssICZxdW90O2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJl Zml4LXBlci1ob3N0LmFsbEB0b29scy5pZXRmLm9yZyZxdW90OyAmbHQ7ZHJhZnQtaWV0Zi12Nm9w cy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QuYWxsQHRvb2xzLmlldGYub3JnJmd0OywgJnF1 b3Q7aXNlZ0BpZXRmLm9yZyZxdW90OyAmbHQ7aXNlZ0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJq ZWN0OiA8L2I+UmV2aWV3IG9mIGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBl ci1ob3N0PGJyPg0KPGI+UmVzZW50LUZyb206IDwvYj4mbHQ7YWxpYXMtYm91bmNlc0BpZXRmLm9y ZyZndDssICZsdDt3YXRzb25ibGFkZEBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+UmVzZW50LVRvOiA8 L2I+Jmx0O2pvaG5fYnJ6b3pvd3NraUBjb21jYXN0LmNvbSZndDssICZsdDtndW50ZXIudmFuX2Rl X3ZlbGRlQG5va2lhLmNvbSZndDssICZsdDtyYm9uaWNhQGp1bmlwZXIubmV0Jmd0OywgJmx0O2xl ZUBhc2dhcmQub3JnJmd0OywgJmx0O2ZyZWRiYWtlci5pZXRmQGdtYWlsLmNvbSZndDssICZsdDti Y2xhaXNlQGNpc2NvLmNvbSZndDssICZsdDt3YXJyZW5Aa3VtYXJpLm5ldCZndDssIFJvbiBCb25p Y2EgJmx0O3Jib25pY2FAanVuaXBlci5uZXQmZ3Q7LCAmbHQ7ZHJhZnQtaWV0Zi12Nm9wcy11bmlx dWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QuYWxsQGlldGYub3JnJmd0Ozxicj4NCjxiPlJlc2VudC1E YXRlOiA8L2I+TW9uZGF5LCA1IEp1bmUgMjAxNyBhdCAwNzozNDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIHJldmlld2Vk IHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdv aW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBi eSB0aGUgSUVTRy4mbmJzcDsgVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBm b3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiZuYnNwOyBEb2N1 bWVudA0KIGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMg anVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPGJyPg0KPGJyPg0KVGhlIHN1 bW1hcnkgb2YgdGhlIHJldmlldyBpcyB0aGF0IHRoaXMgZG9jdW1lbnQgaXMgaGFzIG9uZSBzdWJz dGFudGlhbCBpc3N1ZSBwbHVzIGEgZm9ybWF0dGluZyBuaXQ6IHRoZSBhdXRob3IgbmFtZXMgYXJl IHJ1bm5pbmcgaW50byB0aGUgdGl0bGUuIFBlcmhhcHMgdGhpcyBjYW4gYmUgZml4ZWQNCjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHN1YnN0YW50aWFs IGNvbW1lbnQgaXMgdGhhdCB0aGUgaW50ZXJhY3Rpb24gb2YgcHJpdmFjeSBhZGRyZXNzZXMgd2l0 aCBnaXZpbmcgZWFjaCBzdWJzY3JpYmVyIGEgdW5pcXVlIElQdjYgYWRkcmVzcyBwcmVmaXggc3Bh Y2UgaXMgbm90IGRpc2N1c3NlZCBpbiB0aGlzIGRvY3VtZW50IGF0IGFsbC4gVGhpcyBzZWVtcyBs aWtlIGEgc2VjdXJpdHkgaXNzdWUgdGhhdCBzaG91bGQgYmUgYWRkcmVzc2VkIGFzIGl0DQogcmVk dWNlcyBwcml2YWN5IGNvbXBhcmVkIHRvIGEgc2hhcmVkIHByZWZpeCBmb3IgYWxsIHVzZXJzLiAo T3IgbWF5YmUgSSBhbSBjb21wbGV0ZWx5IHdyb25nOiBJIGRvIG5vdCBrbm93IElQdjYgaW4gZ3Jl YXQgZGV0YWlsKS4gQXQgbWluaW11bSBpdCBzaG91bGQgYmUgZGlzY3Vzc2VkIGluIHRoZSBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLCBldmVuIGlmIGV4cGxpY2l0bHkgZGlzbWlzc2Vk LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T aW5jZXJlbHksPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5XYXRzb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_3FEF62DEB27E493795E9B2AFF1523004nokiacom_-- From nobody Mon Jun 26 10:40:22 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE1812EB23; Mon, 26 Jun 2017 10:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=bZcLCKc7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CcSscp/j 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 xm6fGjvlM8pN; Mon, 26 Jun 2017 10:40:11 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A7C112EB1C; Mon, 26 Jun 2017 10:40:11 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id C0550209CE; Mon, 26 Jun 2017 13:40:10 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 26 Jun 2017 13:40:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=vQIIuXe5RL6q2vFTsY PaX/mPzkv0XUl1x6nMryZ8xT8=; b=bZcLCKc7xbLeYzWWv9GPEtv2vXkB3JiDk5 KGzpY5fbk7x2N6Epl7g5xPAeAbHkvXCSuavi+EtrqD3fPlYaJBLNLSgakQ82zEFt d/b2UczV/JEBYysQJ69iM8cPv/ifltGV7WmEkVV2Xg2gyTRS1vavMrhQa3lnYm/y emA1ZrwYYTri0TkY+JLzdZZyIWBimssDR7Gl9BiX6sdWpkEZKC9Ohp5dtKxdWVu+ qWHGJPsEydToxluFez3UZ6fNDdqSflqkVkNx9R/xAyazHsjv9ZIP3i60SgUffxjB RlKPI356wkhx8ScG1nY2FmTlvKvGVmURIW2CLnek3Z+aPdzgy8DA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=vQIIuXe5RL6q2vFTsYPaX/mPzkv0XUl1x6nMryZ8xT8=; b=CcSscp/j AXtO09Tlzji5eypBWld9ee+0V8Tkd9EkMtxf6/LT4RW4l+sgHSa8+9RoFGu2g13n xmKwS6T2GFHrwta4k3VDskieWjKAIndNx3g3NpoG+o18UCM8my+YXELWyG5/Q9XA 6avhSfZ68eacX3wCXtU6VTYK0fCp4JKdcZTAimwFhlqqpJvhO42pPX1lsG1ZUO6+ famef+AGFW2+LqrQ5S62DD4bk6wWx5RGc432ow4rnPjEAIy9qDO0GTMfUSXrXMLt SDSaUKu2GhUuDAqZ6XTUlVkVRb5uF772pml5FkKsMxyg6/QW2MwTK3tagQ/dR2Fg R3DbTkHAI3m24A== X-ME-Sender: X-Sasl-enc: 0xAl+sTZiWwGlOBv3TGYng8gKq6Gc1Cq0dD58WG0syVo 1498498810 Received: from aither.local (c-98-245-40-52.hsd1.co.comcast.net [98.245.40.52]) by mail.messagingengine.com (Postfix) with ESMTPA id 10BC87E760; Mon, 26 Jun 2017 13:40:09 -0400 (EDT) To: Joseph Salowey , secdir@ietf.org References: <149845620057.31750.11952736688634266964@ietfa.amsl.com> Cc: draft-ietf-precis-7613bis.all@ietf.org, iesg@ietf.org, precis@ietf.org From: Peter Saint-Andre Message-ID: <18393d54-4882-e3f3-a0b0-7af814d51f65@stpeter.im> Date: Mon, 26 Jun 2017 11:40:08 -0600 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: <149845620057.31750.11952736688634266964@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] [precis] Secdir last call review of draft-ietf-precis-7613bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 17:40:14 -0000 Hi Joe, thanks for the review. Comments inline. On 6/25/17 11:50 PM, Joseph Salowey wrote: > Reviewer: Joseph Salowey > Review result: Has Nits > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The summary of the review is document is ready with nits. > > This document is an update to RFC 7613. A few Minor comments: > > 1. I think it would be good to show the zero-length password is not allowed in > table 4 (18 | <> | zero-length password). There are lots of cases where > allowing zero-length passwords has led to problems. Disallowing zero-length > passwords is helpful. Good point - we'll add that. > 2. Comparisons of passwords is a touchy subject. I can't think of a case > where it would be preferable to do a direct password comparison. In most > cases the comparison will be done against a salted-hashed transform of the > password or involve some other cryptographic operation. I think it would be > good to discuss this briefly in the security considerations section, sample > text below > > "Password Comparison > > Verification of passwords during authentication will not use the comparison > defined in section 4.2.3. Instead cryptographic calculations are performed to > verify the password. In most cases the password will be prepared as in > section 4.2.1 and meet the rules enforced in section 4.2.2 before the > calculations are performed." That's helpful - thanks for the suggested test. A forward pointer from Section 4.2.3 also seems desirable. Peter From nobody Tue Jun 27 00:10:47 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189EE12EBDA; Tue, 27 Jun 2017 00:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.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 HUbYzctralVR; Tue, 27 Jun 2017 00:10:43 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD63712EBD4; Tue, 27 Jun 2017 00:10:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.39,399,1493708400"; d="asc'?scan'208";a="202352178" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx143-out.netapp.com with ESMTP; 26 Jun 2017 23:46:28 -0700 Received: from VMWEXCCAS03-PRD.hq.netapp.com (10.122.105.19) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 27 Jun 2017 00:05:27 -0700 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS03-PRD.hq.netapp.com (10.122.105.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Tue, 27 Jun 2017 00:05:27 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NsYZEnUdzBt4mZ7D9WZIlBb9hvhPEWPzYhlBG4rlDpw=; b=PGj+kWYSVdn5QRhAtUiHQ0xbaA74E4ZtLeNtAuHZWm7oxQ+d2SklBi9QHSBZ7dLdBEs4lEMYV/uw9VVKgpubsVTz3ut8l8ljzJAXQCjUum0MtMiNX2M7Re2quftLEWkaOiYOYiaSAqGNPFBjqgOgbr93cj2hzN8oVLRoz0G4n/I= Received: from BY2PR06MB1765.namprd06.prod.outlook.com (10.163.33.19) by BY2PR06MB1768.namprd06.prod.outlook.com (10.163.33.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.15; Tue, 27 Jun 2017 07:05:40 +0000 Received: from BY2PR06MB1765.namprd06.prod.outlook.com ([10.163.33.19]) by BY2PR06MB1765.namprd06.prod.outlook.com ([10.163.33.19]) with mapi id 15.01.1199.019; Tue, 27 Jun 2017 07:05:40 +0000 From: "Eggert, Lars" To: Catherine Meadows CC: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-tcpm-dctcp.all@ietf.org" Thread-Topic: Secdir Review of draft-ietf-tcpm-dctcp-07 Thread-Index: AQHS5JSzX2xxbIqzV0O2QjKFfQxmJqI4XmUA Date: Tue, 27 Jun 2017 07:05:40 +0000 Message-ID: References: <5270D796-928E-466F-96D3-3F8A401FFE7D@nrl.navy.mil> In-Reply-To: <5270D796-928E-466F-96D3-3F8A401FFE7D@nrl.navy.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: nrl.navy.mil; dkim=none (message not signed) header.d=none;nrl.navy.mil; dmarc=none action=none header.from=netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR06MB1768; 7:3waCcGUPN3HFC03Bcy4y7QBT1WLaBHKTDjnrCGYKwLflHlZiRKK63h9UqSQtRnktR4RxTXScYbCo/L2mb1GDO9z5BRQimBo0nm5YGBGy5ox2kJA/7lKNeAwDuBWt8FW0RIFf8G4jvHadgleMjH8TPUQut0PbAal7pGmT2Q5ohuY9JCW2TXawI4DP833bPIIVmoN2b+BEFiWAB2SDrnUag6xMuLyLOaCXl11csDrv53TR4lKNMVgKIqmTEsKCdQl0zDjeQzutd1OJXY9IE9bcQ7KDmPSRn3H4wcxgUx3dw0rS2JIOQUpvlBE+yER9wfi3Am7jzKGLKP3VFEKcC0wAC6Z+EqhRM4Szg5dWP1VRR0J9sYO6pw7FW5c0gkbZegG1B4qdbZmIC/J8Jd4uLf4ZaZaGAedYBvckBtXkTbUnzO6fQvkbch7seKFd2GLuDBYcSL9qSSoDyEVYGBqZqMXuEw7QZ6siZCBoZWqNqH8SqxjXWqJQ4RMEVOiUd4/gCu2DfSA4rMgAipnvN06T4VmzKGf2yl+HS8SCiqgh248lURkLbopYMtgiKTNHN5X8+v/2G7II8gtWdvQNB9ObGTK//YGmilxjYE9vVm9+BeJu6iTpMoQDzVBwSvwW8CGPaQcMGSsdyrU42YF/o9bdq5ZSKpfs9xqvWDwx3iI2KRp1J448GQ0/ctAMAkDXNyRFrzvMg0k3rTSRKUdcySm+lJlGNpvICNbhptIe4CfPMQJNZniv5ZWViJHmb/BXr1eRwaAWiS91IPXJGaWWjc2LVITr3IyH1xhJ82+cTKeMqw8mt2s= x-ms-office365-filtering-correlation-id: e4c94ba7-cca5-46df-cb94-08d4bd2aeb96 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(49563074)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506067)(300135500095); SRVR:BY2PR06MB1768; x-ms-traffictypediagnostic: BY2PR06MB1768: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278178393323532)(236129657087228)(192374486261705)(48057245064654)(148574349560750)(4659246709749); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY2PR06MB1768; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY2PR06MB1768; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39850400002)(39840400002)(39450400003)(24454002)(377424004)(252514010)(51914003)(3660700001)(4001150100001)(6436002)(6116002)(66066001)(3846002)(230783001)(6916009)(102836003)(99286003)(4326008)(189998001)(305945005)(25786009)(110136004)(53936002)(2950100002)(36756003)(38730400002)(2906002)(6246003)(3280700002)(82746002)(6512007)(86362001)(14454004)(229853002)(7736002)(33656002)(122556002)(83716003)(2900100001)(6486002)(6506006)(478600001)(5660300001)(53546010)(76176999)(77096006)(99936001)(50226002)(8936002)(8676002)(50986999)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR06MB1768; H:BY2PR06MB1765.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_5CC5C1A9-591A-44BB-9B34-57F9AAF28D92"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2017 07:05:40.2699 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR06MB1768 X-OriginatorOrg: netapp.com Archived-At: Subject: Re: [secdir] Secdir Review of draft-ietf-tcpm-dctcp-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 07:10:46 -0000 --Apple-Mail=_5CC5C1A9-591A-44BB-9B34-57F9AAF28D92 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Catherine, thanks for the review! I'll try and address your suggestions in the next = revision. Lars On 2017-6-14, at 0:30, Catherine Meadows = 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 > The summary of the review is Almost Ready. >=20 > This draft concerns a variant of TCP intended > for datacenters: DCTCP. Much of this takes advantage of the > fact that datacenters are controlled environments managed by a single > authority. The chief new feature is that the Explicit Notification = Congestion > Field gives information about the amount of congestion present, > instead of simply indicating whether there is congestion or not. >=20 > The Security Considerations section notes that DCTCP inherits the > security considerations of RFC3168, The only change > that has a potential affect on security beyond those already mentioned = in > RFC3168 is a statement that ECT markings (used to indicate whether > endpoints explicit congestion notification) markings SHOULD be applied > to control packets. RFC3168 does not allow this, and RFC5562 does not = allow this for SYN packets because of the possibility > it such packets, since they would live longer, would facilitate SYN = flooding attacks. > However, it is argued here that in a controlled environment SYN = flooding would not be an > issue. >=20 > The section ends as follows: >=20 > The security concerns addressed > by both these RFCs might not apply in controlled environments like > datacenters, and it might not be necessary to account for the > presence of non-ECN servers. Since most servers run virtualized in > datacenters, additional security can be imposed in the physical > servers to intercept and drop traffic resembling an attack. >=20 > I wasn=E2=80=99t sure how to take this. The first sentence indicates = uncertainty, but the second sentence > gives a clear description of how security can be enforced on the = perimeter in datacenters. It also contradicts the > statement at the beginning, that DCTCP inherits the security = considerations of RFC3168. I think that this needs to > be stated more clearly. Perhaps, at the beginning you could say = something like >=20 > DCTCP enhances ECN and thus inherits the security considerations > discussed in [RFC3168]. However, because most servers run = virtualized in > datacenters, additional security can be imposed in the physical > servers to intercept and drop traffic resembling an attack. This = makes it less likely that > it will be necessary to account for the presence of non-ECN = servers, thus mitigating the > security considerations in RFC3168. >=20 > Also, a nit: ECT is never defined in the document. >=20 >=20 > Catherine Meadows > Naval Research Laboratory > Code 5543 > 4555 Overlook Ave., S.W. > Washington DC, 20375 > phone: 202-767-3490 > fax: 202-404-7942 > email: catherine.meadows@nrl.navy.mil >=20 --Apple-Mail=_5CC5C1A9-591A-44BB-9B34-57F9AAF28D92 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAllSA8IACgkQVLXDCb9w wVeIng/+O8Z0ZSmJGeWPufWhD0WwCkpDv3+jydU5VSEyQqX5W5KG+CZ/ePo/5CCF qxQ6Zm4DxGWeD8x6uCVjup+DfwMzOTb2e8yaEuNTJUcQmyQcqgLeBpcf9LAiSd2F cL2OjpcXPOJzC0quJPFjm4ovrOtTf6OtZRkJSKRfpObBsCejxqh6dSaZbnd56JS9 vyS/nSxjUKp0ABF26jTYEqmn/fCRPOk8iPHu1M9gXpZPntYjr4RGjatLzt1GxAd6 yq0zk8AQbZ+1I6fZwculUYauD91rAY1oMYSOl9nLKBf/gUxG9ZmMWL5Y73DJ32I+ TGxr/vgfB++UcVbraUiwNALOLh1/MHloZ6GYCLXnaNjY6frPDfzLBkAKHNa6zLtI +naC85v9RK2BwJj1ewrTy0H1G8THMSOvfafNFPPX08F2ixJPNixr0OqFuiWHcaTO KNbwBUC69eai++BfJhfNZxzF9DSgTDBuG8u68bPb+kb4ZkrXTVD03JL3p1moR6LA bXJ48zItnS4x7DEUANdQl0I9hWiU4pn+dpnXcUqBxfd0wtzfEPLOivbG5mVfYPG6 d9YOOmdqBI3ky4GiWp2hMy5+r0wu+njuao5sclCmw7ww2UE7lmX3dsiyS3JLbcCi N/zW6Tpj3JcsfdnfrhWZNgI059RZZZXM87awiRM387BV1fgWphs= =d5cD -----END PGP SIGNATURE----- --Apple-Mail=_5CC5C1A9-591A-44BB-9B34-57F9AAF28D92-- From nobody Tue Jun 27 08:07: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 6E0D9129B67; Tue, 27 Jun 2017 08:07:44 -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 eDP7qm1fG8Mv; Tue, 27 Jun 2017 08:07:41 -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 C2854127601; Tue, 27 Jun 2017 08:07:41 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v5RF7YBK092652 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 27 Jun 2017 10:07:35 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CC1E66C@ESESSMB109.ericsson.se> Date: Tue, 27 Jun 2017 10:07:33 -0500 Cc: Radia Perlman , "draft-ietf-sipcore-content-id.all@ietf.org" , The IESG , "secdir@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B4CC1C55A@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CC1E66C@ESESSMB109.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-sipcore-content-id-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, 27 Jun 2017 15:07:44 -0000 > On Jun 24, 2017, at 10:39 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 >>>> It is very difficult to read this by itself, even though it is very = short. I'd think it would be better to just make this minor = modification to the base RFC.=20 >>>=20 >>> The WG discussed that alternative, but this was the agreed way = forward. >>>=20 >>>> And if we want to have these tiny RFCs, I understand that it's=20 >>>> unusual for someone to just read one rather than the whole=20 >>>> group...it's really the case of a SECDIR person being assigned a = specific RFC that might not be caught=20 >>>> up on all the jargon for that WG. However, I think each RFC should = be understandable. >>>=20 >>> As a gen-art reviewer, I hear what you are saying, and in the = beginning I more or less had the same opinion.=20 >>> However, later I have realized that to make each RFC = =E2=80=9Cunderstandable=E2=80=9D on its own would mean copy/pasting=20 >>> lots of text from other RFCs, and/or adding lots of clarification = text. So, nowadays, when I review a document,=20 >>> I try to make sure that there are references where I can go and find = extra information. >>>=20 >>>> There ought to be a "context", that includes what other RFCs should=20= >>>> be read first, and in particular, either an acronym dictionary or a = pointer to an RFC that=20 >>>> has explanations for all the acronyms in the little RFC. >>>=20 >>> I guess it is assumed that the Normative References provide such = =E2=80=9Ccontext=E2=80=9D. >>>=20 >>>=20 >> Would an informational reference to RFC 5411 (The Hitchhiker=E2=80=99s = Guide to SIP) be helpful? Maybe if it=20 >> were cited early in the introduction as a place to look for more = information about the various SIP RFCs? >=20 > I actually had a look in RFC 5411, but it doesn't clarify this. >=20 > We have defined lots of new SIP header fields over the years, and I = think people know how to "fit" them into the ABNF. Having said that, IF = we want to clarify this, I think it should be done in 3261, 5411, or = some other generic document.=20 >=20 I think that's a reasonable answer. From nobody Tue Jun 27 08:29: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 35B16129B7E; Tue, 27 Jun 2017 08:29:28 -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 JmLABCV_bojc; Tue, 27 Jun 2017 08:29:26 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 550BE129B5D; Tue, 27 Jun 2017 08:29:26 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id p66so19991038oia.0; Tue, 27 Jun 2017 08:29:26 -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=rhdWy8vwDWL9Ah4JJrKlynDLK6w9ek24cqJV8eDdSXQ=; b=cXsAZuwjhf1/4YCxRXFancg61kmVlKwUKo4Ggx+Ur0lkomxJIc1ifsckZnrk1BBPcr +peiEIaubwEUkh//I2mRUQl59Ll7k7zz8W2oj9gTIaXGmC3PvNyGpygRmyR9vaebbA1t Of2HpXutRGZW6qmGE0i1C9mhO7yQTp2rPGGQvZ0Zc98S5G0YG6L8OwazzpNfX6yVJPOO VFfsWqIqCYjLdyMzudr3CAUxCf/HkRV+Rg7B0dgk+acK1UvBVH2vg8+YGeK23/QLV3YV modNRS7dmSISzl53Z1TW56e6YzJMPRyiox5YTalB+L06nQ7InE/+1dAEIRqbvnF2bJ2d vY/w== 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=rhdWy8vwDWL9Ah4JJrKlynDLK6w9ek24cqJV8eDdSXQ=; b=QL4F5/9f4Xy+TOn8F+lnZA6TzkK2F6ylTevtjGAjQP29d+IWqFQywBEDuVPdkuRKKb fSpReXJpZTPDjnNI15o6D43fufJsnuHOYQbIcqgQNH1QNzxgA61+YaFaeLkIV/61is0e hQDu0NkK+u5gfo+Alqdd9fvpKONAkaTlpPeeaUFPg+CKIYBuy81GrATYpqFIHvdgTpWE Y9WbHpj405pzIbxD4OJZDJnS1/5cFdJKBhtyvvyCEjvIAQ3df/z5MCUKnRAsQ1vnrGwp 0tbJIB6Q195/Po5tXbQwZbEX7n9xfVRfLS1qGhqMIozYqUfQ+K9qme2r1yrFXIHuEodR gtoQ== X-Gm-Message-State: AKS2vOxfZl1ZP207xvCqc72+H0TZeVXHZQlwt+CVgnxcVWxXbu1w+r/M SoLOvZf8TI9SSc+xyK33n4EPMh0QcQ== X-Received: by 10.202.192.5 with SMTP id q5mr3657037oif.60.1498577365723; Tue, 27 Jun 2017 08:29:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.145.37 with HTTP; Tue, 27 Jun 2017 08:29:25 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4CC1C55A@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CC1E66C@ESESSMB109.ericsson.se> From: Radia Perlman Date: Tue, 27 Jun 2017 08:29:25 -0700 Message-ID: To: Ben Campbell Cc: Christer Holmberg , "draft-ietf-sipcore-content-id.all@ietf.org" , The IESG , "secdir@ietf.org" Content-Type: multipart/alternative; boundary="001a113dddfa8d76b20552f2bbe5" Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-sipcore-content-id-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, 27 Jun 2017 15:29:28 -0000 --001a113dddfa8d76b20552f2bbe5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 27, 2017 at 8:07 AM, Ben Campbell wrote: > > > On Jun 24, 2017, at 10:39 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > > > >> Would an informational reference to RFC 5411 (The Hitchhiker=E2=80=99s= Guide to > SIP) be helpful? Maybe if it > >> were cited early in the introduction as a place to look for more > information about the various SIP RFCs? > > > > I actually had a look in RFC 5411, but it doesn't clarify this. > > > > We have defined lots of new SIP header fields over the years, and I > think people know how to "fit" them into the ABNF. Having said that, IF w= e > want to clarify this, I think it should be done in 3261, 5411, or some > other generic document. > > > > I think that's a reasonable answer. > > > but I think it would be nice to have a couple of sentences in this RFC saying "for an acronym list, see RFC xxx, for an overview of SIP concepts see RFC xxx." rather than assuming that people will just read all the normative references cited in the bibliography. --001a113dddfa8d76b20552f2bbe5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

=

On Tue, Jun 27, 2017 at 8:0= 7 AM, Ben Campbell <ben@nostrum.com> wrote:

> On Jun 24, 2017, at 10:39 AM, Christer Holmberg <christer.holmberg@ericsson.com>= wrote:
>

>> Would an informational reference to RFC 5411 (The Hitchhiker=E2=80= =99s Guide to SIP) be helpful? Maybe if it
>> were cited early in the introduction as a place to look for more i= nformation about the various SIP RFCs?
>
> I actually had a look in RFC 5411, but it doesn't clarify this. >
> We have defined lots of new SIP header fields over the years, and I th= ink people know how to "fit" them into the ABNF. Having said that= , IF we want to clarify this, I think it should be done in 3261, 5411, or s= ome other generic document.
>

I think that's a reasonable answer.



but I think it woul= d be nice to have a couple of sentences in this RFC saying "for an acr= onym list, see RFC xxx, for an overview of SIP concepts see RFC xxx." = rather than assuming that people will just read all the normative reference= s cited in the bibliography.=C2=A0
--001a113dddfa8d76b20552f2bbe5-- From nobody Tue Jun 27 09:04: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 96D2F127342; Tue, 27 Jun 2017 09:04:31 -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 FoOIS7KaMT7d; Tue, 27 Jun 2017 09:04:30 -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 E80B7126BF3; Tue, 27 Jun 2017 09:04:29 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v5RG4Jvb001944 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 27 Jun 2017 11:04:20 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Tue, 27 Jun 2017 11:04:19 -0500 Cc: "draft-ietf-sipcore-content-id.all@ietf.org" , "secdir@ietf.org" , The IESG , Christer Holmberg Content-Transfer-Encoding: quoted-printable Message-Id: <721CD94F-C7C9-4411-B0D3-09535EC98113@nostrum.com> References: <7594FB04B1934943A5C02806D1A2204B4CC1C55A@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CC1E66C@ESESSMB109.ericsson.se> To: Radia Perlman X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-sipcore-content-id-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, 27 Jun 2017 16:04:32 -0000 > On Jun 27, 2017, at 10:29 AM, Radia Perlman = wrote: >=20 >=20 >=20 > On Tue, Jun 27, 2017 at 8:07 AM, Ben Campbell wrote: >=20 > > On Jun 24, 2017, at 10:39 AM, Christer Holmberg = wrote: > > >=20 > >> Would an informational reference to RFC 5411 (The Hitchhiker=E2=80=99= s Guide to SIP) be helpful? Maybe if it > >> were cited early in the introduction as a place to look for more = information about the various SIP RFCs? > > > > I actually had a look in RFC 5411, but it doesn't clarify this. > > > > We have defined lots of new SIP header fields over the years, and I = think people know how to "fit" them into the ABNF. Having said that, IF = we want to clarify this, I think it should be done in 3261, 5411, or = some other generic document. > > >=20 > I think that's a reasonable answer. >=20 >=20 >=20 > but I think it would be nice to have a couple of sentences in this RFC = saying "for an acronym list, see RFC xxx, for an overview of SIP = concepts see RFC xxx." rather than assuming that people will just read = all the normative references cited in the bibliography.=20 The problem is, those things don=E2=80=99t really exist in a general = sense. My point was that creating them for SIP in general is not = something I think we should burden a minor extension with. We could = reference 5411 as an overview of the SIP RFC space as of the time it was = published, but it=E2=80=99s out of date now. But if we think we need = those things for SIP in general (and we probably do), the work should = happen elsewhere (e.g. in an update to 3261 or 5411.) Now, it=E2=80=99s reasonable to at least expand non-well-known acronyms = used in this draft on first mention. On a _quick_ scan, the only one I = noticed that needed expansion is UAC, but there may be more.=20 Thanks, Ben. From nobody Tue Jun 27 11:42: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 ACD9912EB04; Tue, 27 Jun 2017 11:42:35 -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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UysIU0aM0rBF; Tue, 27 Jun 2017 11:42:33 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 14C001292F5; Tue, 27 Jun 2017 11:42:32 -0700 (PDT) X-AuditID: c1b4fb30-703ff70000001664-2e-5952a7175a5b Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 46.35.05732.717A2595; Tue, 27 Jun 2017 20:42:31 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.25]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Tue, 27 Jun 2017 20:42:30 +0200 From: Christer Holmberg To: Ben Campbell , Radia Perlman CC: "draft-ietf-sipcore-content-id.all@ietf.org" , "secdir@ietf.org" , The IESG Thread-Topic: secdir review of draft-ietf-sipcore-content-id-06 Thread-Index: AQHS67wrEUOHkTkxaE620T1+A1izWKIyVWmQgABs9oCAAWVIMIAEjY6AgAAGHICAAAnAgIAAS/oA Date: Tue, 27 Jun 2017 18:42:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CC23910@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CC1C55A@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CC1E66C@ESESSMB109.ericsson.se> <721CD94F-C7C9-4411-B0D3-09535EC98113@nostrum.com> In-Reply-To: <721CD94F-C7C9-4411-B0D3-09535EC98113@nostrum.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+NgFuplkeLIzCtJLcpLzFFi42KZGbFdWld8eVCkwfZH4hbzO0+zW8w8u4vF YsaficwWW+a8ZbX4sPAhiwOrx85Zd9k9liz5yeQxa+cTlgDmKC6blNSczLLUIn27BK6MGQ8+ sBfs4qnYfPQxawPjBJ4uRk4OCQETibWvm1i7GLk4hASOMEqsmbERylnMKHHp/lfmLkYODjYB C4nuf9ogpoiAl8T3qa4gJcwCCxglWn5vZwSJCwvYSVw+lQEyU0TAXmLqB5AwiB0lcWnTbzCb RUBV4uvHTnaQcl4BX4m5f8IhNu1jltiz8g0LSA0nUO+VZfuYQGxGATGJ76fWgNnMAuISt57M Z4K4WUBiyZ7zzBC2qMTLx/9YIWwlibWHt7OAzGcW0JRYv0sfolVRYkr3Q3YQm1dAUOLkzCcs ExhFZyGZOguhYxaSjllIOhYwsqxiFC1OLU7KTTcy0kstykwuLs7P08tLLdnECIykg1t+G+xg fPnc8RCjAAejEg/vo9agSCHWxLLiytxDjBIczEoivPm9QCHelMTKqtSi/Pii0pzU4kOM0hws SuK8jvsuRAgJpCeWpGanphakFsFkmTg4pRoYZ7nzBP9kqcmMXel/Tr/oWp6Ty/YFLjOU38gd PzkltOXFK7GsZ3azxbaXtTnGPzfjOPTuOfve1V6mbCXRW603Va5as3zK5alfn2mLxBy7XCsp GV/h+sH/eMEUE+FpLKlPfiRkcDJ3Lrg1qy9IK53xTpO7/GvrfUmN1iydqc8LzvoUPq/c/Gui EktxRqKhFnNRcSIAWbD086ACAAA= Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-sipcore-content-id-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, 27 Jun 2017 18:42:36 -0000 SGksDQoNCi4uLg0KIA0KPj4gYnV0IEkgdGhpbmsgaXQgd291bGQgYmUgbmljZSB0byBoYXZlIGEg Y291cGxlIG9mIHNlbnRlbmNlcyBpbiB0aGlzIFJGQyBzYXlpbmcgImZvciBhbiBhY3JvbnltIGxp c3QsIA0KPj4gc2VlIFJGQyB4eHgsIGZvciBhbiBvdmVydmlldyBvZiBTSVAgY29uY2VwdHMgc2Vl IFJGQyB4eHguIiByYXRoZXIgdGhhbiBhc3N1bWluZyB0aGF0IHBlb3BsZSB3aWxsIA0KPj4ganVz dCByZWFkIGFsbCB0aGUgbm9ybWF0aXZlIHJlZmVyZW5jZXMgY2l0ZWQgaW4gdGhlIGJpYmxpb2dy YXBoeS4gDQo+DQo+IFRoZSBwcm9ibGVtIGlzLCB0aG9zZSB0aGluZ3MgZG9u4oCZdCByZWFsbHkg ZXhpc3QgaW4gYSBnZW5lcmFsIHNlbnNlLiBNeSBwb2ludCB3YXMgdGhhdCBjcmVhdGluZyB0aGVt IGZvciBTSVAgaW4gZ2VuZXJhbA0KPiBpcyBub3Qgc29tZXRoaW5nIEkgdGhpbmsgd2Ugc2hvdWxk IGJ1cmRlbiBhIG1pbm9yIGV4dGVuc2lvbiB3aXRoLiBXZSBjb3VsZCByZWZlcmVuY2UgNTQxMSBh cyBhbiBvdmVydmlldyBvZiB0aGUgDQo+IFNJUCBSRkMgc3BhY2UgYXMgb2YgdGhlIHRpbWUgaXQg d2FzIHB1Ymxpc2hlZCwgYnV0IGl04oCZcyBvdXQgb2YgZGF0ZSBub3cuIEJ1dCBpZiB3ZSB0aGlu ayB3ZSBuZWVkIHRob3NlIHRoaW5ncyBmb3IgU0lQIA0KPiBpbiBnZW5lcmFsIChhbmQgd2UgcHJv YmFibHkgZG8pLCB0aGUgd29yayBzaG91bGQgaGFwcGVuIGVsc2V3aGVyZSAoZS5nLiBpbiBhbiB1 cGRhdGUgdG8gMzI2MSBvciA1NDExLikNCj4NCj4gTm93LCBpdOKAmXMgcmVhc29uYWJsZSB0byBh dCBsZWFzdCBleHBhbmQgbm9uLXdlbGwta25vd24gYWNyb255bXMgdXNlZCBpbiB0aGlzIGRyYWZ0 IG9uIGZpcnN0IG1lbnRpb24uIA0KPiBPbiBhIF9xdWlja18gc2NhbiwgdGhlIG9ubHkgb25lIEkg bm90aWNlZCB0aGF0IG5lZWRlZCBleHBhbnNpb24gaXMgVUFDLCBidXQgdGhlcmUgbWF5IGJlIG1v cmUuIA0KDQpDb3JyZWN0LiBJbiB0aGUgR2VuLUFSVCByZXZpZXcgaXQgd2FzIG1lbnRpb25lZCB0 aGF0IEkgc2hvdWxkIGV4cGFuZCBVQUMgKGluIHNlY3Rpb24gMS4zKSBhbmQgVUEgKGluIHRoZSBz ZWN0aW9uIHRpdGxlIG9mIHNlY3Rpb24gMy40LjEpLCBzbyBJIHdpbGwgZml4IHRoYXQuDQoNClJl Z2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From nobody Wed Jun 28 08:06:36 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 B6504126CF6; Wed, 28 Jun 2017 08:06:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Sean Turner To: Cc: manet@ietf.org, ietf@ietf.org, draft-ietf-manet-rfc5444-usage.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149866238770.7570.2060858148344768585@ietfa.amsl.com> Date: Wed, 28 Jun 2017 08:06:27 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-manet-rfc5444-usage-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: Wed, 28 Jun 2017 15:06:28 -0000 Reviewer: Sean Turner Review result: Ready This draft is well written and in fact provides a wonderful overview of MANET. The draft updates RFC5444 based on some operational experience (and thanks for that); though it does not specify a protocol it is constraining RFC 5444 implementations hence the “updates” header. >From a security perspective this draft seems fine; there is one security-related update and it is explained in the security considerations. >From a non-MANET expert perspective, I have to admit that I found it hard to figure out exactly what is being “updated”. It’s a style thing that I’m not hard over on, but an informative section explaining what got changed would have really helped this reader. I will note that there are a couple of places where the draft is clear that is updates 5444, e.g., s4.4.1, s.4.6, so I have to wonder are those the only update? Or, is it that all the 2119 requirements for the processing rules update 5444 and you’d only look in 5444 for the packet formats? From nobody Wed Jun 28 08:13:30 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF7E1274D0; Wed, 28 Jun 2017 08:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.127 X-Spam-Level: X-Spam-Status: No, score=-6.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RDNS_NONE=0.793] 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 cZ0AcJqHkmvg; Wed, 28 Jun 2017 08:13:27 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [20.133.0.55]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56D7E126CF6; Wed, 28 Jun 2017 08:13:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.40,276,1496098800"; d="scan'208";a="9262605" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 28 Jun 2017 16:13:24 +0100 X-IronPort-AV: E=Sophos;i="5.40,276,1496098800"; d="scan'208";a="7891417" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds016.greenlnk.net with ESMTP; 28 Jun 2017 16:13:24 +0100 Received: from GLKXM0003V.GREENLNK.net ([169.254.4.201]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0248.002; Wed, 28 Jun 2017 16:13:24 +0100 From: "Dearlove, Christopher (UK)" To: Sean Turner , "secdir@ietf.org" CC: "manet@ietf.org" , "ietf@ietf.org" , "draft-ietf-manet-rfc5444-usage.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-manet-rfc5444-usage-06 Thread-Index: AQHS8CAwegFevquESE68dg0fGkiXz6I6YOfw Date: Wed, 28 Jun 2017 15:13:23 +0000 Message-ID: References: <149866238770.7570.2060858148344768585@ietfa.amsl.com> In-Reply-To: <149866238770.7570.2060858148344768585@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-manet-rfc5444-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: Wed, 28 Jun 2017 15:13:29 -0000 U2Vhbg0KDQpUaGFua3MgZm9yIHRoYXQgcmV2aWV3LiBBbnN3ZXJpbmcgeW91ciBxdWVzdGlvbiBh Ym91dCBleGFjdGx5IHdoYXQgaXMgdXBkYXRlZCB3aWxsIHRha2UgYSBsaXR0bGUgd29yayAtIG5v dCB0b28gbXVjaCwgYnV0IGVub3VnaCAoaW5jbHVkaW5nIGNvbnN1bHRpbmcgd2l0aCBjby1hdXRo b3JzKSB0aGF0IEkgd29uJ3QgdHJ5IHRvIGFuc3dlciBub3csIGJ1dCB3ZSB3aWxsIHByb3ZpZGUg YW4gYW5zd2VyIC0gYW5kIGRlcGVuZGluZyBvbiB0aGF0IGFuc3dlciBkZXRlcm1pbmUgaWYgYW55 IGFwcHJvcHJpYXRlIGNvbW1lbnQocykgc2hvdWxkIGJlIGFkZGVkLg0KDQpDaHJpc3RvcGhlcg0K DQotLSANCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpC QUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoNClQ6IMKgKzQ0IDMzMDAgNDY3NTAwIMKgfCDCoEU6IGNocmlzLmRlYXJsb3ZlQGJh ZXN5c3RlbXMuY29tDQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNm b3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIg OEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGln ZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTEN ClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJy ZXksIEdVMiA3WVANCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU2VhbiBU dXJuZXIgW21haWx0bzpzZWFuQHNuM3JkLmNvbV0gDQpTZW50OiAyOCBKdW5lIDIwMTcgMTY6MDYN ClRvOiBzZWNkaXJAaWV0Zi5vcmcNCkNjOiBtYW5ldEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsg ZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLmFsbEBpZXRmLm9yZw0KU3ViamVjdDogU2Vj ZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTA2 DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcgISAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9u LCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIGZyb20gdGhlIGludGVybmV0Lg0K Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3Ms IG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9sbG93IHRoZSAnUmVwb3J0IFN1c3Bp Y2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMgZm9yIGluc3RydWN0aW9ucyBvbiByZXBv cnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClJldmlld2VyOiBTZWFuIFR1cm5l cg0KUmV2aWV3IHJlc3VsdDogUmVhZHkNCg0KVGhpcyBkcmFmdCBpcyB3ZWxsIHdyaXR0ZW4gYW5k IGluIGZhY3QgcHJvdmlkZXMgYSB3b25kZXJmdWwgb3ZlcnZpZXcgb2YgTUFORVQuIA0KVGhlIGRy YWZ0IHVwZGF0ZXMgUkZDNTQ0NCBiYXNlZCBvbiBzb21lIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2Ug KGFuZCB0aGFua3MgZm9yIHRoYXQpOyB0aG91Z2ggaXQgZG9lcyBub3Qgc3BlY2lmeSBhIHByb3Rv Y29sIGl0IGlzIGNvbnN0cmFpbmluZyBSRkMgNTQ0NCBpbXBsZW1lbnRhdGlvbnMgaGVuY2UgdGhl IOKAnHVwZGF0ZXPigJ0gaGVhZGVyLg0KDQo+RnJvbSBhIHNlY3VyaXR5IHBlcnNwZWN0aXZlIHRo aXMgZHJhZnQgc2VlbXMgZmluZTsgdGhlcmUgaXMgb25lDQpzZWN1cml0eS1yZWxhdGVkIHVwZGF0 ZSBhbmQgaXQgaXMgZXhwbGFpbmVkIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy4NCg0K PkZyb20gYSBub24tTUFORVQgZXhwZXJ0IHBlcnNwZWN0aXZlLCBJIGhhdmUgdG8gYWRtaXQgdGhh dCBJIGZvdW5kIGl0IA0KPmhhcmQgdG8NCmZpZ3VyZSBvdXQgZXhhY3RseSB3aGF0IGlzIGJlaW5n IOKAnHVwZGF0ZWTigJ0uICBJdOKAmXMgYSBzdHlsZSB0aGluZyB0aGF0IEnigJltIG5vdCBoYXJk IG92ZXIgb24sIGJ1dCBhbiBpbmZvcm1hdGl2ZSBzZWN0aW9uIGV4cGxhaW5pbmcgd2hhdCBnb3Qg Y2hhbmdlZCB3b3VsZCBoYXZlIHJlYWxseSBoZWxwZWQgdGhpcyByZWFkZXIuICBJIHdpbGwgbm90 ZSB0aGF0IHRoZXJlIGFyZSBhIGNvdXBsZSBvZiBwbGFjZXMgd2hlcmUgdGhlIGRyYWZ0IGlzIGNs ZWFyIHRoYXQgaXMgdXBkYXRlcyA1NDQ0LCBlLmcuLCBzNC40LjEsIHMuNC42LCAgc28gSSBoYXZl IHRvIHdvbmRlciBhcmUgdGhvc2UgdGhlIG9ubHkgdXBkYXRlPyAgT3IsIGlzIGl0IHRoYXQgYWxs IHRoZSAyMTE5IHJlcXVpcmVtZW50cyBmb3IgdGhlIHByb2Nlc3NpbmcgcnVsZXMgdXBkYXRlIDU0 NDQgYW5kIHlvdeKAmWQgb25seSBsb29rIGluIDU0NDQgZm9yIHRoZSBwYWNrZXQgZm9ybWF0cz8N Cg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioKVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRl bnRpYWwgdG8gdGhlIGludGVuZGVkCnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdl ZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0 IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLgpZb3Ugc2hvdWxkIG5vdCBj b3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yCmRpc3RyaWJ1 dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uCioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCg== From nobody Wed Jun 28 08:18:51 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 5CB891274D0; Wed, 28 Jun 2017 08:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 AkUL26JwLiU8; Wed, 28 Jun 2017 08:18:48 -0700 (PDT) Received: from hardbaer.com (mail.hardbaer.com [91.250.101.142]) (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 BFBF0126CF6; Wed, 28 Jun 2017 08:18:47 -0700 (PDT) X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from WStation4 (business-092-079-177-146.static.arcor-ip.net [92.79.177.146]) by hardbaer.com (Postfix) with ESMTPSA id C0ED3280079; Wed, 28 Jun 2017 17:18:45 +0200 (CEST) Date: Wed, 28 Jun 2017 17:18:35 +0200 From: Michael =?ISO-8859-15?B?QuR1ZXJsZQ==?= To: David Mandelberg Cc: iesg@ietf.org, secdir@ietf.org, draft-baeuerle-netnews-cancel-lock.all@ietf.org Message-ID: <20170628171835.49d31b0c@WStation4> In-Reply-To: <79785418-2159-2dba-3beb-b9391a5a2ddf@mandelberg.org> References: <79785418-2159-2dba-3beb-b9391a5a2ddf@mandelberg.org> Organization: STZ Elektronik X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.20; x86_64-slackware-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/GuyADUaM2KNwiorJ+SfkDYN"; protocol="application/pgp-signature" Archived-At: Subject: Re: [secdir] secdir review of draft-baeuerle-netnews-cancel-lock-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 15:18:50 -0000 --Sig_/GuyADUaM2KNwiorJ+SfkDYN Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable David Mandelberg wrote: >=20 > [...] > The authentication in this document is single-use per article. I.e., > once a single supersede or cancel is issued for an article, anybody can > "forge" other valid supersedes or cancels for the same article. I assume > that a cancel followed by a forged cancel is unimportant, but what about > cancel->supersede, supersede->cancel, or supersede->supersede? Also, > what about the race condition if the attacker can propagate the forgery > faster than the original propagates? Hi David, yes, there is no integrity protection. But this is not considered a problem (see below). The current words in the introduction may implicitly suppose some integrity protection capabilities. Suggestion for better words: The authentication system defined in this document is intended to be used as a simple method to verify that the withdrawal of an article is valid, that is to say either the poster, posting agent, moderator or injecting agent that processed the original article has required to withdraw it via the use of a cancel control article (RFC5537 Section 5.3) or a Supersedes header field (RFC5537 Section 5.4). And maybe the following additional words for Section 7 (Security Considerations) as explanation: The authentication system defined in this document provides no integrity checking properties. Arbitrary modifications can be applied to an article on its way through the network, regardless of the presence of a Cancel-K= ey header field. A serving agent, who receives an article that contains a Cancel-Key header field with a matching element, only get the information that the withdrawal of the target article was approved by a legitimate person or agent. Example: A valid element is extracted from a cancel control article and inserted into a forged supersede article. All servers on the network that receive the forged supersede article before the cancel cont= rol article should accept the forged supersede. But because everybody can post articles with forged identity information= in the header (same as with spam e-mail), the same result can be achieved by sending a forged new article using no authentication system at all. For originator and integrity checks a signature based authentication sys= tem is required (normally OpenPGP RFC4880 is used for this purpose). Both systems can be combined. --=20 Michael B=E4uerle --Sig_/GuyADUaM2KNwiorJ+SfkDYN Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZU8jLAAoJECo3xlduIVC7YpwQAJ6CGUw7PpJDpXnWCIuylxXg 41kP8xAYPHLr4QWN2PlmnV+oC376GLJD15YlMpmXYm56l4xMeUAv9lPU/c1df+al QDTa9lASlRAwTKHRIURwcuhEGv1zJFbNRvFNm/Wh0nKfJYqUZAIlMrH41JRTGdul bYHXM853fQszeesPLPKX46CZvA/Kb/rN6v2gvN/9cTWeyXjoN99zYhGTQRDhEGwj JGHWlVu6/kyzG2KitvvFP6VVfoBCdC7xS3iQiOuF3kgQ8OdZDct87Sz1ab4UlcRD /KKUwcUVmYv2tm+TzsZ01rVfZnWgC3Xth/81Z0/KmDwT967O3FQtbw+prVaJVzLg rqQ+4BTjO8x44Z4zpmWVOka/nKHkMiLcTZarAmgq6+V10tUbtga0dzMf00Ps8/p/ p75jiPsNGACCXMWNpFruslk/bDoN2zvGxentcD2ykmQhGkW7m2S8pzmuG1MhIlHI GIZs1Tyqex3csCe45MJq9curZNWoGKravhpCFH6ixH+TspLo49t0rH3jJHqsHqCI SI/INnzn9L22DfttZyk2p1fNXkDC4LdtjnzKBe4BzY8laHpGK0un7fpx1zdvN6SW 2tJoB5avAlfBXYFZZFiiGjs+eZLLVfd9t5HTH9tGIdI3JCs1Ht65HRQmoEVi56NC 5VEjHiBOwJv9l/F2vdWl =f64R -----END PGP SIGNATURE----- --Sig_/GuyADUaM2KNwiorJ+SfkDYN-- From nobody Wed Jun 28 09:09:53 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 E7422129B6F; Wed, 28 Jun 2017 09:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 dTeGa0Kmqh-l; Wed, 28 Jun 2017 09:09:43 -0700 (PDT) Received: from hardbaer.com (mail.hardbaer.com [91.250.101.142]) (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 518C8129B6A; Wed, 28 Jun 2017 09:09:43 -0700 (PDT) X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from WStation4 (business-092-079-177-146.static.arcor-ip.net [92.79.177.146]) by hardbaer.com (Postfix) with ESMTPSA id C387C280079; Wed, 28 Jun 2017 18:09:41 +0200 (CEST) Date: Wed, 28 Jun 2017 18:09:33 +0200 From: Michael =?ISO-8859-15?B?QuR1ZXJsZQ==?= To: David Mandelberg Cc: iesg@ietf.org, secdir@ietf.org, draft-baeuerle-netnews-cancel-lock.all@ietf.org Message-ID: <20170628180933.29d97ee9@WStation4> In-Reply-To: <79785418-2159-2dba-3beb-b9391a5a2ddf@mandelberg.org> References: <79785418-2159-2dba-3beb-b9391a5a2ddf@mandelberg.org> Organization: STZ Elektronik X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.20; x86_64-slackware-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/Yo6/HWJu_CB+5ysOez8eVIf"; protocol="application/pgp-signature" Archived-At: Subject: Re: [secdir] secdir review of draft-baeuerle-netnews-cancel-lock-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 16:09:45 -0000 --Sig_/Yo6/HWJu_CB+5ysOez8eVIf Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable David Mandelberg wrote: >=20 > [...] > This document recommends calculating a single key K for each article > (section 4), then publishing base64(hash(base64(K))) values for multiple > different hash algorithms. This means that the preimage resistance of > the weakest hash algorithm places an upper bound on the security of the > authentication, even if the receiver ignores weaker algorithms. (An > attacker who can calculate K from the weak hash can generate valid keys > for the stronger hashes.) The option to add multiple entries with different hash algorithms in the new draft is intended for the transition period. SHA1 (as defined in the old draft from Simon Lyall) was used for decades and it is unlikely that all existing implementations will add SHA2 support quickly. > Additionally, while plenty of research goes > into preimage security of individual hash algorithms, I don't think as > much research goes into preimage security of multiple algorithms used in > parallel on the same input. While I don't know of any non-brute-force > attacks that can find X given sha256(X) and sha512(X), I see no reason > that it wouldn't be easier than the easiest of the two individual > preimage attacks. (I am not an expert though, there might be something > I'm missing.) Suggested additional words for Section 4 (Calculating the key data): In general every agent must not use the same secret if multiple elements are added. --=20 Michael B=E4uerle --Sig_/Yo6/HWJu_CB+5ysOez8eVIf Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZU9S9AAoJECo3xlduIVC7owkP/0VFyB+CV8jZa+nFj6eXf4Ao TcdmG7q0UlPTgeDJcQex9SgnK2buH1/YHfnh3BOaBzbn+kEc7AxO64wAmDTgtoBT YcxMtoOzMtzohyyAfwO8vTsNZK/X6Ujz7W5dxBd62jP61uLsU5CFku/hW22ueGBQ fz4hndvPJPQniQdULdMj3oAp4lPlGIonrczbUhZer16QC/aNlL36F1YsrDX/0arQ HCcnOq6Ya4g0EfZO+bwS2QW4B333zDMiMuXQkzGm0JUDouMBMQU8299s8KRlU/c7 jaoL7mJCcx5j5e0WW/9eXaXUnhTM+5CUgwVEppoLmYHh9vz91vlvgC6Q4qHQxLAb 3sHtzindiuo7/Tz8+pwJktMqCyOSc0YajLbQcTffijvUyjiRHj1IeKVzysFsScd+ UdUERzjTyTiPkhcsOM2zc+OSdBdqONr0mUQGq57LUGLNYm8I5kdmTZcHefY8tU1o K9lp+bdzG+8ps4+djzvN7xa8HARY4hfqxyIffI9bGjy1SlaNtdMwMiOHZdZoOLyl 1R1f+zoYUZ7ZdoaAfstfWSoubKdGru1bkTZ9V6UirCGQ6wpyPJlAgNEL+3tYrgpy /Si+DjaEiDW1Ur1J4vSvTfLbVsxTWs6otF7t+i81w7miT3h9wVH3MMxKTmo4IZEo kvKp8bnkWiEPw+iWfC8/ =u6xQ -----END PGP SIGNATURE----- --Sig_/Yo6/HWJu_CB+5ysOez8eVIf-- From nobody Wed Jun 28 14:39: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 F2DDC12EC71; Wed, 28 Jun 2017 14:38:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks To: Cc: webpush@ietf.org, ietf@ietf.org, draft-ietf-webpush-vapid.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149868592596.7659.3988919152591675113@ietfa.amsl.com> Date: Wed, 28 Jun 2017 14:38:45 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-webpush-vapid-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 21:38:46 -0000 Reviewer: Robert Sparks Review result: Has Nits Summary: Ready (with nits) This document provides a mechanism for an application server to voluntarily identify itself to a push server using JWT. The draft is easy to follow. The security properties of this mechanism are clearly and thoroughly discussed. There are some minor nits: 1) The draft says that expiry claims MUST NOT be more than 24 hours from the time of the request. Consider adding some discussion of why 24 hours was chosen (vs some other arbitrary value), especially given the MUST NOT strength of the requirement. 2) The last paragraph of 4.2 says application servers create subscriptions, but it means to say that user agents do. Martin already addressed when I brought it up out-of-band with . 3) The last sentence of the abstract is missing a word. Perhaps s/subscription a/subscription to a/ ? 4) Consider using the RFC8174 update to RFC2119. From nobody Wed Jun 28 16:31: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 DCA1512EB0B; Wed, 28 Jun 2017 16:30:57 -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 0lhYZe-n-4Ws; Wed, 28 Jun 2017 16:30:56 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB8212EC2A; Wed, 28 Jun 2017 16:30:55 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id h22so43452089lfk.3; Wed, 28 Jun 2017 16:30:55 -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=u/HhFhLLRZcU5z43GA4cKl/VbYnkux0RTu+AneGlxIY=; b=L5GtFivmyDiLgvG3xB31/bFgJIQQPJnlOYm3i5wZtNr+Rw3qajc5+0vOwW6CkS+g30 SLt9TGHJThbXI4BbN1Y7bIdzW52qqg+FmDNqwpyV92obYdgL7CWSj5K16RarI1Lqnust D1/B57aDa/I9y8cCFSv/TtF8VkViVl7hQXT/JLBmjXJSw9ydDa4nzxehvrPS4Ctk5IWU 12GlPMG0wK4TUSSw2yj1rN+8mJCc09v8xaot8dlTaL98azpqum4SWJyHmbXweYfpehDb Bqou8GyGUoAqJh5ZkCZ4ImcdrbTVvOfvT1ueP7aeggFFnckqunfkztvs+mH1TijPLV7n QDhA== 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=u/HhFhLLRZcU5z43GA4cKl/VbYnkux0RTu+AneGlxIY=; b=rmHBKxcHigmDMesgBehDXiGBMU88F0NHRo3KSEBKOrzdv5yZxJVopLg2AjLigcsJNZ m5ljWbdzM+YWWNoTQOhb0qsdHiuSVTGbVzJT7IP6uCR2YUg9xSq53r74d7lZ16HwV25b Zuo4v5WAzDkcWc+QuVTOpZVLDsombM44ud1J6/lF6nNmFuRKWdbrXNbKtHXLWEFrTuoT ItUHac3ZtrGSMGfss3kCN+3Fky9qSjR657GgXCq7SCjtheEF912szSEb3DEnLddJO+Ak a3QGC4pEUycoiM2w5OGx5w+yw9EE+F/k/KOPZP99xtKuIlOUOXhZQtOm+OVI/1ilRi8k B24Q== X-Gm-Message-State: AKS2vOyV5urLhAr5YTD0EUiIWN1YSnM7ToxVoceEPnRLMqkzJ6L7Ny+t so9ZZ9S1L339f720DZf9M6xS6wIxrK79KzA= X-Received: by 10.25.196.205 with SMTP id u196mr3774462lff.19.1498692654005; Wed, 28 Jun 2017 16:30:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Wed, 28 Jun 2017 16:30:53 -0700 (PDT) In-Reply-To: <149868592596.7659.3988919152591675113@ietfa.amsl.com> References: <149868592596.7659.3988919152591675113@ietfa.amsl.com> From: Martin Thomson Date: Wed, 28 Jun 2017 16:30:53 -0700 Message-ID: To: Robert Sparks Cc: "secdir@ietf.org" , "webpush@ietf.org" , "ietf@ietf.org" , draft-ietf-webpush-vapid.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-webpush-vapid-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 23:30:58 -0000 Thanks Robert. On 28 June 2017 at 14:38, Robert Sparks wrote: > 1) The draft says that expiry claims MUST NOT be more than 24 hours from the > time of the request. Consider adding some discussion of why 24 hours was chosen > (vs some other arbitrary value), especially given the MUST NOT strength of the > requirement. Frankly, the decision is a little arbitrary, but it's where we landed. It's a balance between competing concerns of reuse and the exposure to theft and abuse that comes with reuse. The overriding reason for a MUST NOT strength is that it allows the server to reject requests with bad claims. I'll add a sentence to the security considerations, which talk about the need for expiration and the implications of the MUST NOT. See https://github.com/webpush-wg/webpush-vapid/pull/40 > 2) The last paragraph of 4.2 says application servers create subscriptions, but > it means to say that user agents do. Martin already addressed when I brought it > up out-of-band with . > > 3) The last sentence of the abstract is missing a word. Perhaps s/subscription > a/subscription to a/ ? Fixed, thanks. > 4) Consider using the RFC8174 update to RFC2119. Noted. From nobody Thu Jun 29 01:48: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 BB6E512EBF3; Thu, 29 Jun 2017 01:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5pGEXbRmIDq1; Thu, 29 Jun 2017 01:47:51 -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 CC58712EB96; Thu, 29 Jun 2017 01:47:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.40,280,1496095200"; d="scan'208";a="229937900" Received: from demeter.inrialpes.fr ([194.199.28.3]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2017 10:47:48 +0200 From: Vincent Roca Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Thu, 29 Jun 2017 10:47:47 +0200 To: IESG , secdir@ietf.org, draft-ietf-trill-mtu-negotiation.all@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [secdir] Secdir review of draft-ietf-trill-mtu-negotiation-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: Thu, 29 Jun 2017 08:47:54 -0000 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 issues This document introduces a new mechanism to assess a link level MTU for = local TRILL traffic, in addition to the campus level MTU. Therefore I have problems when the = authors explain in the Security Consider that there is no new security issue: this claim = should be detailed. For instance, what happens if an RBridge misbehaves (deliberately or = not) at the link level or at the campus level, and tries to minimize the Lz (or Sz) size? = Reporting an=20 originatingL1LSPBufferSize smaller than Sz seems to be sufficient at the = campus level. What prevents or mitigates it? This is just an example and I=E2=80=99m = pretty sure other possibilities exist. Since I have the feeling that the =C2=AB Security Considerations =C2=BB = sections of [RFC6325] and [RFC7177] referenced by this document do not address this aspect, I = suggest the authors add a dedicated paragraph with the threats, counter measures and = mitigation techniques whenever appropriate. Other comments (not security related): ** Introduction, second paragraph: The sentence "In other words, if this link..." does not paraphrase = the previous sentence: - the first sentence is about a situation where Link MTU X >=3D = campus Sz; - the sentence beginning with "In other words" discusses the opposite = situation and introduces another property: "it will not be reported as part of the campus = topology". I suggest changing the transition and perhaps the beginning of this paragraph that is = not so clear to me. On the opposite, I find the first few introduction sentences of = Section 2 crystal clear on what is Ls and its relationship to Sz, unlike the Introduction. Typos: ** Introduction: the references [RFC6325] and [RFC7177] that appear at = the start of the first two paragraphs are textual, not pointers to the = appropriate reference. ** Introduction: "By calculating a using Lz" =3D> "and" Cheers, Vincent From nobody Thu Jun 29 05:09: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 D9A401293E1 for ; Thu, 29 Jun 2017 05:09:05 -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.55.1 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <149873814580.6607.17412979874519992763.idtracker@ietfa.amsl.com> Date: Thu, 29 Jun 2017 05:09:05 -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, 29 Jun 2017 12:09:06 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-07-06 Reviewer LC end Draft Tim Polk 2017-06-28 draft-ietf-trill-rbridge-multilevel-06 David Waltermire 2017-06-29 draft-ietf-bier-architecture-07 For telechat 2017-08-03 Reviewer LC end Draft David Mandelberg R2017-07-12 draft-ietf-pce-pceps-14 Rifaat Shekh-Yusef 2017-07-07 draft-ietf-teas-gmpls-lsp-fastreroute-09 Klaas Wierenga 2017-07-12 draft-ietf-mpls-rfc3107bis-02 Paul Wouters None draft-ietf-teas-gmpls-scsi-03 Last calls: Reviewer LC end Draft Tobias Gondrom 2017-05-14 draft-ietf-calext-caldav-attachments-02 Rich Salz 2017-07-19 draft-bormann-hybi-ws-wk-00 Yaron Sheffer 2017-07-17 draft-weis-gdoi-rekey-ack-05 Melinda Shore 2017-07-05 draft-ietf-httpbis-early-hints-03 Takeshi Takahashi 2017-06-30 draft-ietf-spring-oam-usecase-06 Tina Tsou 2017-06-29 draft-ietf-trill-arp-optimization-08 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-11 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Catherine Meadows R2017-06-29 draft-ietf-opsawg-capwap-alt-tunnel-09 Brian Weis 2017-06-29 draft-ietf-idr-bgp-prefix-sid-06 Next in the reviewer rotation: Liang Xia Tom Yu Dacheng Zhang Derek Atkins John Bradley Shaun Cooley Alan DeKok Donald Eastlake Shawn Emery Stephen Farrell From nobody Thu Jun 29 10:53:58 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 0EA75129B47; Thu, 29 Jun 2017 10:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dJCSCIA070L; Thu, 29 Jun 2017 10:53:47 -0700 (PDT) Received: from hardbaer.com (mail.hardbaer.com [91.250.101.142]) (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 82F36129ADF; Thu, 29 Jun 2017 10:53:47 -0700 (PDT) X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from WStation4 (business-092-079-177-146.static.arcor-ip.net [92.79.177.146]) by hardbaer.com (Postfix) with ESMTPSA id 80C29280030; Thu, 29 Jun 2017 19:53:45 +0200 (CEST) Date: Thu, 29 Jun 2017 19:53:37 +0200 From: Michael =?ISO-8859-15?B?QuR1ZXJsZQ==?= To: David Mandelberg Cc: iesg@ietf.org, secdir@ietf.org, draft-baeuerle-netnews-cancel-lock.all@ietf.org Message-ID: <20170629195337.431deba7@WStation4> In-Reply-To: <79785418-2159-2dba-3beb-b9391a5a2ddf@mandelberg.org> References: <79785418-2159-2dba-3beb-b9391a5a2ddf@mandelberg.org> Organization: STZ Elektronik X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.20; x86_64-slackware-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/IDPi7YImYnA35QBMt9pyPLO"; protocol="application/pgp-signature" Archived-At: Subject: Re: [secdir] secdir review of draft-baeuerle-netnews-cancel-lock-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: Thu, 29 Jun 2017 17:53:50 -0000 --Sig_/IDPi7YImYnA35QBMt9pyPLO Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable David Mandelberg wrote: >=20 > [...] > Section 4: Is it ever possible for two different (uid, mid) pairs to > have the same concatenated value? E.g., alice@example.co + mfoo and > alice@example.com + foo. If that ever happened and one of the two > articles was canceled, an attacker would be able to cancel the other > article. Literal angle brackets at start and end must be part of mid (words are already present in Section 4). Adding additional words that forbid angle brackets in uid would make an overlap impossible (the first opening angle bracket would always be the junction point in this case). Suggestion for additional words in Section 4: The User-ID must not contain angle brackets. > Section 4: I don't understand Q1. Are you asking me if the existing > implementations are doing something insecure? (It's not specified well > enough for me to tell.) Q1 is there because the draft intentionally does not formalize the algorithm used by some existing implementations that support uid: HMAC(data, secret key) Existing : K =3D HMAC(mid, uid+sec) Recommended by draft: K =3D HMAC(uid+mid, sec) It is unclear why existing implementations with support for uid are using it in a specific way (there was no User-ID in the old draft from Simon Lyall). It is assumed that uid may be easy to guess - probably simply the users name. The choice for the latter option from the two above was done because: - mid is public and sec is secret If uid is easy to guess, it is more related to mid than to sec. - HMAC has two input channels (data and key) If sec is our secret key, other information should be feeded into the data input. - Section 4 defines recommendations for the length of sec This definition would be more complicated (and the recommendations harder to implement) if some potentially non-secret data with non- constant length is concatenated to sec. The question is why existing implementations have chosen uid+sec as secrect key (maybe I have overlooked an advantage of this option) and whether the different choice uid+mid as data really is the better option. --=20 Michael B=E4uerle --Sig_/IDPi7YImYnA35QBMt9pyPLO Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZVT6hAAoJECo3xlduIVC7POIQAKSt4aKYfieBVeI1qby0gwqy KbCsRJBjzALw1LNTzqykHDsrpn0i4XGN4rZevEztO9b8ghmHjIVROaifS6Un9f3u OHE3dcPmyxGONEA/Hi48s6LIteO27qNrFmoewwHHli2hs3bXwYCMlvpaGRtj/i4u sFz3IqmTFGhDNBEk5sUjdTVbtjqffatJEVZA1lrKCksq5d/lcYG9+DDZwaFN0UXv 63YfRLHT9YoYwSXqJFN+XLpqspCL1AuORhAK6sIRML4bVByDTYh37tlQDDuoQIp5 OO0sWjWeIod4XT2tS6vHgfUSgVT30SZh6frHU0pfx59lYv0GkOtDBq9Inl+u7pNl k2EYVnROvp+tVYMsN7a2nwBUdMK41aG5Eb7exoU+tPAXlkfv44+1DiaSwWFmIHm3 aOH7YFzpfNjTQX56hWxhSutIJdnONTZiH3D0zZUKAjomkg6Zeuyv7JptruTlhL+G fNywRkVNWxlvfczUWI6pupw58oEtPkGVUs4CKeuO+qGEZFYVGyK9p06A6jU5uZqU vspD5eQRb6eew51yGTKLQGs08AOOvMDF4ncD0V9YcWAwJiG8jzytDGnm+Juz5cie LFrX5GizO7QbN7ZobTDc722zF6sZy9eCSK0M8rwCz5lbXkJpHj9ZCwLnNFaIWYhY ODVilU9tQNsBM2RpHpm6 =irOl -----END PGP SIGNATURE----- --Sig_/IDPi7YImYnA35QBMt9pyPLO-- From nobody Thu Jun 29 12:10: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 559F3129B94; Thu, 29 Jun 2017 12:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 7UQ8yM7ZPQs9; Thu, 29 Jun 2017 12:10:30 -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 6B331126DEE; Thu, 29 Jun 2017 12:10:30 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id z62so12573458ioi.3; Thu, 29 Jun 2017 12:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7eG+HWccBHaHxwNs9jVyueRdK9UdaMjw7x/Q7hukP5I=; b=KC1ZqqWISuCAUslJucfsOuiDMLX7DvRD7I9+ix8VNXF8cQDkMKZ43eGW2b+66l+RDS 1WIjgS0qjYhfzcKcZLsu0NwRC4sW1vm3UgZSwcQpT2YUZYbAG865gcJO1UUXRsH0JoqH cM3nvdaz8zINaE3l7It7cHtihT0OoB+6UuM+8eWjFB3H3l0CzJm36ENA4ZOhBf8cy1Xg RM75YEZsN+4nIsCAYZn2fBLjfZKiZEORK8PgbWq5xoGVPcx9CS0h80tWWdBaM9cy+e+I KGZ1UilI1hpeiekfV+mO6J9jFIcvtyk/TQU+ZTrvT6+TsFsaaMgVLuc0pfaOr562si06 dqwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7eG+HWccBHaHxwNs9jVyueRdK9UdaMjw7x/Q7hukP5I=; b=LMYvzESCU9qlS94ERXG7J1dU2YaKhRQbipo36aWHwayIngjvTQYsmesKFzzbT9utkf Ws1AxRvNiTFXKSb/IS3vsK9dLiFy+zN7nkywqRpzTQggaGSFx85WvfLMSVEvSaQrKxxD B9H2W5ORLCa3L4hRrM5MaNjyggmNF1ZoC2Gn7qwmAoGyiE9xj0viQi24lnFfD09R7juD h7MwxmUscVzru8YY6zO0iMxinRjC0tVmtrwqwBmt29tc+S/Rdd0gvZ519HjeKjqy1nt7 KpAU9ssR6r2PWUWwLr/IXkFHtf1zIJkwaDqaN01wpEqYWxpfszGi8dvOeKoYGA8vq6zN y1sA== X-Gm-Message-State: AKS2vOxnJ2G6RRydteqOEqIvnQqoP/Dodnx3RiyP9h+LokGxUSxykIQJ zyLkgW+T8CC1d5pCstoyeiF/GuiKvB2SxuI= X-Received: by 10.107.31.209 with SMTP id f200mr18541555iof.231.1498763429727; Thu, 29 Jun 2017 12:10:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.221 with HTTP; Thu, 29 Jun 2017 12:10:14 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Thu, 29 Jun 2017 15:10:14 -0400 Message-ID: To: Vincent Roca Cc: IESG , "secdir@ietf.org" , draft-ietf-trill-mtu-negotiation.all@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-trill-mtu-negotiation-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: Thu, 29 Jun 2017 19:10:32 -0000 Hi Vincent, Thanks for your review. On Thu, Jun 29, 2017 at 4:47 AM, Vincent Roca wrote= : > 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 ju= st > like any other last call comments. > > Summary: Ready with issues > > This document introduces a new mechanism to assess a link level MTU for l= ocal TRILL traffic, > in addition to the campus level MTU. Therefore I have problems when the a= uthors explain in > the Security Consider that there is no new security issue: this claim sho= uld be detailed. > For instance, what happens if an RBridge misbehaves (deliberately or not)= at the link level or > at the campus level, and tries to minimize the Lz (or Sz) size? Reporting= an > originatingL1LSPBufferSize smaller than Sz seems to be sufficient at the = campus level. > What prevents or mitigates it? This is just an example and I=E2=80=99m pr= etty sure other possibilities > exist. > > Since I have the feeling that the =C2=AB Security Considerations =C2=BB s= ections of [RFC6325] and > [RFC7177] referenced by this document do not address this aspect, I sugge= st the authors > add a dedicated paragraph with the threats, counter measures and mitigati= on techniques > whenever appropriate. I have no problem with saying a bit more about this. However, I reject the idea that this document needs to fill all the gaps you see in all the Security Consideration sections of TRILL RFCs on which it is dependent. The goal of this document is to allow TRILL, for link local IS-IS PDUs, to make us of a link MTU (Lz) that is higher than the campus wide MTU (Sz). With regard to this feature, the worst that a misbehaved RBridge could do would be to constrain Lz to be equal to Sz which really isn't a bit deal. In TRILL, RBridges are trusted devices and there are just all kinds of ways they can screw things up by advertising false or malicious information. As I say, I have no problem with adding a couple of sentences clarifying th= is. > Other comments (not security related): > > ** Introduction, second paragraph: > The sentence "In other words, if this link..." does not paraphrase the= previous sentence: > - the first sentence is about a situation where Link MTU X >=3D campus= Sz; > - the sentence beginning with "In other words" discusses the opposite = situation and introduces > another property: "it will not be reported as part of the campus top= ology". I suggest changing > the transition and perhaps the beginning of this paragraph that is n= ot so clear to me. OK. > On the opposite, I find the first few introduction sentences of Sectio= n 2 crystal clear on what is > Ls and its relationship to Sz, unlike the Introduction. Well, Section 1 is more of a general introduction about the topic of TRILL MTU while Section 2 is more specifically about the link local MTU feature. I think perhaps that paragraph 2 should be split right after the sentence currently beginning with "In other words," and a reference to Section 2 added to the new paragraph 3. > Typos: > > ** Introduction: the references [RFC6325] and [RFC7177] that appear at th= e start of the first two paragraphs are textual, not pointers to the approp= riate > reference. Sounds like an IETF tools bug to me. > ** Introduction: "By calculating a using Lz" =3D> "and" Fixed in version -06. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Cheers, > > Vincent From nobody Thu Jun 29 12:38: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 DA5441243F6; Thu, 29 Jun 2017 12:38:26 -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 gHRrPfxEgz96; Thu, 29 Jun 2017 12:38:24 -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 7D6D71205D3; Thu, 29 Jun 2017 12:38:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.40,282,1496095200"; d="scan'208,217";a="230030722" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.1.104]) ([82.236.155.50]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2017 21:38:21 +0200 From: Vincent Roca Message-Id: <935C94F4-DC5C-47C3-BE71-5939BD3E11B9@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_8ACB8CAE-415C-493A-A1A5-36E10DD22486" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 29 Jun 2017 21:38:19 +0200 In-Reply-To: Cc: Vincent Roca , IESG , "secdir@ietf.org" , draft-ietf-trill-mtu-negotiation.all@ietf.org To: Donald Eastlake References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-trill-mtu-negotiation-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: Thu, 29 Jun 2017 19:38:27 -0000 --Apple-Mail=_8ACB8CAE-415C-493A-A1A5-36E10DD22486 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Donald, > Thanks for your review. You=E2=80=99re welcome. >> This document introduces a new mechanism to assess a link level MTU = for local TRILL traffic, >> in addition to the campus level MTU. Therefore I have problems when = the authors explain in >> the Security Consider that there is no new security issue: this claim = should be detailed. >> For instance, what happens if an RBridge misbehaves (deliberately or = not) at the link level or >> at the campus level, and tries to minimize the Lz (or Sz) size? = Reporting an >> originatingL1LSPBufferSize smaller than Sz seems to be sufficient at = the campus level. >> What prevents or mitigates it? This is just an example and I=E2=80=99m = pretty sure other possibilities >> exist. >>=20 >> Since I have the feeling that the =C2=AB Security Considerations =C2=BB= sections of [RFC6325] and >> [RFC7177] referenced by this document do not address this aspect, I = suggest the authors >> add a dedicated paragraph with the threats, counter measures and = mitigation techniques >> whenever appropriate. >=20 > I have no problem with saying a bit more about this. >=20 > However, I reject the idea that this document needs to fill all the > gaps you see in all the Security Consideration sections of TRILL RFCs > on which it is dependent. The goal of this document is to allow TRILL, > for link local IS-IS PDUs, to make us of a link MTU (Lz) that is > higher than the campus wide MTU (Sz). With regard to this feature, the > worst that a misbehaved RBridge could do would be to constrain Lz to > be equal to Sz which really isn't a bit deal. >=20 > In TRILL, RBridges are trusted devices and there are just all kinds of > ways they can screw things up by advertising false or malicious > information. >=20 > As I say, I have no problem with adding a couple of sentences = clarifying this. Okay, do whatever you think is appropriate and clarify the threat model = as well.=20 If going down to Sz is the only threat, then this is not a big deal I = agree. It just needs to be clearly stated. >> Other comments (not security related): >>=20 >> ** Introduction, second paragraph: >> The sentence "In other words, if this link..." does not paraphrase = the previous sentence: >> - the first sentence is about a situation where Link MTU X >=3D = campus Sz; >> - the sentence beginning with "In other words" discusses the = opposite situation and introduces >> another property: "it will not be reported as part of the campus = topology". I suggest changing >> the transition and perhaps the beginning of this paragraph that = is not so clear to me. >=20 > OK. >=20 >> On the opposite, I find the first few introduction sentences of = Section 2 crystal clear on what is >> Ls and its relationship to Sz, unlike the Introduction. >=20 > Well, Section 1 is more of a general introduction about the topic of > TRILL MTU while Section 2 is more specifically about the link local > MTU feature. I think perhaps that paragraph 2 should be split right > after the sentence currently beginning with "In other words," and a > reference to Section 2 added to the new paragraph 3. Section 1 has a somewhat complex structure. It was my first time to = TRILL, and found it difficult to follow. But this comment is not part of the = official SECDIR review ;-) Cheers, Vincent= --Apple-Mail=_8ACB8CAE-415C-493A-A1A5-36E10DD22486 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Donald,

Thanks for your review.

You=E2=80=99r= e welcome.

This document introduces a = new mechanism to assess a link level MTU for local TRILL traffic,
in addition to the campus level MTU. Therefore I have = problems when the authors explain in
the Security Consider = that there is no new security issue: this claim should be detailed.
For instance, what happens if an RBridge misbehaves = (deliberately or not) at the link level or
at the campus = level, and tries to minimize the Lz (or Sz) size? Reporting an
originatingL1LSPBufferSize smaller than Sz seems to be = sufficient at the campus level.
What prevents or mitigates = it? This is just an example and I=E2=80=99m pretty sure other = possibilities
exist.

Since I = have the feeling that the =C2=AB Security Considerations =C2=BB sections = of [RFC6325] and
[RFC7177] referenced by this document do = not address this aspect, I suggest the authors
add a = dedicated paragraph with the threats, counter measures and mitigation = techniques
whenever appropriate.

I have no problem with saying a bit more = about this.

However, I reject the idea that = this document needs to fill all the
gaps you see in all the Security = Consideration sections of TRILL RFCs
on which it is dependent. The = goal of this document is to allow TRILL,
for link local IS-IS PDUs, to = make us of a link MTU (Lz) that is
higher than the campus wide MTU = (Sz). With regard to this feature, the
worst that a misbehaved RBridge = could do would be to constrain Lz to
be equal to Sz which really = isn't a bit deal.

In TRILL, RBridges are trusted = devices and there are just all kinds of
ways they can screw things up by = advertising false or malicious
information.
As I say, I have no problem with adding a couple = of sentences clarifying this.

Okay, do = whatever you think is appropriate and clarify the threat model as = well. 
If going down to Sz is the only threat, then this = is not a big deal I agree. It just
needs to be clearly = stated.


Other comments (not security = related):

** Introduction, second = paragraph:
  The sentence "In other words, if = this link..." does not paraphrase the previous sentence:
  - the first sentence is about a situation where = Link MTU X >=3D campus Sz;
  - the sentence = beginning with "In other words" discusses the opposite situation and = introduces
    another property: "it = will not be reported as part of the campus topology". I suggest = changing
    the transition and = perhaps the beginning of this paragraph that is not so clear to me.

OK.

  On the opposite, = I find the first few introduction sentences of Section 2 crystal clear = on what is
  Ls and its relationship to Sz, = unlike the Introduction.

Well, Section 1 is more of a general = introduction about the topic of
TRILL MTU while Section 2 is = more specifically about the link local
MTU feature. I think perhaps = that paragraph 2 should be split right
after the sentence currently = beginning with "In other words," and a
reference to Section 2 added to = the new paragraph 3.

Section 1 = has a somewhat complex structure. It was my first time to = TRILL,
and found it difficult to follow. But this comment is = not part of the official
SECDIR review ;-)

Cheers,

  = Vincent
= --Apple-Mail=_8ACB8CAE-415C-493A-A1A5-36E10DD22486-- From nobody Thu Jun 29 13:46:14 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7BB12EAE4; Thu, 29 Jun 2017 13:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 tXbinwuzafl5; Thu, 29 Jun 2017 13:46:04 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 3DC4412EAC4; Thu, 29 Jun 2017 13:46:04 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id m68so51945161ith.1; Thu, 29 Jun 2017 13:46:04 -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=M/L0OrHL//SLvjhPVBQjVWHH7kZikwebuV5dCGhoeE4=; b=eg2OcwRuqg0lINjPDTiexW/U1u745ZazELmmzRQv4FYVxMmW0fufylK8P/yAbgOrPr x7gbqfeoV1WFlN6jfM11lVax+MaWYpkcIT6+qtIiYeDr2hJS2uuiUDd554ZZ4Guqwfka seK4TaIsb/m07saOacopYhxoHoCrUSLUkQvIWh0cAtqDjJhPVndCIhNabUPBQzuBYnDu A98u9Bi8P8kuOtV2/YB/djBLgdWQzfInBHzcvOz+QGQUB2MD/dzHVzM0ooZcvuvtGoa3 3xLt4nFMwQMBLxNsWtOjYlCB1ojGvKpSDxB4Ygg9v/mZmoxW/mv+BlZj/6EIJV11UyJj tKDw== 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=M/L0OrHL//SLvjhPVBQjVWHH7kZikwebuV5dCGhoeE4=; b=CD5+JMkdO9HlEjvM4VBqVKNyKx7EDOejkLED0Q8YY0GB2fmwrJAqYyDeLzPmoOySI4 bBKSH1JX00zZRUQJWIENsn/01x6Yn1lLCQJz8Lm1FU3kkR9ZQlnT0JQkdsgwHfCiJOD5 PloNbXQCax6gjuQt5ONGqJOTuOT6GzAlwSdCDG50xaLE37xKV16CElZOFW+o7Qnr2FK4 yNOMx80TDS+OR8j+DFDV1EQRfl0dY4phjiINWliyz9+ybUgE1gyiEGUEXYhoij41WMFA K5JiXSy3DFFj2PsYPI6k63mYaWlnFx5pf6R+qjAy3vADrBBUXkt76QSJMKMMsGU3Kiud DoOg== X-Gm-Message-State: AKS2vOx+t2PVy3tDcNjMjWt8HHj36tAv5SjyL5c/AfEXCg+Us4uNLc2e UmaU4gvIZGM5bo1G5RJ05z6lqu8AXS2uz1s= X-Received: by 10.36.3.11 with SMTP id e11mr4160193ite.79.1498769163582; Thu, 29 Jun 2017 13:46:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.221 with HTTP; Thu, 29 Jun 2017 13:45:48 -0700 (PDT) In-Reply-To: <935C94F4-DC5C-47C3-BE71-5939BD3E11B9@inria.fr> References: <935C94F4-DC5C-47C3-BE71-5939BD3E11B9@inria.fr> From: Donald Eastlake Date: Thu, 29 Jun 2017 16:45:48 -0400 Message-ID: To: Vincent Roca Cc: IESG , "secdir@ietf.org" , draft-ietf-trill-mtu-negotiation.all@ietf.org Content-Type: multipart/alternative; boundary="001a1147dbec98cd5105531f63d1" Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-trill-mtu-negotiation-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: Thu, 29 Jun 2017 20:46:06 -0000 --001a1147dbec98cd5105531f63d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Vincent, See below at >On Thu, Jun 29, 2017 at 3:38 PM, Vincent Roca wrote: >>Hi Donald, >>... >>This document introduces a new mechanism to assess a link level MTU >>for local TRILL traffic, in addition to the campus level >>MTU. Therefore I have problems when the authors explain in the >>Security Consider that there is no new security issue: this claim >>should be detailed. For instance, what happens if an RBridge >>misbehaves (deliberately or not) at the link level or at the campus >>level, and tries to minimize the Lz (or Sz) size? Reporting an >>originatingL1LSPBufferSize smaller than Sz seems to be sufficient at >>the campus level. What prevents or mitigates it? This is just an >>example and I=E2=80=99m pretty sure other possibilities exist. >>Since I have the feeling that the =C2=AB Security Considerations =C2=BB >>sections of [RFC6325] and [RFC7177] referenced by this document do >>not address this aspect, I suggest the authors add a dedicated >>paragraph with the threats, counter measures and mitigation >>techniques whenever appropriate. >I have no problem with saying a bit more about this. >However, I reject the idea that this document needs to fill all the >gaps you see in all the Security Consideration sections of TRILL RFCs >on which it is dependent. The goal of this document is to allow >TRILL, for link local IS-IS PDUs, to make us of a link MTU (Lz) that >is higher than the campus wide MTU (Sz). With regard to this feature, >the worst that a misbehaved RBridge could do would be to constrain Lz >to be equal to Sz which really isn't a bit deal. >In TRILL, RBridges are trusted devices and there are just all kinds >of ways they can screw things up by advertising false or malicious >information. >As I say, I have no problem with adding a couple of sentences >clarifying this. Okay, do whatever you think is appropriate and clarify the threat model as well. If going down to Sz is the only threat, then this is not a big deal I agree. It just needs to be clearly stated. How about the following for a revised Security Considerations section? This document raises no significant new security issues for TRILL. In TRILL, RBridges are generally considered to be trusted devices. Protection against forged TRILL IS-IS PDUs, including forged Hellos containing originatingSNPBufferSize APP-subTLVs, can be obtained through IS-IS PDU cryptographic authentication [RFC5310]. The worst that an RBridge can do by reporting an erroneous originatingSNPBufferSize is reduce Lz to Sz and thus make unavailable the optimization of being able to use link MTUs that exceed the campus wide MTU for link local TRILL IS-IS PDUs. For general and adjacency related TRILL security considerations, see [RFC6325] and [RFC7177]. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com >>Other comments (not security related): >>... >>Cheers, >>Vincent --001a1147dbec98cd5105531f63d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Vincent,

=
See below at <dee>

>On Thu, Ju= n 29, 2017 at 3:38 PM, Vincent Roca <vincent.roca@inria.fr> wrote:
>>Hi Donald,

>>...

>>This doc= ument introduces a new mechanism to assess a link level MTU
>&= gt;for local TRILL traffic, in addition to the campus level
>&= gt;MTU. Therefore I have problems when the authors explain in the
>>Security Consider that there is no new security issue: this claim<= /div>
>>should be detailed.=C2=A0 For instance, what happens if a= n RBridge
>>misbehaves (deliberately or not) at the link le= vel or at the campus
>>level, and tries to minimize the Lz = (or Sz) size? Reporting an
>>originatingL1LSPBufferSize sma= ller than Sz seems to be sufficient at
>>the campus level.= =C2=A0 What prevents or mitigates it? This is just an
>>exa= mple and I=E2=80=99m pretty sure other possibilities exist.

<= /div>
>>Since I have the feeling that the =C2=AB Security Conside= rations =C2=BB
>>sections of [RFC6325] and [RFC7177] refere= nced by this document do
>>not address this aspect, I sugge= st the authors add a dedicated
>>paragraph with the threats= , counter measures and mitigation
>>techniques whenever app= ropriate.

>I have no problem with saying a bit = more about this.

>However, I reject the idea th= at this document needs to fill all the
>gaps you see in all th= e Security Consideration sections of TRILL RFCs
>on which it i= s dependent. The goal of this document is to allow
>TRILL, for= link local IS-IS PDUs, to make us of a link MTU (Lz) that
>is= higher than the campus wide MTU (Sz). With regard to this feature,
>the worst that a misbehaved RBridge could do would be to constrain L= z
>to be equal to Sz which really isn't a bit deal.
<= div>
>In TRILL, RBridges are trusted devices and there are= just all kinds
>of ways they can screw things up by advertisi= ng false or malicious
>information.

&= gt;As I say, I have no problem with adding a couple of sentences
= >clarifying this.

Okay, do whatever you think i= s appropriate and clarify the threat model as well.=C2=A0
If goin= g down to Sz is the only threat, then this is not a big deal I agree. It ju= st
needs to be clearly stated.

<dee&g= t; How about the following for a revised Security Considerations
= section?

=C2=A0 =C2=A0This document raises no sign= ificant new security issues for
=C2=A0 =C2=A0TRILL. In TRILL, RBr= idges are generally considered to be trusted
=C2=A0 =C2=A0devices= . Protection against forged TRILL IS-IS PDUs, including
=C2=A0 = =C2=A0forged Hellos containing originatingSNPBufferSize APP-subTLVs, can
=C2=A0 =C2=A0be obtained through IS-IS PDU cryptographic authentica= tion
=C2=A0 =C2=A0[RFC5310]. The worst that an RBridge can do by = reporting an
=C2=A0 =C2=A0erroneous originatingSNPBufferSize is r= educe Lz to Sz and thus make
=C2=A0 =C2=A0unavailable the optimiz= ation of being able to use link MTUs that
=C2=A0 =C2=A0exceed the= campus wide MTU for link local TRILL IS-IS PDUs.

= =C2=A0 =C2=A0For general and adjacency related TRILL security consideration= s,
=C2=A0 =C2=A0see [RFC6325] and [RFC7177].

=
<dee>Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
= =C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A0= 155 Beaver Street, Milford, MA 01757 USA

>>Oth= er comments (not security related):

>>...

>>Cheers,

>>Vin= cent

--001a1147dbec98cd5105531f63d1-- From nobody Thu Jun 29 13:51: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 7207F12EAFA; Thu, 29 Jun 2017 13:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uyVDz9ycAuVT; Thu, 29 Jun 2017 13:51:09 -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 B356212EAC4; Thu, 29 Jun 2017 13:51:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.40,282,1496095200"; d="scan'208";a="230037796" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.1.104]) ([82.236.155.50]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2017 22:51:06 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Vincent Roca In-Reply-To: Date: Thu, 29 Jun 2017 22:51:05 +0200 Cc: Vincent Roca , IESG , "secdir@ietf.org" , draft-ietf-trill-mtu-negotiation.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3E57C59A-F330-4BB6-93AE-87EC71B9FB80@inria.fr> References: <935C94F4-DC5C-47C3-BE71-5939BD3E11B9@inria.fr> To: Donald Eastlake X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-trill-mtu-negotiation-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: Thu, 29 Jun 2017 20:51:10 -0000 > How about the following for a revised Security Considerations > section? >=20 > This document raises no significant new security issues for > TRILL. In TRILL, RBridges are generally considered to be trusted > devices. Protection against forged TRILL IS-IS PDUs, including > forged Hellos containing originatingSNPBufferSize APP-subTLVs, can > be obtained through IS-IS PDU cryptographic authentication > [RFC5310]. The worst that an RBridge can do by reporting an > erroneous originatingSNPBufferSize is reduce Lz to Sz and thus make > unavailable the optimization of being able to use link MTUs that > exceed the campus wide MTU for link local TRILL IS-IS PDUs. >=20 > For general and adjacency related TRILL security considerations, > see [RFC6325] and [RFC7177]. >=20 > Thanks, =46rom my point of view, it=E2=80=99s okay. Thanks, Vincent From nobody Thu Jun 29 17:40: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 49E3B126D45; Thu, 29 Jun 2017 17:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ljuSnI8OUP36; Thu, 29 Jun 2017 17:40:07 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E29631200F3; Thu, 29 Jun 2017 17:40:03 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id j186so55403402pge.2; Thu, 29 Jun 2017 17:40:03 -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=5mlqVYUXnDA2eQzvGifZVlfWaiKE8Ofjafaj0vi7GmU=; b=HyoJ6e3SUET9VDP5AdMkcXQOjXMfe+/Ww7t6rpAthBWDqdrP4fD9//vnEPmxPdtmAM qZQZQ1m2gNlHWNIPP4YzGpwtQK1OXRAXBJ7T9NTE2shgRkYPsnnZFgGEpQ0L0Bj/LCtc qPYjNvdZddceE5O/lnDhouwTsqqfe+gnaxGPZ4JXhRa8aqFoAci129L3HhxHSRvgD04z VuBt42vJtRwo5QlLF+m61J4Der97Yejz8vlI1HbTyVRqlYUyWuagivOuKeSZjTx9BFNy FQOLJgEv/UqMO1RZ5tKoxv1vlA4gzaBwSlz24dMVejnUGWqeGmXcDhqfim3ShZrLGxCE t6NQ== 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=5mlqVYUXnDA2eQzvGifZVlfWaiKE8Ofjafaj0vi7GmU=; b=nZqAvZK2OwTmZXY/CGrag18bSET8H/E3HwNL1oLlULQWqOT3FGJlIEhhKkhVLkwCjl EXVZ53y3QoeH91bN3Cj3jCXfJgDzgE4xLmAFLmmCdHeD/DsD/ZS77slfUTjLpZLhpcty qV7nfmLK6sOLjItbNxLq+jkild3yR3utsTyUYQeaz9ymUKTvbhPxP1W0Ylmx9ixqR1rk CqeJUq8J//ThbJZeL0g+j/SoNwYSP5bL+0ItOD2c7jRVplxhyoygEWFJm+tWoOtmMRW2 77zzHIVlikT9bodvxiUpVdrScMx1BuKbm1iMjSEsgSkItZfrtBb0a9Rc6YdchHIO2tF/ OnWg== X-Gm-Message-State: AKS2vOz0IrjMsoUBiZN9f3OqT4WUnUx+L7PlqICHHmDHperEcRPFc7Mr C6wxXj9KHimJ2D30w/BkYzZ9D8P+Cg== X-Received: by 10.99.123.18 with SMTP id w18mr18485395pgc.122.1498783203340; Thu, 29 Jun 2017 17:40:03 -0700 (PDT) MIME-Version: 1.0 From: Tina Tsou Date: Fri, 30 Jun 2017 00:39:52 +0000 Message-ID: To: "draft-IETF-trill-arp-optimization.all@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" , "tina.tsou@arm.com" Content-Type: multipart/alternative; boundary="f403045c64ba6e3501055322a818" Archived-At: Subject: [secdir] SECDir review of draft-IETF-trill-arp-optimization-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: Fri, 30 Jun 2017 00:40:08 -0000 --f403045c64ba6e3501055322a818 Content-Type: text/plain; charset="UTF-8" Reviewer: Tina Tsou Review result: Ready This is a document that specifies optimized ARP/ND response for RBridge, when the target's location is known, to avoid ARP/ND query and answer flooding. >From security point of view this document is Ready. If it can describe how to store and transfer the key, it is more complete. In addition, a flow chart may help the readers to clearly understand the handling of messages in section 4. No nit was found. -- Thank you, Tina --f403045c64ba6e3501055322a818 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Reviewer: Tina Tsou
Review result: Ready

This is a document that specifies optimized ARP/ND response for R= Bridge, when the target's location is known, to avoid ARP/ND query and = answer flooding.

From security point of view this documen= t is Ready. If it can describe how to store and transfer the key, it is mor= e complete.

In addition,= a flow chart may help the readers to clearly understand the handling of me= ssages in section 4.

No nit was found.
--
Thank you, Tina
--f403045c64ba6e3501055322a818-- From nobody Thu Jun 29 19:32:03 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB556126DCA; Thu, 29 Jun 2017 19:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 zWH-sfNinupB; Thu, 29 Jun 2017 19:32:01 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 F04D2126D85; Thu, 29 Jun 2017 19:32:00 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id m84so17619480ita.0; Thu, 29 Jun 2017 19:32:00 -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=gV1KciEazS7HZk6xD2KrzSy02L/xciGz1hVVQwdHA2Y=; b=aosiCn5c3oY4amMvkIgak7sjbQVQSqlJreou0n7xwm5BXIVJ5rKIFnpvpXKL6vTWhW FTu1b2uBSjWgSSCY6LL1RrQjbBt+OsuqjQ8rKojzs3CXhW3NRYE5QjI3qbFNw4/XvsPX czl+YLEoZK0YOND+Y60x9K3Q8Fp8LZgaXnOdjy+lTV97uoBUCo/o2GyaTDDR93pVobop qc/4JL+RyifBmhhGO+QiIwMCnXfYGPnKgrKfSEfGVCE/l/5i0lYWtZRwZ89HmdHmpjQo P1yXck3MKvVGoFUhagVs/KD7wzsCXnXg+kl70PDuAvw/cPvtBeH3Y5xbzJqkLrbgXrFk JdyA== 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=gV1KciEazS7HZk6xD2KrzSy02L/xciGz1hVVQwdHA2Y=; b=LDbCDrYQdE5+tA/TB8zAQX9epB3rmcovJqFhlPaLeaEawPIiB1+MZRwyrGCsFljUxa 1/Tn7U8OJP/0Yvpa3tZM4lPoNcRmmrT6PfaJDZ4JMXYK4gm+173feXHmXOhTnr4FCSax il+MbjkzvvYfIdbFidRnHKN9vgxL5m5qOkAPi+aO23Kf1HtSgXOVeLbB3m3xei/F8Ku3 hskBqpH2vXAf23sgRG5umdeJVdEy0tXHcGHsPjOudStX8Vb/dCiFv4y94bT//8T3Kpqd BhgOKlIsWn0VSyhUMdsng7PUkgQ1o938WVTqq+8uj+ZSAdCb3I9TCqtSoq/fAn/4XbSa 0Oaw== X-Gm-Message-State: AKS2vOylUt/UT3+hidvKuqe1iSOnjKwmY/tbRGguChzRK1INzbBE+uph HlsfopgJsrQ3eJD/1nPlsDS9cL5YUg== X-Received: by 10.36.150.133 with SMTP id z127mr18016913itd.104.1498789920336; Thu, 29 Jun 2017 19:32:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.221 with HTTP; Thu, 29 Jun 2017 19:31:44 -0700 (PDT) In-Reply-To: <3E57C59A-F330-4BB6-93AE-87EC71B9FB80@inria.fr> References: <935C94F4-DC5C-47C3-BE71-5939BD3E11B9@inria.fr> <3E57C59A-F330-4BB6-93AE-87EC71B9FB80@inria.fr> From: Donald Eastlake Date: Thu, 29 Jun 2017 22:31:44 -0400 Message-ID: To: Vincent Roca Cc: IESG , "secdir@ietf.org" , draft-ietf-trill-mtu-negotiation.all@ietf.org Content-Type: multipart/alternative; boundary="94eb2c08c4e2cb949d0553243856" Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-trill-mtu-negotiation-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 02:32:03 -0000 --94eb2c08c4e2cb949d0553243856 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OK. Thanks. Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Thu, Jun 29, 2017 at 4:51 PM, Vincent Roca wrote= : > > How about the following for a revised Security Considerations > > section? > > > > This document raises no significant new security issues for > > TRILL. In TRILL, RBridges are generally considered to be trusted > > devices. Protection against forged TRILL IS-IS PDUs, including > > forged Hellos containing originatingSNPBufferSize APP-subTLVs, can > > be obtained through IS-IS PDU cryptographic authentication > > [RFC5310]. The worst that an RBridge can do by reporting an > > erroneous originatingSNPBufferSize is reduce Lz to Sz and thus make > > unavailable the optimization of being able to use link MTUs that > > exceed the campus wide MTU for link local TRILL IS-IS PDUs. > > > > For general and adjacency related TRILL security considerations, > > see [RFC6325] and [RFC7177]. > > > > Thanks, > > From my point of view, it=E2=80=99s okay. > Thanks, > > Vincent > > > --94eb2c08c4e2cb949d0553243856 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK. Thanks.

Donald
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cel= l)
=C2=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com

On Thu, Jun 29, 2017 at 4:51 PM, Vincent Roc= a <vincent.roca@inria.fr> wrote:
> <dee> How about the following for a = revised Security Considerations
> section?
>
>=C2=A0 =C2=A0 This document raises no significant new security issues f= or
>=C2=A0 =C2=A0 TRILL. In TRILL, RBridges are generally considered to be = trusted
>=C2=A0 =C2=A0 devices. Protection against forged TRILL IS-IS PDUs, incl= uding
>=C2=A0 =C2=A0 forged Hellos containing originatingSNPBufferSize APP-sub= TLVs, can
>=C2=A0 =C2=A0 be obtained through IS-IS PDU cryptographic authenticatio= n
>=C2=A0 =C2=A0 [RFC5310]. The worst that an RBridge can do by reporting = an
>=C2=A0 =C2=A0 erroneous originatingSNPBufferSize is reduce Lz to Sz and= thus make
>=C2=A0 =C2=A0 unavailable the optimization of being able to use link MT= Us that
>=C2=A0 =C2=A0 exceed the campus wide MTU for link local TRILL IS-IS PDU= s.
>
>=C2=A0 =C2=A0 For general and adjacency related TRILL security consider= ations,
>=C2=A0 =C2=A0 see [RFC6325] and [RFC7177].
>
> <dee>Thanks,

From my point of view, it=E2=80=99s okay.
Thanks,

=C2=A0 Vincent



--94eb2c08c4e2cb949d0553243856-- From nobody Fri Jun 30 06:10: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 75C5C126CB6; Fri, 30 Jun 2017 06:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1v5tki0HoCkN; Fri, 30 Jun 2017 06:10:46 -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 29DBE1204DA; Fri, 30 Jun 2017 06:10:46 -0700 (PDT) Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id v5UDAi9i027677; Fri, 30 Jun 2017 22:10:44 +0900 (JST) Received: from DESKTOP2JPR8KD (ssh1.nict.go.jp [133.243.3.49]) by gw1.nict.go.jp with ESMTP id v5UDAihJ027545; Fri, 30 Jun 2017 22:10:44 +0900 (JST) From: "Takeshi Takahashi" To: , , Date: Fri, 30 Jun 2017 22:10:42 +0900 Message-ID: <000a01d2f1a2$473494f0$d59dbed0$@nict.go.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01D2F1ED.B71EADF0" X-Mailer: Microsoft Outlook 16.0 Content-Language: ja Thread-Index: AdLxokRNagQuj+VzTqOH2wtODcVqGg== X-Virus-Scanned: clamav-milter 0.98.7 at zenith1 X-Virus-Status: Clean Archived-At: Subject: [secdir] Secdir review of draft-ietf-spring-oam-usecase-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, 30 Jun 2017 13:10:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000B_01D2F1ED.B71EADF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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. [General summary] This document has small nits. [Clarification Questions] In the "Security Considerations" section, the draft says that "some fundamental MPLS security properties need to be discussed." It would be nicer if you could elaborate more details of the "properties" in the section or put some reference that describes the details. The "Security Considerations" section in RFC 4379 says, "Overall, the security needs for LSP ping are similar to those of ICMP" and elaborates issues such as DoS attack and spoofing. Is the proposed MPLS monitoring system free from these issues? Since this draft discusses the path monitoring system in coparison with RFC 4379 from time to time, it would be nice if these security issues are also addressed. (Indeed, I could not find the term "denial" in this document at all.) Thank you. Take ------=_NextPart_000_000B_01D2F1ED.B71EADF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have = reviewed this document as part of the security directorate's ongoing = effort to review all IETF documents being processed by the = IESG.

These 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.

 

[General = summary]

This document has small = nits.

 

[Clarification = Questions]

In the "Security Considerations" = section, the draft says that "some fundamental MPLS security = properties need to be discussed."

It would = be nicer if you could elaborate more details of the = "properties" in the section or put some reference that = describes the details.

 

The = "Security Considerations" section in RFC 4379 says, = "Overall, the security needs for LSP ping are similar to those of = ICMP" and elaborates issues such as DoS attack and = spoofing.

Is the proposed MPLS monitoring system free = from these issues?

Since this draft discusses the = path monitoring system in coparison with RFC 4379 from time to time, it = would be nice if these security issues are also addressed. (Indeed, I = could not find the term "denial" in this document at = all.)

 

Thank = you.

Take

 

 

------=_NextPart_000_000B_01D2F1ED.B71EADF0-- From nobody Fri Jun 30 07:47:21 2017 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA50A129AF6; Fri, 30 Jun 2017 07:47:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rich Salz To: Cc: iesg@ietf.org, draft-bormann-hybi-ws-wk.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149883403385.4646.10205758976301254515@ietfa.amsl.com> Date: Fri, 30 Jun 2017 07:47:13 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-bormann-hybi-ws-wk-00 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, 30 Jun 2017 14:47:14 -0000 Reviewer: Rich Salz Review result: Ready This is a SECDIR review of draft-bormann-hybi-ws-wk-00 This document is ready. It is a formality, defining what was already possible. The security considerations are appropriate, and the second paragraph was particular nice to see. From nobody Fri Jun 30 09: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 2D6AE130141; Fri, 30 Jun 2017 09:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 5WuropfKnqHQ; Fri, 30 Jun 2017 09:31:35 -0700 (PDT) Received: from hardbaer.com (mail.hardbaer.com [91.250.101.142]) (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 156E9126557; Fri, 30 Jun 2017 09:31:34 -0700 (PDT) X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from WStation4 (business-092-079-177-146.static.arcor-ip.net [92.79.177.146]) by hardbaer.com (Postfix) with ESMTPSA id 7D68B280A52; Fri, 30 Jun 2017 18:31:31 +0200 (CEST) Date: Fri, 30 Jun 2017 18:31:22 +0200 From: Michael =?ISO-8859-15?B?QuR1ZXJsZQ==?= To: David Mandelberg Cc: iesg@ietf.org, secdir@ietf.org, draft-baeuerle-netnews-cancel-lock.all@ietf.org Message-ID: <20170630183122.5b8b10ae@WStation4> In-Reply-To: <79785418-2159-2dba-3beb-b9391a5a2ddf@mandelberg.org> References: <79785418-2159-2dba-3beb-b9391a5a2ddf@mandelberg.org> Organization: STZ Elektronik User-Agent: Claws-Mail/3.13.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_//0eltdKLevD5K+JW.qZ007W"; protocol="application/pgp-signature" Archived-At: Subject: Re: [secdir] secdir review of draft-baeuerle-netnews-cancel-lock-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 16:31:37 -0000 --Sig_//0eltdKLevD5K+JW.qZ007W Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable David Mandelberg wrote: >=20 > [...] > Section 4: I think you should run any user-supplied password through a > key derivation function before using it as a MAC key. The obvious solution would be HKDF, but RFC5869 says in section 4: |=20 | [...] Applications interested | in a password-based KDF should consider whether, for example, | [PKCS5] meets their needs better than HKDF. Would PKCS5 (RFC8018) be a good solution for this purpose? A workaround would be to change the words from section 4 of the draft: |=20 | The local secret should have a length of at least the output | size of the hash function that is used by HMAC (256 bit / 32 octets | for SHA256). If the secret is not a random value, but e.g. some sort | of human readable password, it should be much longer. In any case it | is important that this secret can not be guessed. to: The local secret should have a length of at least the output size of the hash function that is used by HMAC (256 bit / 32 octets for SHA256) and must be a random value. This would simply push the problem beyond the scope of the document. > Section 7: As I understand the terms, you care about preimage > resistance, but not second preimage. (I think preimage covers finding > any input that results in the specified output, not only the input that > originally generated the specified output. But I might be > misunderstanding the terms.) If second preimage always is associated with known input, then I have used the wrong term and paragraph 1 in section 7 should say: The important property of the hash function used for is the preimage resistance. A successful preimage attack either reveals the real Cancel-Key (that was used to create the Cancel-Lock of the original article) or gives a different Cancel-Key (that matches a Cancel-Lock too= ). This would break the authentication system defined in this document. --=20 Michael B=E4uerle --Sig_//0eltdKLevD5K+JW.qZ007W Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZVnzaAAoJECo3xlduIVC7bCEP/2nXynzje4ALTcSor3QWZJdh 8TzaKlpkoSoFua1l0XVEf73hGR1ElmPvGOuCbEu47AIOogYSriHtiAMx94SgvPCW Io8itFygwoq7guXlFISBFCvYMPNP7mmWG9LkKHq5RPM9G27pnQQhGwXp59IOoebP DqbSPUOZ3Ff1xNqvfKQL40y+9jQCkAaR96XED8QFPpIgzlAjKfhd0Ju0YGBAQSEV Eq1U5SLYWu2ozR0moqw6lLgUCg7VdUuYiTTZOWVnRdWIyJgOi2RHRX1mQYvYwkEi areXUqXv72GJ9fRFhHSu/Iv4U47ORLSqf0LVvE1Uf4SCJ3CV+h/9pIHFluWJfjhx h05jj23wKYLAw/XpRH0pIjKtA/P9hfMnhvX7Pl0nohbolX5pPIZyiEQ6mSj2rSw6 p7zfuzw3gsm+MTk+PSMclaKqXAWjd1dBZBLVAbCN522unmT9Chdo0l3fBDv5a5sd 6IcK58442yKi98N/+zn8oMxerlmK0xzLcDUYrVZQgfpHq2SOZ0MRwclMqIgNVKKb h+kIaJ/ZyAmjYwjfO1juiKqYDGn1K4tICkWJ8w+kRFXRQHQQzMeH2uyBdfei9nHD JPx9MZUzDiEwp9k9+8ugo69V7DcCZEKB1rxTkA9xaO4eND0ZlfI/gtNir+Wsv8JN cwojZRfGPhtLaONvkEkb =ptip -----END PGP SIGNATURE----- --Sig_//0eltdKLevD5K+JW.qZ007W-- From nobody Fri Jun 30 18:45:26 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 02B6212EC5C; Fri, 30 Jun 2017 18:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 UojO-XNMDysF; Fri, 30 Jun 2017 18:45:16 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 A317812EABA; Fri, 30 Jun 2017 18:45:16 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id v202so13237837itb.1; Fri, 30 Jun 2017 18:45:16 -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=rVwAyZ2hf3RtWJu3zXtQsb67LaGH+63xs6W4yKhOJTo=; b=rypx6KhZsxI8uLsL04P/sXqmQD8yCQoSGbvIpFgD8OVixsZ29G0vC/gn2mou35Y8h1 LBuF2ztJZMcgz8jGc0YgvJTv9BfXXkTDVBDhg7PLT5w7Ht+gCDQTRed6S2oCFMxQzQQ/ aIsaXnqJGXo2kotOXMy3lUgKVw6c2EImaSNwht3bt+B+NiCb1h/XU6lAg0Qw6qKhU8yJ 0UwVUWZRNZzlObU1DFqH2JFoJR3a6ZJfy6Hyap3l+J4eWUSe3Q3CVf53iVijjay6kxhK ntd55LY2hin6YSuUx3IHu2zuRgqBzGWCpTQP0yJsG0mf/Re3IzEEVT7blnkqUO2GXpZg OuFg== 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=rVwAyZ2hf3RtWJu3zXtQsb67LaGH+63xs6W4yKhOJTo=; b=tDJhfjRyTC7U56GrEqVy1JjbZH50tXSYtm8QnZFw9soRkeLT6zrpqgsXUz89M27LGK ZQevtcnH6pcdPf8vc9iADlbBgWl7J7SZ+VXRODlmmKSDTvXR+joSaKXK7IDwkzVRaoqS zEQ6l5fbsyHF0+Kqze2KECKhAkj6vungzK1zODgPIfoPffopAR99X6t+1VixV5VwuCqo I4iXySFUoTjQqLDGQkbVz6sCXQyZD8AQzhlPeksO0czKtGCk4sCPTDAbisCW5qw1aWAQ uxk2KyQea2OX4mEZlw6z/URRyu97zLB1I2Bii08sr/24oRdHvu6B1+6urLkxPZib4uiO tF8g== X-Gm-Message-State: AKS2vOy/hdKCCIS9TpjsLYReE1baFk0GhDfP3bsa12cO0KYEZ7mKefYE xeBIHJNWQ7uDizx4nToCHfxxxOPQ6TxZ X-Received: by 10.36.53.70 with SMTP id k67mr22173084ita.79.1498873516075; Fri, 30 Jun 2017 18:45:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.221 with HTTP; Fri, 30 Jun 2017 18:45:00 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Fri, 30 Jun 2017 21:45:00 -0400 Message-ID: To: Tina Tsou Cc: "draft-IETF-trill-arp-optimization.all@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" , "tina.tsou@arm.com" Content-Type: multipart/alternative; boundary="001a114abeec7d2ef9055337afb5" Archived-At: Subject: Re: [secdir] SECDir review of draft-IETF-trill-arp-optimization-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: Sat, 01 Jul 2017 01:45:18 -0000 --001a114abeec7d2ef9055337afb5 Content-Type: text/plain; charset="UTF-8" Thanks, for the review. Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 <(508)%20333-2270> (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Thu, Jun 29, 2017 at 8:39 PM, Tina Tsou wrote: > Reviewer: Tina Tsou > Review result: Ready > > This is a document that specifies optimized ARP/ND response for RBridge, > when the target's location is known, to avoid ARP/ND query and answer > flooding. > > From security point of view this document is Ready. If it can describe how > to store and transfer the key, it is more complete. > > In addition, a flow chart may help the readers to clearly understand the > handling of messages in section 4. > > No nit was found. > -- > Thank you, Tina > --001a114abeec7d2ef9055337afb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, for t= he review.

Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2= =A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A0155 Bea= ver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com

On Thu, Jun 29, 2017 at 8:39 PM, Tina Tsou <= span dir=3D"ltr"><tinatsou6@gmail.com> wrote:
Reviewer: Tina Tsou
Review result: Ready

This is a document that specifies optimized ARP/ND response for= RBridge, when the target's location is known, to avoid ARP/ND query an= d answer flooding.

From security point of view this docum= ent is Ready. If it can describe how to store and transfer the key, it is m= ore complete.

In additio= n, a flow chart may help the readers to clearly understand the handling of = messages in section 4.

No nit was found.
--
Thank you, Tina

--001a114abeec7d2ef9055337afb5--